On Wed, 25 Dec 2013 21:28:36 -0800 (PST)
prashanna rana <prashannajab...@gmail.com> wrote:

> I've a stable released version i.e version2.0  and a master for
> future version release say v3.0.
> version2.0 doesnot have some features of master. when i found bug in 
> version2.0 then i create a branch under version2.0 say v2.0-bug-fix1.
> while merging this v2.0-bug-fix1 branch to version2.0 is ok no
> conflicts. but at the same time i also want to merge that
> v2.0-bug-fix1 to master because that bug needs to be fixed in master
> as well, i get conflicts i resolved that for 1st time its ok but for
> every bug of version2.0 there will be a v2.0-bug-fix-xx branch and on
> merging that to master every time the same conflicts will arises. Is
> there a better way to handle this or i've to always resolve conflicts
> manually. cause i don't want to replicate master's snapshot in
> version2.0 its stable release. 

Most probably you want cherry-picking (see `git cherry-pick`) and not
merging.  The difference is that merging is essentially an act of
bringing *all* the changes done on a line of development into another
line since the last point they diverged, while cherry-picking is simply
applying one (or more) *independent changesets* (extracted from selected
commits) onto HEAD.

Of course, it might turn out that your code bases diverged so much even
cherry-picking would provoke merge conflicts.  There's no real solution
to this.  Either fix bugs on the maintenance branch by hand or try
using `git rerere` which is able to memorize how you resolved your
merge conflicts the last time and apply this strategy the next time
you're merging.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to