Hello everyone, this is my first post, I hope there’s something wrong with it.
This week I had a heated argument with a project member about using git merge and git rebase. When the other side boycotts git rebase and considers git merge to be the ultimate weapon, I prefer using rebase (not boycotting git merge, of course). Too bitter, I went online to learn about git rebase and git merge so that I could explain to the other person that everything is born with a purpose. Just like a mosquito was born to be invented to kill mosquitoes.
That’s all that rambling, now I’ll dive into the main topic. What is Git rebase and git merge ? How does it work? When should git rebase be used? When should git merge be used?
1. Git rebase
Rebase, understood simply as its name implies, ie resetting the base for the branch. Suppose you have a branch feature/crawl_video_links checkout from the master branch as shown below:
And after feature/crawl_video_links had written some methods to call the API, the master branch was merged with another feature/library_call_api branch by a library geek:
And you see that the logic of this guy’s Api call is quite delicious and smooth, so what you have done so far has been successful. But never mind, if someone else’s is better, I’ll use it. Then you have to merge into your branch. But your branch still needs further development, now if you use git merge from master, your branch history will look like this
It doesn’t look very good, you want your commits to be seamless, not patchwork like that torn shirt. This is where rebase comes into play. You will pull from the master branch, and then rebase it on the feature/crawl_video_links branch.
1 2 3 4 5 6 | git checkout master git pull origin master git checkout feature/crawl_video_links git rebase master git push origin feature/crawl_video_links -f |
Now your commits are seamless. No one will know that you’ve been craving that guy’s library and merged it into your branch to use, you can smile and say: “That’s easy, it’s just available, so you don’t either. What needs to be rewritten?” Hehe
And so, the commits of each branch will always be seamless after merging into the master branch, making it easier for us to track the change process of that branch on the master branch.
2. Git merge
That’s the rebase, what about the merge? Merge, ie merge. That is, will take the changes of branch A and put them in branch B.
Sounds like a rebase, right? Then why not just use rebase? The problem is, with rebase, we won’t know when those commits were pushed to our branch at what point (the advantage is now a disadvantage). While with merge, the changes will be pushed directly after the last commit of that branch, in addition it will create an additional merge commit to mark the time of the merge again. Thanks to that, we won’t be able to hide our offense anymore
1 2 3 4 5 | git checkout master git pull origin master git merge feature/crawl_video_links git push origin master |
Rebase and Merge. When to use it?
Regarding the mechanism of pushing commits to another branch, there is also a different history. While rebase will do a merge code commit-by-commit, and when there is a conflict at any commit, it will stop and let you fix the conflict and then continue rebase, which is quite time consuming when there are a large number of commits. As for merge , it will collect all commits from the time of great-grandfather to descendants and pour it on your head. You’ll have to figure out for yourself which commit the conflict is from in your misery.
So when to use rebase and merge?
After everyone understands its mechanism of action, there is no need to say more about how to use it. Just say it anyway.
Với rebase, khi ở nhánh master có thêm commit mới, ta sẽ dùng rebase để thực hiện merge các commits mới này vào nhánh feature của mình.
Với merge, ta sẽ dùng khi muốn merge những commits từ feature vào master. Rất đơn giản và gọn gàng
There is 1 caveat with rebase. Because it repositions commits on the feature branch, its commits will have their commit ID changed. Also, using git rebase will always go with git push -f , so always remember pull both the master and feature branches back before doing the rebase to avoid missing code, and in that case you’ll have to spend a week trying to get the code to work. thinking about the upcoming direction. Luôn nhớ, luôn nhớ, luôn nhớ
Bonus with Git rebase
Suppose we have a problem like this, we checkout the feature from the master branch. But then, the boss said: “You’re dead, son, the main branch is the develop branch”. But the master branch has commits that develop does not have. Well, now committed to nearly a dozen files with a few hundred lines of edits. If checking out the new branch with develop and then compare also takes half a day. Boss mom.
Rebase will support this with options --onto . The syntax is as follows:
1 2 | git rebase --onto newBase oldBase feature |
In this case it would be git rebase --onto develop master feature . It will bring the feature commits back to develop’s HEAD, and the commits on master will fade
summary
Here’s a little insight into git rebase and git merge . Hopefully, after learning more about them, people will cherish them more, not boycott any of them, which is poor. If anyone has anything to say, please leave a comment. I would be happy to hear everyone’s input. I would like to thank you. Alligator(Arigatou)