DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Cover image for NOTES: Merge or Rebase
Erin Fox
Erin Fox

Posted on

NOTES: Merge or Rebase

Recently, I learned that merging a main branch, into your local working branch is a thing 🀯. I was shocked that I just learned about this in my 3+ years of being an engineer. BUT it's never too late to learn. (And take notes for when you forget).

Before, I would always copy/paste my rebase notes from my Notion into my terminal, cross my fingers with selecting the correct "accepting incoming" changes. "blue is you" theories, hope the correct version is added, continued and then force pushed. Sounds scary... but it worked!

From what I understand, merging main into your branch and rebasing from master results in the same goal: The latest most up to date code on your branch with your new feature code.

Merging sounds better to me. At least, it makes more sense, visually. Gelling together all the code, vs dumping it on top, feels better. I needed to learn how to gel instead of dump.

So, let's gel.

Here are my merge and rebase notes. Be aware that these work for me, and may not do exactly what you're hoping for. Chat with your team and do more research when you're learning this.

MERGING

Merging takes the content of the main branch and integrates it with your branch. Only your branch is changing.

Merge Master --> Feature Branch

Let's do it.

$ git checkout [your-branch]
$ git merge main

~~another way~~

$ git merge main [your-branch]
Enter fullscreen mode Exit fullscreen mode

REBASING

Rebasing takes the content of the main branch into a single "patch" and integrates onto your branch.

Apparently, rebasing incorrectly can unintentionally rewrite history. Which sounds really cool, but also like the climax of a bad time travel movie where everything goes bad because they talked to that person they weren't suppose to talk too and now everything is ruined.

For now, I'd like to not time travel until I understand it better.

It moves your entire branch on top of the main branch. It rewrites the project history by making new commits for each commit on your original branch.

Rebase feature branch into master

Let's do it.

$ git pull origin main
$ git checkout [your-branch]
$ git rebase main

--resolve your conflicts-- when you are resolving conflicts *DO NOT COMMIT*

save ****the changes from the conflicts 

$ git add

and then... 

$ git rebase --continue

:wq // or however you have your editor setup 

-- repeat until no more conflicts --
*EVEN if there are no conflicts 

$ git push origin [your-branch] -f
Enter fullscreen mode Exit fullscreen mode

Interactive Rebase

Now this just sound wild. Taking it a step further, interactive rebasing allows altering the commits as they are moved to the new branch. This gives you more control over your branch's commit history. I've heard you use this type of rebase when things are really harry.

Let's do it.

$ git checkout feature
$ git rebase -i master

This will then open the editor and list the commits that are about to be moved. 
This is where you can change the history, to make it look like how you need it. 
Enter fullscreen mode Exit fullscreen mode

Alright. So now we've learned there are 3 options:

  1. Merge

  2. Automation rebase ("regular")

  3. Interactive rebase

Which one should you use? Great question. I'm still figuring that out, but it starts with understanding each of your options, and the situation that you're in. Do you need to rewrite history? Or will a merge be quicker and all you need?

I believe it's best to chat with your team to hear their philosophies and approaches so everyone is on the same page. Hopefully, all y'all are not time traveling at the same time causing madness and talking to that person you're not suppose to talk to that changes the future.

Top comments (3)

Collapse
 
jessekphillips profile image
Jesse Phillips

There is definitely a different way of managing commits when you are working with rebaseing. The biggest thing is making atomic commits. This allows each commit to have a dedicated purpose and you don't have commits of 'attempts' creating chain of conflicts on the same code.

The other is frequently integration. You aren't building merge requests which are 20, 30 commits. You've already made two or three atomic commits, those can be merged to master.

There are times where merging master to a feature branch. But with the points above and frequently rebaseing it shouldn't be because the conflicts are too complicated.

Collapse
 
pke profile image
Philipp Kursawe

For Pull Requests I choose rebase. It does not clutter the commit history with merge commits. With gits "rerere" config its also not as painful as some people think it is anymore.

🌚 Life is too short to browse without dark mode