Git is a the most popular version control system in the software engineering world. Its popularity grown even bigger with the raise of Github, Gitlab, Bitbucket and similar tools. When you think about software development Git is a crucial part of it, you just can’t live without it if you’re doing it professionally.
Background
Imagine you’re working on some big feature that requires a lot of time to implement it properly. In the meantime your team members are developing their own tasks. They get reviewed and merged to to the branch: master, main, develop - you name it (I'm going to refer to it as a source branch later in the text).
At some point you realize that it would be good to update your working branch with the latest changes from the source branch. It can be tempting to do it by either running git merge <source-branch-name>.
Update with merge commit option. After doing it the list of commits is increased by a number of merge commits.
Notice, there are commits starting with Merge branch ‘develop’ into … those are the merge commits, but if you take a look at the branch history on Git it looks even more messy.
In the Github UI there are 12 commits, but when you’re looking into the Git history you can see there are 19 commits in total.
Git merge is a bad idea
You might be wondering what’s the problem there? IMO, it’s bad because it messes up your work with someone else’s work. Mixing commits leads to confusion when trying to find a specific commit that introduced a specific bug or trying to squash all your commits into one with git rebase -i HEAD~<number-of-your-commits>.
In general, your work should be always on top of the source branch commits so you can easily find out what does your work contain and, what’s more important, you can have a flat commits history in your branch. In the last picture there are 3 levels of commits caused by using git merge. Which can be problematic to read sometimes. More nesting levels mean more complex graphs to read and to understand the history of changes.
Using git rebase will help you:
- To have a clear list of changes in your repository. You’ll know what change is an effect of another.
- To have a linear history of changes. No nested levels of commits making it difficult to read.
- To debug your code easier with
git bisect. This command is really cool to find the exact commit that broke the code. With that you can mark which commits are good and which are broken. You can read more about it here: https://git-scm.com/docs/git-bisect
What can you do instead?
To learn more about what can you do instead go to the full version of this article.
Top comments (0)