Branching and Merging in Git

Having touched upon this topic in the last video, it is now time for us to delve a little deeper into the topic of branching and merging in Git.

[Video description begins] Screen title: Collaboration in Git [Video description ends]

Before we get into any specifics, let's take a look at a problem which it tries to address. And this is collaboration when working on source code. It is becoming more and more common for teams to be scattered all over the world. And for them to work on large code bases which are stored in a version control system. Clearly a good version control system will make it easy for such teams to work collaboratively. While ensuring that any changes to the source code is regulated.

[Video description begins] Screen title: Remote Repository [Video description ends]

To understand how this might work, let us take a look at an example. So we have a remote repository which includes the original source followed by a number of recorded changes. Now, multiple teams can work independently by cloning this remote repo into their own local repos. And let's just say there are two teams which are headed by Alice

[Video description begins] Screen title: Adding New Features [Video description ends]

and Bob, which are tasked with adding new features to the source code. For Alice and Bob to begin working on the development, they will need to create clones of this remote repo.

[Video description begins] Screen title: Cloning the Remote Repository [Video description ends]

So let's just say Alice has her own local repo and, of course, Bob has his own copy as well. In the simplest of cases, these are the only two people working on the source code. And they have the ability to work independently on their own local versions. They will of course make changes and then record their changes in the form of commits to the local repositories. And there will come a time when they're ready to share their changes with the wider team.

[Video description begins] Screen title: Pushing Commits to the Origin [Video description ends]

When they do that, they will push their changes over to the remote repo. So you have the changes recorded by Alice, and those recorded by Bob as well. Once again, this is a rather simple scenario but in reality, Alice and Bob may be managers of a team which is scattered all over the world. In this case, the team members will not have access to Alice's local repo because that is only available on her own local machine. Each developer could, of course, create their own local repos, but this could potentially lead to dozens of independent copies of the repos. And collaboration will become much more complicated. Especially since the team managers will have no visibility into the changes being made until they are pushed to the remote repo. The problem then is to allow each of the team members to make their own contributions to the project while still being regulated by their managers. This is a more organized way of adding features to the project.

[Video description begins] Screen title: Branches [Video description ends]

And one way to handle this is to have separate branches for each team. So each developer will still work on independent local repositories. But instead of pushing their commits directly to the remote repo, they will push them first to a branch. To understand how this works though. Consider that what we have been referring to so far as the remote repo is in fact the master branch of the remote repo. So you are now about to add another layer. And for that, we will visualize a branch as a series of commits. So let's just say we have the master branch in this case and this of course contains the initial commit of all of the source code. At some point, developers will make changes to the source. And then record these changes on the master branch. And as more and more time goes on, there will be a lot of changes and each of these will be recorded as a commit on the master branch. So at this point, when we have three changes beyond the initial commit, let's just say Alice and Bob begin work on their projects. Each of which involves adding a new feature to the source code. And since they also wish to collaborate with team members who may be scattered all over the world. They don't create local repos within their own workstations. But instead, create branches on the remote repo. Each of these branches, alice_branch and bob_branch, exists alongside the master. And at this point, they contain the exact same source code.

[Video description begins] Screen title: Working on Separate Branches [Video description ends]

Individual developers then will not clone the local repo from the master branch. Rather, their clones will be derived from their respective feature branches. The reason this needs to happen is because each of the developers will record their commits and push them over to the feature branches. And not directly to the master. As team managers, Alice and Bob will then be able to view all of the changes made by their developers. And significantly if any new developer were to join either of the teams. They will be able to pick up all of the changes made by their team members by cloning the feature branches, rather than the master. After some time though, a number of different commits will have been recorded on each of the feature branches. And then of course, the contents of each of these branches can vary significantly from the master. In order for the master branch to get all of the changes which have been made in the feature branches. Those branches need to be merged with the master. So this is where the merging part of branching and merging comes into the picture.

[Video description begins] Screen title: Merging [Video description ends]

The way it works is that all of the commits which have been recorded on one of the feature branches will be pushed over to the master. So if Alice's team have recorded three commits to this feature branch. Once they merge with the master branch, all of those three commits will be pushed to the master. And the same will occur when Bob's team merges their branch over to the master as well. Once this happens, well the master branch will now have all of the commits recorded for each of the features. So by adding this layer of branching and getting development teams to work of branches rather than directly of the master. Two things have been accomplished. Alice's and Bob's teams have been able to work independently of each other. However within those teams, they have been able to collaborate. And in the end, the master branch gets all the changes. One thing to note is that if you happen to use a service such as GitHub. Merging one branch into another involves something known as a pull request. This is a convenient way to view the differences between two branches before they are merged together. Now one thing we have been assuming with this merging of branches is that Alice's and Bob's features are completely independent of each other. However, realistically it is possible that there will be a conflict during the merge. This happens if Alice and Bob's teams make changes to the same file in the project. And as an example, consider that they're both working on the tea recipes.

[Video description begins] Screen title: Merge Conflicts [Video description ends]

Each of them has different version for line 3 of the same file. So clearly, they're not aligned in terms of what the contents of this file should be. Now let's just say Alice's team happened to merge their changes over to the master branch first. And this is followed by Bob's team trying to do the same. Well what happens in this case is that Bob will be prevented from merging his branch over. Due to what is known in Git terminology as a merge conflict. Since Alice and Bob have conflicting versions of the same file. The only way for Bob to be unblocked in this case is for this merge conflict to be resolved.

[Video description begins] Screen title: Resolving Merge Conflicts [Video description ends]

So how exactly can this be done? Well, the answer is that there is no single solution. One thing to do is for Bob to accept the changes made by Alice's team and then disregard his own team's modifications. Alternatively, Bob and Alice may decide that Bob's team's changes need to take precedence. And that is the final version which will appear in the master. Alternatively, of course, they can work out some kind of compromise. The specific system which is adopted can vary with each organization or team. And if you'd like help with resolving merge conflicts, there are a handful of tools which are available for it. At this point, you have a good grasp of the concepts around Git as well as some of its features. In the next video, we will take a look at what exactly GitHub is and how it fits in with Git.