Public Git repo
Colin Law
clanlaw at googlemail.com
Mon Jan 10 11:13:06 EST 2011
On 10 January 2011 15:56, Jeff Kletsky <gnucash at allycomm.com> wrote:
> At least as I understand it, branches in git are nothing more than a pointer
> to the "head" commit and, structurally, are pretty much the same (if not
> identical) to tags. A branch in git is a tag on point in development that is
> moved to other commits if you commit "to" that branch. In simpler words, it
> is a tag that gets conveniently moved each time you commit. You really
> aren't "working on/in a branch" but are more moving what the notion of the
> head of the branch is. Yeah, it's really different from svn that way.
It may well be true that branches and tags in git are structurally
very similar, but in terms of operation they are completely different.
Git knows the difference and handles the concept of "working on" a
branch in virtually the same way as svn (as far as the user is
concerned). So one can create a new branch, make changes, committing
along the way. One can use gitk to give a graphical representation
showing the branch separate from other branches.
>
> While there is the notion of "parent" and "child" commits (which can be
> multiple) in git, one of the things that is different about git branches is
> that there is no notion of a "branch point" or a "branch history" the way
> there is in svn, for example.
Up to the point of merging there is effectively a branch point and history.
> Sure, as long as you don't merge the branch,
> you can determine where it diverges from another branch. However, once you
> merge, that gets dicey to impossible.
That is true, once a branch is merged into the master branch, for
example, it is as if the changes were made on the master. Personally
I have not found this to be an issue.
> As long as you don't really care where
> you came from and how, git branches are fine. They can take care of
> * most recent 2.2-Release version
> * most recent 2.4-Release version
> * most recent Stable version
> * most recent Current (bleeding-edge) version
One of the most useful features is the ability to setup local branches
(on ones local clone of the repository) for experimental work. Once
one is happy with the work then the changes can be merged into
whatever branch is appropriate on the master repository.
Colin
>
> Git tags are really the "static" things to take care of the concept of:
> * what are all the 2.2-Release versions?
> * what are all the 2.4-Release versions?
>
More information about the gnucash-devel
mailing list