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

Daily short news for you

Here! A question that I've been wondering about for ages, and until yesterday, everything was finally clarified.

Normally, people use height: 100vh to set the height equal to the viewport of the screen. On computers, there's no issue, and even simulating the size of a smartphone works fine. But when opened on a phone, height: 100vh always exceeds the viewport. Huh!? What's going on???

The explanation for this is that mobile devices have a different way of calculating the viewport compared to computers. It is often interfered with or affected by the address bar and navigation bar of the platform you are using. Therefore, if you want 100vh on mobile to truly equal the viewport, you need to take an additional step to reset the viewport.

It's easy, first, you need to create a CSS variable --vh right in the script tag at the top of the page.

function updateViewportHeight() { const viewportHeight = globalThis.innerHeight; document.documentElement.style.setProperty('--vh', `${viewportHeight * 0.01}px`); } updateViewportHeight(); window.addEventListener('resize', updateViewportHeight);
Then instead of using height: 100vh, change it to height: calc(var(--vh, 1vh) * 100). And that's it.

» Read more
Nowadays, how much memory will 1 million (1M) concurrent tasks consume? That is the question posed by hez2010, and he decided to find the answer by experimenting with a simple program in various programming languages: How Much Memory Do You Need in 2024 to Run 1 Million Concurrent Tasks?

To summarize, Rust remains unbeatable, but the second position surprised me 😳

» Read more
Is something coming? 😱🥶

» 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

Subscribe to receive new article notifications

or

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

Hello, my name is Hoai - a developer who tells stories through writing ✍️ and creating products 🚀. With many years of programming experience, I have contributed to various products that bring value to users at my workplace as well as to myself. My hobbies include reading, writing, and researching... I created this blog with the mission of delivering quality articles to the readers of 2coffee.dev.Follow me through these channels LinkedIn, Facebook, Instagram, Telegram.

Did you find this article helpful?

NoYes

Comments (0)