How to take remote master branch changes into local develop branch?

Question

I want to take update into my develop branch from master, what I tried to do is applying below commands:

 git checkout master
 git pull
 git checkout develop
 git rebase master

By executing the above commands I am getting below warning:

First, rewinding head to replay your work on top of it...

Also, I am not sure whether I should perform rebase or merge from master to develop. I referred a couple of articles online and in one it is suggested as

Rebases are how changes should pass from the top of hierarchy downwards and merges are how they flow back upwards. ( Link )

And in Microsoft Docs it is suggesting to rebase when(In example its showing rebasing develop onto master ):

A suggested approach is to allow rebasing local changes that you have made but haven't shared with others, but to merge once you are sharing changes with others. This avoids trouble with rewriting history while still letting you easily catch up with changes as you develop your code locally.

I would like to know the best approach to take the latest changes from master branch to develop branch.

Answer 1

In my humble opinion, unless you're a confident git user, git rebase (-i) , causes more issues than it solves.

Please note that, for example, neither GitHub nor Atlassian in their git flow tutorials use rebasing.

Of course git flow is just one approach and Atlassian in their Feature Branch Workflow article writes:

Once Bill is ready to accept the pull request, someone needs to merge the feature into the stable project (this can be done by either Bill or Mary):

 git checkout master git pull git pull origin marys-feature git push 

This process often results in a merge commit. Some developers like this because it's like a symbolic joining of the feature with the rest of the code base. But, if you're partial to a linear history, it's possible to rebase the feature onto the tip of master before executing the merge, resulting in a fast-forward merge.

I'm a merge commit proponent and I would encourage you to not use rebasing.

Answer 2

First, rewinding head to replay your work on top of it...

That is not a warning. That's normal output for rebase. If there's a warning, git will tell you so ( WARNING: like you'd see CONFLICT: ).

Note: Fast forward rebases aren't acutally doing any work - no merging, no rewinding of HEADS. So git doesn't output that line, even if you use git rebase

As for choosing between merge and rebase, it's convention in most scenarios. Follow the convention your team wants you to use - if they primarily rebase changes onto master, then do that.

If there's no convention handed down, do as your gut tells you to. Merge preserves order of commits according to time, clearly shows the divergence and then convergence, as it happened in real life. Rebase makes the history look seamless and clean (by editing history, hence why pulled-by-others branches shouldn't be rebased).

I try to use rebase. I like clean history - this person changed ABC, then I changed XYZ on top of it.

Answer 3

I would avoid rebasing. If you made some commits directly into master (not a great idea) and need to bring them to develop -

git checkout develop
git merge master