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:
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):
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.