I think they should teach this during first week of orientation - Its ridiculous that I learned using this only after 4-5 years from graduation. and yes - I am a product manager

i thought its because the CS courses are all still actually 'computer science' and not 'software engineering' or 'software development' even if that is what most graduates are doing.

@@tusharjamwal yeah, people commonly conflate computer science with software development.

We had a class that covered it. I don't know that I agree that it needs to be taught first thing. But even if it isn't taught, most people are going to end up a company that is going to teach them to use it very soon after they get there.

In my program we learned git in first year

You don't want to see the ugliness.

I view computerphile more as higher level ideas than i do a tutorial on how to do something. Showing code isn't necessary in that case.

I was thinking the same thing. The worst is when you’ve been working on a branch for weeks and have dozens of merge conflicts to fix.

@@iamfenix117 you're absolutely right, it's more of a macro perspective than a micro one, and that's why it's amassed such a big audience.

Agree - they should show a merge tool in operation

What he described is very similar to the process that we follow where I work.

Automated testing and continues delivery is even more ;)

I mean, not really. It's been in common use for over a decade now, and arguably is THE version control standard now. So it IS the game, not the game changer.

Was* It's been the de-facto standard for over a decade

Software configuration management has been evolving for decades. git inherited many features from its predecessors so I wouldn't say it's game-changing.

Why? Everybody seems to be on the Git bandwagon, but how is it a game changer? I'm not trying to be antagonistic at all, just that I think I might be missing something that was not addressed in this video. How is Git better than Svn, for example? From the video, it is no different than Svn.

Use squash merge when merging PRs to keep the history of the master branch clean. My working branches I use normal merges when I pull in master so that I have a history of what I did, and can see when I introduced a bug.

@@TesterAnimal1 Yeah, I always squash-and-merge pull requests, unless the commits are better kept separate, in which case I'll just do a rebase-and-merge. And, I alwats use git-emojis to make the cmmit messages more colorful.

This is so true. I tried learning Git from tutorial videos multiple times and always struggled to connect theory to practice. The only way I overcame this was to do examples repeatedly, especially merges and fixing merge conflicts.

that's why calling it a merge request makes more sense

"I actually use SVN" Get out!

With Git, it’s “commit early and often”. 😎

The 80's called, they want their version control system back

@@RudyBleeker, first Ouch! Second, the only real advantage of GIT is tooling and wasting money doing merges. I have a non distributed team, and actually like command lines that make sense.

@@levmatta apologies, my comment was meant as a joke, not an insult. Also it's factually incorrect, SVN was developed in 2000, not the 80's, I got it mixed up with CVS. That said, I can't make heads or tails of SVN's command line syntax, nor do I particularly like the client-server model and quirks that come with it such as locking. But that's probably because I haven't used it very much, I started early with git and got the hang of that pretty quickly.

Mask flavoured iirc -Sean :)

Try vscode for conflict resolution, unless you have deep tree conflicts, conflict resolution is really easy

As someone who codes in C# and uses Rider as an IDE, you can do exactly what you're describing when handling merge conflicts!

@@KZfaqFrog1212 also in Intelij, but I prefer vscode or either solve it manually.

@@adia.413 SmartGit is another option.

Conflict resolution isn't Git's job. Git just identifies the conflicts, you resolve them in your editor. Whatever pain points you are facing, it's probably to do with your editor setup rather than git.

Why do you think Microsoft bought GitHub?

TFS can use Git for version control, rather than TFVC which is (or used to be, at least) the default. And you can, I believe, migrate from TFVC to git as well. Just to give you a bit of a gentle reality check though - Git isn't perfect. It does have it's own problems too.

@@idjles Nope. They had Git and TFVC well before they bought github. That acquisition was done for a whole different reason.

@@marklnz Oh? I did not know that! Alas, I'm not the one who gets to make that decision, so for now I'm stuck with TFVC, at least until we retire this project and its updated version goes live. And yeah, I'm well aware that Git has its faults (I'd be a fool to think Any VC system was flawless) I just personally like some of the things it allows you to do which TFVC doesn't, or at least which I haven't figured out how to do.

