Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>What you are asking is a typically a <strong><a href="https://stackoverflow.com/questions/216212#216228">merge workflow</a></strong> problem: what to merge from where to where. </p> <p>But you also need to remember that in a DVCS, a merge will also be influence by <strong><a href="https://stackoverflow.com/questions/1039817/git-commit-frequency/1040502#1040502">publication considerations</a></strong> (are those branches pushed to local repositories, or public ones)</p> <p>"master" branch in particular is the one visible by default when someone clone your repo, meaning it should reference what you consider most useful to that user/developer. (since <a href="https://stackoverflow.com/questions/904353/unable-to-understand-git-branch-merge-and-rebase/905284#905284">other branches are not referenced locally by default</a>)</p> <hr> <blockquote> <p>1/ When I add some feature on release-2 and it should go to 3 as well, but not to 1</p> </blockquote> <p>You can indeed merge r2 to master, after having made a number of commits to r2 in order to achieve the necessary evolutions. That way, only a limited number of commits are visible in master, avoiding "commit cluttering".<br> For r3 however, you can cherry pick what you need from r2, if r3 is being pushed and published. Otherwise, you could rebase r3 on r2. See "<a href="https://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions/457988#457988">git workflow and rebase vs merge</a>" question</p> <blockquote> <p>2/ When I need to changes sth in all the versions, should I do it on master and cherry-pick it to all the branches?</p> </blockquote> <p>You should do it on r2, and then merge on master and r1 and r3. That way, only one commit is added to those branches.</p> <blockquote> <p>3/ Should I keep master up to date with the newest(release-3 branch) or rather developer on release-3 and merge to the master just before I will need release-4 branch?</p> </blockquote> <p>It depends on what you want your other colleague to see when they clone the repo.<br> But from 1/, I gather master is representing r2 (current development) and not r3 (future, long-term refactoring)</p> <blockquote> <p>4/ When I fix sth on release-1 or release-2, should I merge or cherry-pick it to master or rather?</p> </blockquote> <ul> <li>r1: cherry-pick: not all what you are fixing on r1 is meant to be merged to current development.<br> Actually, I would rather cheery-pick r1 fixed on r2, make sure everything work there, and then merge on master.</li> <li>r2: merge. If master represents r2, a simple merge is enough.</li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload