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.

Let's do it.

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

~~another way~~

$ git merge main [your-branch]

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.

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

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. 

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.

Comments

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

Git is a Communication tool

Jesse Phillips ・ Dec 12 '18 ・ 2 min read

#git

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