Warning: Using TFS or Visual SourceSafe can be seriously harmful to your programmers’ productivity.

It's not big enough for a video but it's very important for every newbies out there - I hope they cover it somewhat in a later video

@@aravindpallippara1577 I think at least for Git Rebase they could make a full video discussing why you need to force push when you do it. And why once someone starts rebasing in a Git repository, it tends to be that everyone has to start rebasing in a Git repository.

@@ZT1ST you don't and you don't. Just never rebase anything that you work on with other people, only private branches that you merge before publishing them.

@@RudyBleeker Sure. but you could absolutely do a whole video on *why* that's the intended case. Because you *can* rebase the main and public branches. You just never *should*, hence why it's limited to private branches in practice.

Always pronounced it as beata myself See no reason to change now

queens English

beta, eta, theta, zeta ... they all rhyme.

Maybe that’s an argument for using names rather than numbers.

@@lawrencedoliveiro9104 It might be. :-) In this case, though, the original code wasn't mine, and I prefer to leave as many lines untouched as I can. Elsewhere in the code base, we did indeed use names.

I can’t even see anything in standard SQL that allows columns to be referenced by numbers, only names. Not in the SQL 2003 spec, anyway.

@@lawrencedoliveiro9104 The Informix dialect allows columns in the GROUP and ORDER BY clauses to be referred to by number instead of by name. Especially convenient if a some of the columns are expressions (usually TRIM) and you don't want to provide aliases for each.

@@menachemsalomon I don’t understand the point of that. It’s just a recipe for needless obfuscation -- and trouble, as you discovered.

While you are correct in theory, in practice as a git user you don't have to worry about this if you didn't edit the same area in the same file. When the second person pulls because he can't push at that point, but there is no conflict, git will just fast-forward the head to where it should be and automatically merge the new code. Depending on your settings it might not even create an automatic merge commit.

We used Subversion and it was ok. And before Subversion, we used CVS and it was ok too...

@@carlaodacosta while CVS was better than nothing it was considerably worse than either SVN or git.

The same? Source control has existed for a real long time

@@carlaodacosta And before CVS there was RCS. And before RCS there was mostly manual management of revisions. But it was less of an issue back then.

Subversion works great. It uses a centralized server for everything. Git is decentralized. Its main advantage is that it takes a LOT more data to do a checkout, and the vast majority of people use a centralized server anyways, so git acts a lot like a much slower version of SVN. Yes, git has a few advantages over SVN, but those advantages are not a big deal for most people.

I would prefer a life without love

Do CI/CD and always push to main.

I think one of the main differences is that with Git the coder is cloning a repository locally to their personal machine, where is SVN you're working with a centralized system.

Imagine you commit just like SVN but nobody else (no server) gets the change. You can commit as often as you want. Only when you push the server receives your changes and commits and others can get them too.

Subversion internally stores changes as file objects while git stores changes as commit tree. Subversion being central repository will require updates on every changes i.e. branches, commits etc. Git being distributed only cares of changes when merging happens between two different repo, typically local repo and remote repo, or two branches. So to actually get file from subversion, you actuslly request it to read particular directory and file like traditional filesystem where you would keep reading first file and then go to next and so on while on git all the commits till files latest state gets recreated from begining with commit history. Benefit of timeseries like commit data is, you can have separate commits with different meta data and when multiple users merge these to central repository, each commit hash ensures that relevant changes are reflected on repository collectively. As each independent commit is made sure no user writes same lines on next commit if their heads are not upto date with current repository state. Git is like local repository, every git repo is full fledged repository on it's own. We just keep them in servers to be accessible to others along with ACL that may forbid access. Unlike traditional version control systems, git is distributed - meaning each node will have their own copy, when you merge it with other node, magic of commit history happens which creates journal entry in commit history (metaphorically) On other hand with traditional version control, files are kept centrally and you have to notify it for branches and commits which adds extra trips, not so convenient when lots of people have their own copies. Git protocol by design raises any conflicts and will not let you merge or commit till change history is clear and code can be pushed / merged on top of existing commit. All done by keeping track of changes in a tree like structure of commits and branches where changes data is kept and then further packed into files and compressed to save space. That is still very vauge explanation on what exactly happens as different version control systems will work differently, git on other hand is more like commit journal where entries are permanent and self sustaining by nature.

