Git Merge vs. Git Rebase

Both of these commands are designed to integrate changes from one branch into another branch—they just do it in very different ways.

When you go to merge your code there are a bunch of merge conflicts that you aren’t sure how to resolve. git rebase will move your new feature to the tail end of the new commits on master, creating one continuous flow of commits that should be conflict free, and replaces the need to merge.

Git how to merge

Let’s say you are currently working on branch feature/feature_a and you want to merge the changes made in another branch called feature/feature_b to feature/feature_a. The following commands should do the trick:

git checkout feature/feature_b
git pull
git checkout feature/feature_a
git merge feature/feature_b

Git how to rebase

I do think that merging is a little more elegant.

See this https://verdantfox.com/blog/how-to-git-rebase-mainmaster-onto-your-feature-branch-even-with-merge-conflicts

• Go to the branch in need of rebasing
• Enter git fetch origin (This syncs your main branch with the latest changes)
• Enter git rebase origin/main (or git rebase origin/master if your main branch is named master)
• Fix merge conflicts that arise however you see fit
• After fixing merge conflicts, git add FILE previously merge conflicted files
• Enter git rebase --continue (or git rebase --skip if git complains that there were no changes after resolving all conflicts)
• Repeat as necessary as merge conflicts arise in the subsequent commits
• Once the rebase is complete, enter git push origin HEAD --force

At Ericsson, I would do something like

git checkout -b branch_name origin/master

However, when I push, I actually am not pushing a branch.