>First of all, I use pull with the rebasing option to keep my work on top of >what the others already pushed until there's no issues for my local merges.
>that's not actually what rebase is doing. Rebase is rewriting the commit >history so it looks nice. It doesn't have anything to do with keeping changes >merged >Yes, it might have been an option but I preferred to rebase to make people to >get the habit of getting the others' commits before starting a working >session, making the eventual conflicts resolved first. That was my point too... I am just saying that's not really what rebase is doing >How would you have write it so ? I will write up something and post >I generaly do a "pull --rebase" + "git merge --no-ff" + "push" in the same >stream to avoid "git rebase -p", which, in case of conflict would make me >create an extra commit in more than the merge commit for the >same >feature/bugfix, with "rebasing first" solution, I can resolve the conflict, >rebase again and then have a merge up to date relative to the main stream. Okay, although honestly, that seems a little bit like running before we walk. All we are saving is, at most an extra commit to indicate the merge and forcing people to understand rebase. Understand what I mean?