Under git you can create thousand of branches, it won't take gigabites on your drive. Create a branch under SVN, it will do a full copy of exisiting code Create a branch under git, it will only save the diff That a huge game changing

SVN can also work with a checkout-lock flow where only one person can edit a file at any one time. There's huge debate about whether this is better than copy-modify-merge (like GIT, but subversion can also do it) and in my experience (ASIC designer) it's highly dependant on team/corporate structure, design flows and design tasks. However, I find locking infinitely preferable when it comes to binary files.

That's only for codebases where you never have to maintain older versions of the code. Every user is always on the bleeding edge. I work in Financial IT where that is definitely not the case.

@@Jonteponte71 I agree with you. The point is you do not have to use a branch structure like beta versions or a release branches and even feature branches. Reducing the amount of branches which are supposed to be merged again reduces the overall clutter and effort.

In my personal experience with CI/CD development - our solution was to commit to branches, push them up, then make GitLab specific Merge Requests into a staging branch, and then every so often a Merge Request from Staging into Main - with each merge request squashing all the changes since the last time they merged into the branch above it (i.e. Stage -> Main would only merge the newest stuff since the last time it merged) into a single commit that is committed to the branch above it. Which effectively *looks* like we just commit to the main-only approach, but isn't *quite* like that.

Yes we use trunk based development and CI/CD at my work. Definitely better than feature branching with e.g. git flow. You can still support multiple released versions easily. We tag when we release a version and if we ever need to patch it we just create a branch from that tag, which eventually gets released with it's own tag and the active branch is deleted. The commit structure is still a tree, there just aren't any long lived branches other than the main branch. You may sometimes have to push the same fix to multiple versions but it's usually pretty easy to just cherry pick it across. We don't make a branch as a team, work on it for 2 weeks and then try to merge it back into the main branch. The real problem with long lived feature branches is merging. If you have 2 weeks of changes to merge and another team has 2 weeks of changes to merge, it will be painful. If you only have an hour of changes to merge at a time it won't be as bad.

@@ZT1ST In CI/CD we don't have "QA branches", "staging branches" or "production branches"...

Linus Torvalds, the creator of Linux.

Linus Torvalds, who also created Linux.

Linus Torvalds had issues distributing code hence why he made Github :)

The dude is a god

@@netadmin-fraser787 He made Git, not Github. I do believe he's specifically not fond of Github.

Yeah agree

I think the lack of a tripod is an intentional artistic decision. I'm not commenting about its usefulness though.

I think is meant to have the camera man be a stand in for the audience to ask follow up questions etc as well, doesn't require handheld but I guess seems more natural.

Maybe buy a gimbal then, or a stabilized lens or camera body. Would be nice to watch these videos without worrying about motion sickness.

Found the comment I was looking for so I don't need to make my own. A stable camera is a simple and fundamental principle to a quality video.

We've actually just switched to this model, before all of us developers would branch and merge into a "develop" branch, this would then be pushed to a "release" branch for regression testing, before finally being merged into "master" and going live. But now we've spent tonnes of time building up automated tests, which get ran everytime a pull request is made (and will fail the PR if a test fails!) and have switched to only using a single "master" branch. The overall team confidence has gone up, we're seeing a lot less issues during regression, and we get to spend more time developing new features instead of bugs!

We're getting closer to that branching strategy. We went from 3 long lived branches (main, Dev, sit) with feature/* and bugfix/* branches for each ticket created from Dev. To just 1 long life branch (main), release/* candidate created from main, and the feature/* bugfix/* branches from the release. Definitely sped us up, so I think we'll eventually get there

It's a methodology and has nothing to do with git the software. It's like claiming if you wanted to learn about for loops you should also learn about orm vs database querying.

