git checkout feature/mastering-git

Almost all the developers use git every day. It is amazing to see how git became a de facto so quickly. Despite of using git such a long time, I see many developers still struggling. I am also not apart. I also check Stack Overflow for some commands or a specific situation. The complexity is one part but there are so many variants in the practices, making it more error prone.

I will cover some of those challenges and will also provide some standard ways to make your life easy.

Merge vs Rebase

The most discussed topic is whether to use merge or rebase. But believe me, it should be a conscious decision. I will tell what happens if you don’t do it consciously.

Suppose if your team starts with two features, feature X and feature Y similar to the following image in Git

Here the green/red dots on the feature branches are the commits by the developers of the respective features whereas the develop has moved a single commit further after the branches are created.

Let’s assume that feature Y is completed first and merged into develop without rebase.

The square represents the merge commit. If feature X is merged without rebase now. It may look like

With two branches, you can see this much of overlap. Think of the team working on 10 different branches together. Let’s see what happens if we rebase the branches on develop before merging.

If you look at the dotted yellow line, that was the actual reference before rebasing. With rebase, git applies all the commits on the feature branch after taking the latest version of develop (Obviously it requires you to execute extra commands). If we continue merging the branch into develop and apply the same with feature X, the branches will change as following.

feature Y is merged into Develop

feature X is rebased on develop

There is no overlap at all, very clean to debug and fix any issues with the branches.

Now you know the difference. so, choose wisely.

If you want to go fast, go with merge,

If you want to go far, go with rebase !!

Using commands or UI based tools

Another challenge I faced is to have standard way of working in the team. There are different flavours of executing the actions like rebase; some prefer commands, the other use UI based tools. Undoubtedly there are really powerful UI based tools like Tower, Tortoise git, Source tree etc.

I personally prefer commands over UI. But for many it is difficult. I always used the flow chart to keep a git guide handy. You can also use it.

Most of the commands are covered in the flow for daily operations but there can be special cases still missed like squashing the commits.

Push with force

Never ever push with force but there are cases where we want to do it. When the branch is pushed with force, the history will be overwritten. The first checkpoint is push.default setting. Mostly it is set to “simple”. But it is good to check else you end up pushing all the branches.

Secondly, I prefer to use push force with lease. If you did not observe it in the flowchart, it is “git push — force-with-lease” command. Push force is a bit destructive. It overwrites the content unconditionally with remote repository. It can go wrong if another team member pushed in the meantime.

Fast Forward

You may have noticed in the flow chart that I used “git merge — no-ff”. I intentionally did that to prevent git from executing “Fast forward”

A fast-forward is when, instead of constructing a merge commit, git just moves your branch pointer to point at the incoming commit.

I prefer to read the history as it is and hence would always prefer to refer the commit as it was created as a part of different branch. I found a good illustration on another article once.

Summary

Git is obviously the best version control mechanism right now. But lack of knowledge can lead to big problems or too much efforts. I hope my tips and the flow chart will be tremendously helpful to you as well.