Git - I don't understand branching

I don't see a place on Code Ranch to ask about git.   If a moderator sees this, please move it to the correct area.

I am reading a book that was giving wonderful explanations of how to use git.  It was working until I got to the topic of branching.    It seems as if the code goes in multiple directions and the developers can make changes, add and commit them.  

Later on, the different paths can be merged together.   If there are conflicts such as more than one branch making a change to the same line of code,  git complains until the user determines which is the correct version for the differences.

I'm going to watch some YouTube videos to get a better understanding.  

Maybe someone could explain the branching at a high level.

Thanks,

Kevin

A branch is like a parallel universe where a different version of your code exists. When the code in one branch changes, it doesn't affect the code on another branch.

There are four big reasons I can think of why you'd want to have different branches of your code:

1. You and a colleague are working on the same piece of code simultaneously. It would be very annoying if your colleague made a small change that breaks your changes, and when you fix it it messes up what your colleague had planned. Instead, you both work on parallel branches and only merge your changes when one of you is done.

2. You are working on two different features. Let's say you're working on some fancy new feature for your application, and then an urgent bugreport comes in. You can't finish your feature first because it will still take a while, and you can't start the bugfix, because the codebase is still full with unfinished code from the new feature. Instead, you create a branch off of the latest stable version of the code before you started work on the new feature, and use that branch to develop the bugfix. When the bugfix is done and released, you can merge it back into the feature branch you were working on. An advantage of using a separate branch per feature or bugfix is that you can always go back and take a look at the changes that were made in order to implement the feature or bugfix.

3. You have hit a dead end in an experiment, but you don't want to throw away the code. Let's say you wrote some messy code just to find out how an API works or to experiment with a new idea. When it turns out the experiment didn't work, you don' want the code to mess up your main application. However, you might still want to keep the code around so you can review it later. Just put it on a separate branch where it won't affect the main branch!

4. Maintaining major versions. Sometimes you create a new version of your application that contains major changes that break compatability with a previous version. However, some of your customers might still be using the old version and don't want to migrate to the new version of your code, because it will break their application. So when you have bugfixes, you might have to apply them to the new version of your code, but also the old version. The solution is to maintain different branches for each major version of your application.

So I don't understand git too well but have used other version control tools.  Really would like to gain a proper understanding, but limited time!  

It seems a common complaint is that the various commands are difficult to understand and don't describe what you want to do from a user's perspective.  
Git is simply too hard
So mostly I stick to a few commands and practices; feature branches, rebase the main branch onto the feature often, and merge as soon as possible.        
I've started using the IDE a lot more for git.

Git probably could have been a bit simpler. But the criticism of Git ignores something very important: Teamwork IS complex.

In the article, the author illustrates some seemingly simple use cases, but as with anything, the devil is in the details. Let me quote a part:

I have some changes. I wanna share it with Jon and Johnny so they can tell me what they think. And then maybe they can add their ideas. And then we can have a merging of our ideas, and eventually test out if it works, and have it out there and ship it.

This sounds simple, but it really is a very strong distillation of some very complex ideas. What does "sharing" mean? What does "adding ideas" mean? What does a "merging of our ideas" really look like? What if that doesn't work? What does "getting it out there" mean?

I can explain anything to a person as if they're five years old, but that doesn't mean that the reality isn't more difficult.

I find that despite its complexity, Git is way WAY easier to use than other version control systems. That's because other version control systems mostly focus on the happy flow, where you don't run into conflicts. But when you run into conflicts, people then generally resort to solutions where you might as well not use the version control system at all. Git gives you very powerful tools to handle these situations in a consistent way.

Yes, that means you have to understand the tools well. Yes, that means you have to practice.

"some very complex ideas"

- yes, it's also decentralised which I guess adds to the complexity.  Other systems I've used seem to only offer a centralised repository.
I'll agree the fundamental issue is that version control is difficult, more so on larger projects.  I'm guessing Linus (and others) were always more focused on the [complex] solution and expecting others to provide more usable tools (like IDE's).  

I do still find some terms confusing - "head" for example - but then I'm only halfway through "head first git".  
     

Probably the two most powerful features of git are its distributed nature and branching. Branching is a very old concept, but git does it exceptionally well.

A short note on distributed version control. Traditionally, there'd be a central server that people would check code out from and check changes into. Often you'd have to put a lock on the code to avoid conflicts coming from two people trying to modify the same code at the same time, which can happen, for example, if they both need improvements to a utility module that's shared between their work assignment codes.

Git is different in that your true repository is the checked-out project itself. You can do all your work locally and only need to contact a central server when you want to either obtain a project, get updates from others, or check your own changes in. Everything else is completely offline, which can be a major help if you're Devaka Cooray in Sri Lanka, and electrical power is prone to frequent outages and Internet connectivity even more so. That was a major concern about 2 years ago to the point where he set up solar power and did other things. Hopefully things are better there now, but the important fact was that he could do most of his work unaffected by these inconveniences.

Revisions are committed atomically, so no broken stuff. It's "all or nothing". When you are ready to push your changes back to the master repository. those changes likewise get applied atomically. Also note that there's not necessarily just one remote repository for a project. You can designate more than one remote code host and push to whichever one suits you. A nice feature, but best used sparingly.

Finally, note that commits don't have version numbers like older systems such as Subversion did. Instead, each commit has a hash code that makes it distinct so that the git repository doesn't have to worry about getting the same commit twice or having contributors commit back out of sequence. And an additional note is that since this plan doesn't require locking code, you don't have to worry about any of the developers being hit by a meteorite which critical code is locked, requiring a central administrator to forcibly unlock it.


Now for branches. A branch is simply a variant of a project and it's common practice pre-dating git to create a project branch and work on the branch, merging the branch back into the mainline project when it's ready for production. Doing this allows any fixes to production (production source) to be done without dragging in the incomplete changes in the branch prematurely. Git supports multiple concurrent branches on the same local project, which can be helpful if you have several feature set projects in various stages of development. A simple "git checkout" can switch your workspace between branches".

Git also has a special "stash" feature for when you're working on something and you get an emergency fix request. You can simply stash your local work to revert to the mainline code, put in your fix, commit it, and unstash what you'd been doing. It's fairly easy to spin a branch out of work in progress as well, if you're like me and forget to create a branch before starting work.

Yes, git has a bewildering array of features, but most of the critical ones have simple uses. And the rest of them are there. Just in case.