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

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

Daily short news for you
  • For over a week now, I haven't posted anything, not because I have nothing to write about, but because I'm looking for ways to distribute more valuable content in this rapidly exploding AI era.

    As I shared earlier this year, the number of visitors to my blog is gradually declining. When I looked at the statistics, the number of users in the first six months of 2025 has dropped by 30% compared to the same period last year, and by 15% compared to the last six months of 2024. This indicates a reality that users are gradually leaving. What is the reason for this?

    I think the biggest reason is that user habits have changed. They primarily discover the blog through search engines, with Google being the largest. Almost half of the users return to the blog without going through the search step. This is a positive signal, but it's still not enough to increase the number of new users. Not to mention that now, Google has launched the AI Search Labs feature, which means AI displays summarized content when users search, further reducing the likelihood of users accessing the website. Interestingly, when Search Labs was introduced, English articles have taken over the rankings for the most accessed content.

    My articles are usually very long, sometimes reaching up to 2000 words. Writing such an article takes a lot of time. It's normal for many articles to go unread. I know and accept this because not everyone encounters the issues being discussed. For me, writing is a way to cultivate patience and thoughtfulness. Being able to help someone through my writing is a wonderful thing.

    Therefore, I am thinking of focusing on shorter and medium-length content to be able to write more. Long content will only be used when I want to write in detail or delve deeply into a particular topic. So, I am looking for ways to redesign the blog. Everyone, please stay tuned! 😄

    » Read more
  • CloudFlare has introduced the pay per crawl feature to charge for each time AI "crawls" data from your website. What does that mean 🤔?

    The purpose of SEO is to help search engines see the website. When users search for relevant content, your website appears in the search results. This is almost a win-win situation where Google helps more people discover your site, and in return, Google gets more users.

    Now, the game with AI Agents is different. AI Agents have to actively seek out information sources and conveniently "crawl" your data, then mix it up or do something with it that we can't even know. So this is almost a game that benefits only one side 🤔!?

    CloudFlare's move is to make AI Agents pay for each time they retrieve data from your website. If they don’t pay, then I won’t let them read my data. Something like that. Let’s wait a bit longer and see 🤓.

    » Read more
  • Continuing to update on the lawsuit between the Deno group and Oracle over the name JavaScript: It seems that Deno is at a disadvantage as the court has dismissed the Deno group's complaint. However, in August, they (Oracle) must be held accountable for each reason, acknowledging or denying the allegations presented by the Deno group in the lawsuit.

    JavaScript™ Trademark Update

    » 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.

initial git tree

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.

git tree after rebase

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

git tree after merge

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".

attempt to rebase feature onto develop

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
Hello

The secret stack of Blog

As a developer, are you curious about the technology secrets or the technical debts of this blog? All secrets will be revealed in the article below. What are you waiting for, click now!

As a developer, are you curious about the technology secrets or the technical debts of this blog? All secrets will be revealed in the article below. What are you waiting for, click now!

View all

Subscribe to receive new article notifications

or
* The summary newsletter is sent every 1-2 weeks, cancel anytime.

Comments (0)

Leave a comment...