Menu
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?
889
I definitely suggest a daily master pull. It gives you a nice visual of all of the changes that have been made, and if you see a storm of +/-'s on files you're working on, then you better merge down since it's probably a refactor. If it's a small amount of changes on your files, just leave it alone.
At this point, you should prefer rebasing over merging to keep history tidy. If you've got your personal fork of the repository and that is not shared with other developers, you're safe to rebase even after you've pushed to your fork.
git pull --rebase commandThe main reason we do a git pull --rebase over git pull is because it avoids loops in the project history. For instance, the master branch has had many changes since you began working on your feature branch.
If you use pull requests as part of your code review process, you need to avoid using git rebase after creating the pull request. As soon as you make the pull request, other developers will be looking at your commits, which means that it's a public branch.
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.
88
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 it1, 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.
1"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.
39
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
