is it ok to always git pull --rebase master branch

Question

We are a team working with git, we have a central repository (single origin) we use to push and pull from (and capistrano use it to deploy the branch master)

we make commits and deploy regularly (10~20 deploys a day), that means we have a lot of merge commit and git blame become a nightmare

I've read that to have a simpler history we can use git pull --rebase to avoid this. Is it a good idea to do always do this on the master branch?

if it is I'd like to suggest to set it in config with :

git config branch.master.rebase true

Is there any issue with this?

Answer 1

No problem at all. In fact that is preferred.

99% of the time it's better to rebase the changes in. If not, the developer can always abort the rebase and merge their changes manually.

The alternative (merging on pull) causes tons of little side commits and merges which don't contribute any meaning.

In general, I don't often see the point of merging local changes. It implies that there was something special about the exact revision that the developer started on and somehow rebasing to a different revision would cause a loss of information (maybe "I started this before Bob's feature and I want to communicate that in case it doesn't play well with Bob and I get blamed" or something...). This is rarely actually the case and a clean straight line commit history is a lot easier to follow.

Answer 2

Making pull rebase by default is OK (not necessarily a "good idea", not necessarily a "bad idea" either). You just need to keep in mind that it will in fact rebase your work. If you've made a series of commits that all depend on what was in the repo before Bob changed it ¹ , your rebase (on top of Bob's changes) may force you to fix up all those commits, when it might have been easier to fix up only the final merge commit.

I prefer to do this manually: run git fetch , and then git rebase or git merge depending on the situation, which I can discover once I have done the fetch.

There's an advantage to git pull --rebase (and/or setting branch.master.rebase true ) though, in that a "pull with rebase" is extra-smart and can handle some cases where the remote has done rebases too.

---

¹ "Bob" here represents anyone who made some change (and beat you to the push step) that causes your own changes to "have indigestion", as it were.

Answer 3

It's always fine pull.rebase in my expierence. If you don't want to have merge conflicts you can work in a local branch, and if you want to work with latest code you'll always prefer to have any uncommited changes before your current work is pushed.

Merging in a branch as a result of git pull is almost always meaningless, if merge would be meaningful branches should have been different (and merge explicit).

See also http://stevenharman.net/git-pull-with-automatic-rebase .

Answer 4

You should never rebase any revision that exists in other repository and might have another work based on it, because that work would than need to be rebased too.

If you push a branch and then rebase it, you will have to use -f option to next push. So if you never use that option, you never get in the problematic situation and can rebase freely. But if you push with -f , perhaps to a feature branch, then be careful not to rebase when other people may be working on that branch too or coordinate the rebase with them.

So for your own development work, by all means, rebase (and rebase -i and combine and split changes etc. to make them more logical). But if more than one person works on a feature, rebasing would need coordination which might no longer be worth it and rebasing published development branch is basically off limits.