Sorry of you get multiple copies of this. I keep getting bounce messages. I messed up and sent a draft in my last response. I didn't want it to be more confusing, so, if you can.
Read me instead: >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's not required to keep 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... However doing so with pull (or fetch+merge)does the same thing, without the crazy flags or potential for really bad results. I am just saying that's not really what rebase is doing for us here so I am favoring the simpler approach. >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?
