Alexander Litvinov <litvinov2004@xxxxxxxxx> writes: > Can somebody explain the meaning of next and pu branches and > some documenation about using topic branches. > > 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. I think what you are looking for is how my 'maint' and 'master' branches are maintained; 'maint' corresponds to your "stable release" while 'master' corresponds to your "develment branch". When a stable release is cut, 'maint' is forked from there. Truly obvious corrections will be applied on top of the tip of 'maint' directly, while if there are any doubt about a proposed change I might fork a topic off of the tip of 'maint' and cook the fix for a while until I finally merge it to 'maint'. This way, 'maint' will be "bugfix only since the last release". The tip of 'maint' will be merged into 'master', from time to time, to make sure that all fixes will be in 'master'. When it is time for a new release to be cut, I'd make sure that the tip of 'maint' is merged into 'master' (it usually is) and then the tip of the 'master' is tagged to be released. After a release is made, I could have two maintenance branches (one that continues on top of the old codebase, another that fixes the new release). A fix that can apply to both codebases will be applied to the maintenance branch for the old release and then its tip can be pulled into the maintenance branch for the new release and then its tip can further be merged into the development branch. At some point, the codebases for the older release and the current release become diverged enough that merging could become inpractical (the same bug may need different fix if the infrastracture has become different); you would need to bite the bullet and fix it twice (i.e. differently). - 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