one of biggest surprises me while learning git fact revisions not permanently associated specific branch; rather, branch merely points particular revision. once i've internalised concept, realised don't understand how use feature properly.
i've read apparently famous essay a successful git branching model, depicts branches lines, , revisions being associated 1 line. consider excerpt:
this shows 2 feature branches (call them featurea , featureb), , develop branch. moreover, featureb merged develop , briefly diverged again, re-merged.
this looks nice, tidy , understandable, , happens repo literally @ end of process in mercurial. understand much, it, , i'd develop (and did, in mercurial). however, in git, final state doesn't that. looks this:
in other words, only information have 2 feature branches @ same revision develop branch. result, best can infer whole tree this:
in other words, nice information history of how development occurred lost; never recorded in first place. observe how in first graph, 3 revisions on featureb before merged develop, don't see how can know 3 revisions on featureb before merge.
is correct? above best can recover after-the-fact in git, , screenshot essay therefore rather misleading? or there important i'm missing?
yes, correct, 3 branches (pointers) refer same commit.
but git, more sequence of commits branch.
branch pointer in graph of commits, in order to:
- help local developer switch 1 or merge 1 another
- help publishing (pushing) upstream repo collection of commits (you don't push all branches default, 1 want public).
if need store "featurea" somewhere, in commit message, wouldn't necessary indicate branch: can cherry-pick commit, rebase branch, rename of delete branch (pointer) @ time.
in end, story told sequence of commits more important fact said commit belongs or belonged 1 or several branches.
Comments
Post a Comment