Simplify - How to Use Git Merge and Git Rebase Appropriately?

Daily short news for you

Privacy Guides is a non-profit project aimed at providing users with insights into privacy rights, while also recommending best practices or tools to help reclaim privacy in the world of the Internet.

There are many great articles here, and I will take the example of three concepts that are often confused or misrepresented: Privacy, Security, and Anonymity. While many people who oppose privacy argue that a person does not need privacy if they have 'nothing to hide.' 'This is a dangerous misconception, as it creates the impression that those who demand privacy must be deviant, criminal, or wrongdoers.' - Why Privacy Matters.

» Read more
There is a wonderful place to learn, or if you're stuck in the thought that there's nothing left to learn, then the comments over at Hacker News are just for you.

Y Combinator - the company behind Hacker News focuses on venture capital investments for startups in Silicon Valley, so it’s no surprise that there are many brilliant minds commenting here. But their casual discussions provide us with keywords that can open up many new insights.

Don't believe it? Just scroll a bit, click on a post that matches your interests, check out the comments, and don’t forget to grab a cup of coffee next to you ☕️

» Read more
Just got played by my buddy Turso. The server suddenly crashed, and checking the logs revealed a lot of errors:

Operation was blocked LibsqlError: PROXY_ERROR: error executing a request on the primary
Suspicious, I went to the Turso admin panel and saw the statistics showing that I had executed over 500 million write commands!? At that moment, I was like, "What the heck? Am I being DDoSed? But there's no way I could have written 500 million."

Turso offers users free monthly limits of 1 billion read requests and 25 million write requests, yet I had written over 500 million. Does that seem unreasonable to everyone? 😆. But the server was down, and should I really spend money to get it back online? Roughly calculating, 500M would cost about $500.

After that, I went to the Discord channel seeking help, and very quickly someone came in to assist me, and just a few minutes later they informed me that the error was on their side and had restored the service for me. Truly, in the midst of misfortune, there’s good fortune; what I love most about this service is the quick support like this 🙏

» Read more

Problem

After finishing a feature, we merge it into develop. The git merge command basically combines changes from one branch to another and can create an additional commit to mark the merge.

Recently, you have also heard about the git rebase command. Through research, you have found that it is also used to merge changes from one branch to another. The only difference is how git merge and git rebase create commit history.

However, you may have heard advice that if you are new, don't rush to use git rebase. While git merge is solving your problems well, continue using it. Honestly, I am not certain about using git rebase either, but I have a small tip that I would like to share with you in this article, hoping it will be helpful.

A Common Scenario

In practice, many projects have two basic branches: master and develop. The code in master is put into production while the code in develop runs in the development environment. (In reality, there may be more branches and it can be more complex, but I'm only using a basic example).

To develop a new feature, I check out from develop into a new branch and then start development on it. Branches can follow the rule feature/01, feature/02... with 01, 02... being the names of the features.

During development, there may be multiple features being developed concurrently and independently. What if you need changes from feature/01 to be incorporated into feature/02? Merge feature/01 into feature/02? Not bad! But if you continue doing that, your commit history may become messy. Instead, why not try this approach?

Principle: Always let develop serve as the intermediate branch between feature branches because ultimately the features have to be merged into develop. So, if you need changes from feature/01 into feature/02, merge feature/01 into develop, and then rebase feature/02 onto develop.

If you merge feature/01 directly into feature/02, the commit history will look like this:

Doesn't the git tree look more complex compared to the initial state?

The Golden Rule of Rebase

The golden rule of rebase is clearly stated in the article Merging vs. Rebasing. I will summarize it: never use rebase on a shared branch. In the above example, the shared branch is develop. Why? If we rebase feature/01 or feature/02 onto develop, the commit history on develop will be "rewritten".

As shown above, when we rebase feature/01 onto develop (Main in the image), the new commits of develop are added after the latest commit of feature. At this point, the develop branch has a "rewritten" commit history. Just imagine if multiple people are working based on develop from prior to this point. Performing merge operations in the future will cause many confusing issues.

Conclusion

In summary, merge is always sufficient. You don't need to know about rebase, and it's okay. But if you want to have a cleaner git commit history, you can try rebase. The golden rule is to never rebase a feature onto develop (never rebase on a shared branch). Only rebase feature onto develop, and vice versa, merge develop into feature.

References:

Premium

Me & the desire to "play with words"

Have you tried writing? And then failed or not satisfied? At 2coffee.dev we have had a hard time with writing. Don't be discouraged, because now we have a way to help you. Click to become a member now!

View all