Alexander Litvinov <litvinov2004@xxxxxxxxx> wrote: > Can somebody explain the meaning of next and pu branches Within git.git: maint: Current stable release. Receives bug fixes for the current release. master: Stable development tip. The tip of this branch will be used to create the next stable release. next: Topics which are pretty stable and are likely to be merged into master soon are merged here first, to make them visible to a wider community and get more testing. pu: aka "Proposed Updates". Junio publishes a number of branches here and continously rebases this branch. Topics here may make it into next (and then later master), or may not and just be dropped forever. >and some documenation > about using topic branches. What about Documentation/howto/using-topic-branches.txt ? > My development model use two branches now: stable release and develment > branch. All changes in the stable release branch are bug-fix only changes. > All (or most) of them must go to development release. Now I do this using > cherry-pick but it is not easy to track what was merged especialy when merge > pruduce confic resloved by hands. Stable branch live long life, much more > than 100 commits. > > It seems topic branches can help me here, but reading Documentation under git > sources teach to make topic branch from the branch point and then merge it to > both branches. This can work while stable branch has short life and was not > heavily rewritten. > > If there any technique that can help me ? The easiest way to do this is to create a new topic branch from the merge base of the two branches (see git-merge-base's docs for details). Make the fix on this branch, test it, then merge it into your development branch. If additional changes are needed, go back to the topic branch, fix it there, then remerge the topic to your development branch. When the topic is finally ready, merge it to your stable branch. This is what the documentation suggests, because it works, and works well. This is how Junio manages `next` (which is the same as your development branch) and `master` (which is about the same as your stable branch). You can let git-rerere help you to manage conflicts which might reoccur during merges. If you create the .git/rr-cache directory then git-commit and git-merge will automatically use git-rerere to help you. If you are cherry-picking stuff back and forth this gets really hard, as you point out. The tools don't help you very well here, as there isn't enough data to figure out what is where. You can try using git-cherry to tell you which commits are in both branches, but it has limited usefulness if the commits are making different changes. -- Shawn. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html