4 ms·

Merge commits are more than just a cosmetic issue. If you have merge commits from pulling master into your working branch you have broken the relationship of th

Merge commits are more than just a cosmetic issue. If you have merge commits from pulling master into your working branch you have broken the relationship of the commits which you just merged into your branch from master. Once you merge your branch into master, these changes you pulled in will now appear to be changes that were part of your branch. So say you have your branch, Sally's branch, and master. You create a branch from master, and then Sally merges her changes into master, and then you pull those changes in, when you merge your branch into master it will look like Sally's changes came from your branch. If something went wrong and you revert your merge all of Sally's changes get taken out of master. Yup. Not being able to do a clean revert of all the changes is just one problem with pulling master into your branch, another problem is being able to tell just what in the hell you are about to push to production. If you have merge commits your change diff may include all kinds of stuff already deployed, in which case you have to do a manual diff of the code deployed and what's in master instead of just relying on what the merge commit tells you. So please rebase.

kalms 13y ago
Keep a clear distinction between branches, and never do any clean commits to your develop branch, instead merge any feature (or hotfix) branches you might have with merge --no-ff. Basically, git flow is your buddy.
twic 13y ago
What? No. If Sally has already merged her commits into master, then those commits will never look like they've come from your branch. If i'm misunderstanding this, then a worked example would be a really great way of clarifying it.
- btipling 13y ago
  I believe you are wrong. The merge commit would make it look like her changes were in your branch. Try it out with a new repository. Create a new repo. Add some commits. Create Sally's branch, add commits to her branch. Create your branch from master, add some commits to your branch. Merge Sally's branch into master. Merge the updated master into your branch. Add some commits to your branch. Merge your branch into master. Revert your merge, and see, Sally's changes are no longer in master.
  - deleted 13y ago
    [deleted]

kalms 13y ago

Keep a clear distinction between branches, and never do any clean commits to your develop branch, instead merge any feature (or hotfix) branches you might have with merge --no-ff. Basically, git flow is your buddy.

twic 13y ago

What? No. If Sally has already merged her commits into master, then those commits will never look like they've come from your branch. If i'm misunderstanding this, then a worked example would be a really great way of clarifying it.

btipling 13y ago
I believe you are wrong. The merge commit would make it look like her changes were in your branch. Try it out with a new repository. Create a new repo. Add some commits. Create Sally's branch, add commits to her branch. Create your branch from master, add some commits to your branch. Merge Sally's branch into master. Merge the updated master into your branch. Add some commits to your branch. Merge your branch into master. Revert your merge, and see, Sally's changes are no longer in master.
- deleted 13y ago
  [deleted]