git - Merging branch back with clean history -


i working on branch (with others) off of master.

a - b - c - f - g    (master)          \           d - e      (branch-a) 

periodically, merge master branch, minimize conflicts later.

a - b - c - f - g    (master)          \       \           d - e - h  (branch-a) 

eventually, want merge back.

a - b - c - f - g - - k - m - n  (master)          \       \       \     /           d - e - h - j - l - o    (branch-a) 

what cleanest way can merge master?

  1. i want preserve individual commits (i.e. no squash)
  2. i not use branch-a longer, commits hashes can change.
  3. i not include merge commits (e.g. h, l) merges without conflicts, if possible.

ideally, (assuming there no conflicts):

a - b - c - f - g - - k - m - n  (master)          \                     /           d  -  e   -   j  -  o 

any ideas on how should done?

(fyi, question workflow. if should have done else earlier, legitimate answer too.)


update:

after thinking more, realized not possible.

for example, if j changed line g changed, there not way history.

the next best choice have history:

a - b - c - f - g - - k - m - d - e - j - o  (master) 

essentially, rebase, omitting unnecessary merge commits.

you can hand branching off e , cherry-picking other commits new branch, merging master. rebasing possible, i.e. do

git rebase c 

on branch-a. however, take commits master , put them on feature branch.

git rebase -i c 

has same effect, allows skip commits no master , not required on branch-a. git cannot in general know whether commits interact in way (e.g. change 1 file might require change different file done on master), there's no fail-safe, automatic solution problem.


Comments

Popular posts from this blog

Android layout hidden on keyboard show -

google app engine - 403 Forbidden POST - Flask WTForms -

c - Why would PK11_GenerateRandom() return an error -8023? -