I've never noticed that before, but it's possible that you both had added functions in different places:
foo() ... ; original
bar() ... ; added by alice
foo() ...
foo() ...
bar() ... ; added by bob
I haven't tried it, but I could imagine that being seen as separate text additions, and ending up with duplicates if git thinks it needs to merge them:
bar() ... ; alice
foo() ... ; original
bar() ... ; bob
You mentioned using `git pull`, which will actually merge things if it thinks it's necessary -- which can lead to tree differences. In practice, I've found it helpful to NEVER USE `git pull`. Rather, I advise using:
This will ensure that git only does "fast-forward" merges, and does not end up accidentally merging things - and keeps 'origin' as the system-of-record for what's been merged.
Yes, ff-only will fail. If C,D are independent and simple, I would go ahead and rebase, otherwise do a proper merge.
Remember you can play a lot with git; if you are not sure how it will turn out, checkout a commit (e.g. git checkout origin/master), create a new throwaway branch (git checkout -b tmp), then you can do rebases, cherry-picks, merges etc., then do "git log tmp" or "git log -p tmp" to see how does the branch look. If you are unhappy, you can always throw it out (git branch -D tmp), it won't affect anything else.
I generally avoid the situation when a branch and origin diverges. The flow I have in my work is: If I need to make a small change (few lines), I pull, do changes, commit and push directly to master; if there are any intervening independent changes, pull --rebase. For anything larger, I create a new branch, and commit there. Once it is ready, I give it to a teammate for code review and do automated build, if everything is OK he merges it to master. Other people generally don't push to my branch, and there is no A-B-C vs A-B-D situation.
If several people work together on the same branch, we coordinate actions face-to-face or via team chat, to avoid conflicts. We pull/push many times a day and the changes are small enough so there are no problems with rebasing in a topic branch. If two people make big conflicting changes to the same branch, it means trouble and we merge or even discard some changes.
Comments
I've never noticed that before, but it's possible that you both had added functions in different places:
I haven't tried it, but I could imagine that being seen as separate text additions, and ending up with duplicates if git thinks it needs to merge them: You mentioned using `git pull`, which will actually merge things if it thinks it's necessary -- which can lead to tree differences. In practice, I've found it helpful to NEVER USE `git pull`. Rather, I advise using: This will ensure that git only does "fast-forward" merges, and does not end up accidentally merging things - and keeps 'origin' as the system-of-record for what's been merged.I recommend
git config --global pull.ff only
instead, then you can use "git pull" without worries. Or,
git pull --ff-only
Anyone wondering what a "fast-forward" merge is? https://sandofsky.com/images/fast_forward.pdf
In the following scenario:
origin: A-B-C local: A-B-D
What is the recommended action? git pull --ff-only will fail, right? So should I be using git pull --rebase?
Yes, ff-only will fail. If C,D are independent and simple, I would go ahead and rebase, otherwise do a proper merge.
Remember you can play a lot with git; if you are not sure how it will turn out, checkout a commit (e.g. git checkout origin/master), create a new throwaway branch (git checkout -b tmp), then you can do rebases, cherry-picks, merges etc., then do "git log tmp" or "git log -p tmp" to see how does the branch look. If you are unhappy, you can always throw it out (git branch -D tmp), it won't affect anything else.
I generally avoid the situation when a branch and origin diverges. The flow I have in my work is: If I need to make a small change (few lines), I pull, do changes, commit and push directly to master; if there are any intervening independent changes, pull --rebase. For anything larger, I create a new branch, and commit there. Once it is ready, I give it to a teammate for code review and do automated build, if everything is OK he merges it to master. Other people generally don't push to my branch, and there is no A-B-C vs A-B-D situation.
If several people work together on the same branch, we coordinate actions face-to-face or via team chat, to avoid conflicts. We pull/push many times a day and the changes are small enough so there are no problems with rebasing in a topic branch. If two people make big conflicting changes to the same branch, it means trouble and we merge or even discard some changes.