How select a file from one branch when resolving conflict during git rebase? -


given git repo 2 branches master , feature. when rebasing feature branch on top of master using rebase master lets file a.txt contains conflict needs resolved before rebase can continue.

i know can resolve conflict in 3 steps:

  1. open a.txt in editor manually resolve conflict
  2. call git add a.txt tell git have manually resolved conflict
  3. call git rebase --continue move rebase forward

is there way avoid step 1 telling git want version of file master branch or want version of file feature branch without having steps 1 , 2 above.

yes. in fact, there's more 1 way it.

the rebase , merge (and cherry-pick, matter) commands take same strategy , -x flags pass underlying git merge machinery. recursive strategy, -xours , -xtheirs choose 1 or other "sides" of files in case of file modified in both branches being merged.

or—this quite different—in cases when merge stops conflict, can use git checkout --ours or --theirs flags, pick version 1 side or other. (you can other commands; here, i'll stick --ours , --theirs these match arguments commands use merge machinery.)

this of course different because can switch choices:

$ git checkout main switched branch 'main' $ git merge branch ... conflicts in files , b ... $ git checkout --ours --    # takes main:a $ git checkout --theirs -- b  # takes branch:b 

note quite different "ours strategy" (the above shows "recursive strategy ours option"). "ours strategy", different occurs. let's start without it, doing same merge again:

$ git checkout main && git merge branch ... conflicts ... $ git checkout --ours -- b  # take main:a , main:b 

let's there's third file, c, git can merge on own. when above, git merges c , take main:a , main:b. if use git merge --strategy=ours branch, though, git take main:a, main:b, , main:c. discard branch:c changes rather automatically merging them.

i've used git merge above because makes "ours" , "theirs" stuff "work right". dislike way git names these, though, because when you're doing rebase, ours/theirs version swapped around, because rebase works changing "other" branch , doing series of cherry-picks. is:

$ git checkout mine; git rebase theirs 

works underneath doing (very) rough equivalent of:

$ git checkout theirs; git cherry-pick theirs..mine 

and afterward, shuffling branch labels around branch theirs not move. (it's not bad internally :-) manage make --ours mean "theirs" , --theirs mean "ours", pretty bad externally.)


Comments

Popular posts from this blog

php - regexp cyrillic filename not matches -

c# - OpenXML hanging while writing elements -

sql - Select Query has unexpected multiple records (MS Access) -