简体   繁体   中英

Git merging master to branch - conflicts (coming from Subversion background)

Subversion Background:

We are transitioning from Subversion to Git .

We used Subversion trunk to be our "gold copy", create long-running feature branches, and we would merge trunk to branch many times.

Finally when the feature was complete, we would merge the branch back into trunk .

When we did this, if Bar.java was modified in trunk , but we never modified it in the branch, we would never get merge conflicts on Bar.java .

I believe this is because Subversion has a concept of svn:mergeinfo , and knows about the history of the merges and that Bar.java was never modified in the branch.

SVN Branch Maintenence Diagram:

SVN分支维护图

Git Behavior:

Now that we have transitioned to Git , we are getting conflicts on merging master to the branch, even if we did not change Bar.java in the branch!

I believe this is because Git does not have the same notion of svn:mergeinfo and does not keep track of the fact that Bar.java changes came over from master and were merged in.

Git Diagram (SHOWS ISSUE):

Git图(显示问题)

Question:

Is there any way we can continue using the same approach we used in Subversion (frequent merges of trunk to branch) without getting conflicts in Git ?

Is there a way to implement an equivalent of svn:mergeinfo so that Git knows that a file only changed in master and never changed in branch , and merge automatically?

Although the example I illustrated is trivial (one file), realistically we have numerous developers working in parallel and end up dealing with numerous files conflicting, and this difference in behavior from svn to git is causing us a lot of pain.

Git does have analogue to svn:mergeinfo , in fact a much more advanced one. If you see merge conflicts on files you haven't touched in your branch that means either you did touch it somehow (automatic line endings conversion by IDE is a common pitfall), or somewhat has rewritten the history on trunk. Make sure that you guys don't do git rebase , commit --amend or similar history rewriting changes against the trunk ever.

Edit as for how do we search for mergeinfo

Standard git log would show you the merge info at the second line:

$ git log
commit 1ca56fefd6ed1af2a6e62f1fbd811d56fa72ded7 (HEAD -> master, origin/master, origin/HEAD)
Merge: a3323f6 2237297

Normally you use graphical representation at UI to see what has been merged and what not. At the command line git log --oneline --graph HEAD origin/master would show a subgraph containing your current workdir and origin/master for examination. git log origin/master --not HEAD would print you the commits that git assumes not yet merged from master to you current branch.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM