On Wednesday 12 March 2014 09:27:20 christopher_dearb...@dell.com wrote: > Disclaimer: I am not a github expert. > > Regarding branch lifecycle: > > 1. Work on the release being actively developed continues in a branch
After it was "split of" from the main development branch, yes. As long it is in maintained state. > 2. When that release is shipped, another branch is made so that active > development on the next release can continue in one branch, and critical > fixes can be made in the shipped branch only if needed This describes what happens with pebbles/roxy/stoney. The last one doubles as the development branch until it is declared stable. The a new branch is created which acts as the future development branch. The other (more popular) model is that there is a continuous development branch from which releases are forked on a regular basis (or at least based on the release master's will, if any). Despite we (as in SUSE) follow the first model, I at least have a preference for the latter. There are countless resources on the net that already discussed all the pros and cons. But I am not sure which model Dell is following. > It sounds like the recommendation for best practice is to convert the > shipped branch to a tag once that branch is no longer supported? To keep the overall number of branches low, yes. > Is there > a safe way to do this without risking losing the branch? A git tag is only a human-readable name for a specific commit. A branch is nothing different, it only brings some more tooling. You can always "git checkout $TAG" and create a branch again with "git checkout -b $BRANCH_NAME". > If a branch has 1 change in it that is not included in any other branch, > then it can't be converted to a tag can it? The branch only points to that very commit, so does a tag. However, a tag is only a human-readable name for a state in time. It doesn't provide the additional meaning of a branch (i.e. a common ancestor). However, this is implicit since every git commit has a parent relationship, which forms the tree. By simply looking at the git history of that specific commit, you can see that it's parent is an ancestor for other commits and hence, it's parent was a branching point. You can inspect this with: git log --graph --decorate --pretty=oneline --abbrev-commit --all Which is the command-line equivalent of tools such as gitk, qgit and whatnot. Simply add this to ~/.gitconfig to have it available as 'git lola': [alias] lola = log --graph --decorate --pretty=oneline --abbrev-commit --all -- Viele Grüße, Sascha Peilicke _______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