This usage of feature branches depicted in this video is one of the general anti-patterns of using git for development in almost all the cases. They have a nice idea of finishing complete and tested work pieces. But when you scale that model up to several people or teams (not to mention about hundreds), you will get integration issues just before deadline that then may actually take quite a long time (months) to solve. And the bigger the organization, the worse it gets. That's why continuous integration and trunk based development is all the rage in places where development efficiency matters.

Even with automated testing, you would want to work in a dev branch. You may be calling your dev branch the main branch, but what you don't want is to be preparing for a release and come in to find that the nightly build has failed or some tests don't pass. Plus, on large projects, you may not be able to run all of the test every day, so you may have test failures that don't show up right away. You always need code that has all of the tests passing and isn't being modified by developers.

Ha ha. I wrote software for 30 years. Every year that went by it was more of a chore because of how elaborate systems became.

The quality of translations aren't always the best, maybe in the future.

Git by itself, both can and will never do it. Gitlab and github have absolutely nothing to do with git itself. They are merely web frontends for git. Git is more or less just a file system. A versioned file system as there have been many others. It stores your data on disk along side the metadata and does so for several versions of the files. So, can a file system allow random people to translate whatever? Well, yeah, in the end it's just a file. All you need is an application that presents the translation files nicely and perform the commits. But it's not git's job by a vast margin.

You learned version control.

@@ddanielsandberg I learned version control on the job. I don't like to give my university credit for much

@@BarelyGoodTV Lol. Sad, but true. :D

No

@@rickymort135 ?

Yes. It's called pair programming and Continuous Integration.

@@ddanielsandberg No, that's complementary processes to git, it doesn't remove the need of git.

@@Ermude10 I'm sorry, I was unclear. I never argued against Git. I commented about your comment about convoluted processes and "requirements to review even the most mundane changes" and that there have to be better ways to collaborate. None of which has anything to do with Git. There are probably tools out there that achieve the same things as TBD/CI without the overhead of Git but I don't know... OK?

​@@ddanielsandberg Aha, that makes more sense. But yeah, I still think those processes are often used in conjunction with git as they ultimately target different problems. And I think it very much has to do with git, because git is often the tool or framework that dictates how we make changes and how we collaborate.

Bitbucket started out as an online repo service only for Mercurial. It got forced into providing Git as an alternative, by popular demand. And then the popularity of Mercurial diminished to the point where it wasn’t worth supporting any more. So that is now gone.

File locking is how version control used to work back in the 1980s. Because it was thought that, if two people simultaneously made changes to the same file, the world would end or something.

@@lawrencedoliveiro9104 That's not why I thought of file locking, I just figured that a lot of time & effort would be saved if the dev didn't have to spend time merging changes manually since they would already be in there before the editor allows them to work on the file, it also serves as an indictor that they might not need to fix whatever they were going to fix & instead go work on something else for a while before retrying the file.

@@zxuiji The problem with locking is it slows down development and makes things awkward, like when you find that somebody has locked something they didn’t need to, and you have to ask them to unlock it so you can work on it. That’s why locking was done away with. That’s why productivity is so much greater with modern VCSes than those older, locking-based ones.

I think you aren't using git properly, because I can't relate with my 100+ daily commit project.

Wouldn't fixing this second issue imply that git is able to analyse code in every possible programming language or even every possible structured file format? It seems a bit out of scope to me.

@@ApprendreSansNecessite not necessarily. git offloads merges to a different program (configurable per file type). by default it uses an internal diff3 solver for text files and a binary choice merger for everything else, but there's little reason why you couldn't write an intelligent merger for your own file types which git would use. why that isn't done very often it a question I don't know the answer to (searching git mergetool on the web brings up basically no projects that implement it)

@@ApprendreSansNecessite Not at all. Git should be able to detect that two developers have added code (any code, regardless of language) in the same section of the file and simply include both. The code after the new sections is unchanged... it should be easy enough to determine that both versions have additions and just include them both.

@@kleinesfilmroellchen Using it properly? You commit a change, you pull, you push. There aren't many things that you can do wrong.

I think the biggest benefit of doing this also as a solo developer is that it conditions you to work on one issue or functionality at a time. Your code is then much less messy than if you tried to do several things at once and ended up with a complex web of dependencies.