On Jul 19, 2010, at 09:29, Roddie Grant wrote:

> My recent brush with a forgotten stash has led me to consider again an issue
> which I've never really got a complete answer to - how much information (if
> any) about a project should be kept outside Git.
> IOW do developers keep a note (on paper, spreadsheet, database?) of how
> branches inter-relate, their purpose and so on.

yes - absolutely - for any sizable project, I typically have an issue tracker 
(redmine, jira, bugzilla, trac, whatever) and an open issue for every defect 
and planned unit of work (feature, etc).

Each feature has a branch for development (bugs have branches for resolution).
You need a branch per codeline you want to fix (eg. maintenance releases, 
current release, next release etc)

Branches are named to be self-descriptive (release and tag) and then named 
after the issue numbers.
eg b-issue-1234 -- this is a branch for dealing with issue 1234. You can 
quickly go to that issue for context, planning, delivery dates etc.

The interesting thing to note here is that the life of these branches depends 
on the intended integration date. It is a case by case call.
In all cases, the 'owner' of the issue or feature is responsible to ensure that 
the branch is tracking the changes on the main codeline as best as it can. 
Where possible, via a rebase, otherwise, by merging the mainline into the 
feature branch. Which works for you depends on what you are trying to 

When it is time to integrate back into the mainline, the branch is merged (or 
in the case of a rebase, potentially just fast-forwarded).

We don't delete these branches, since they capture the development history.

> An example: For a website I'm currently developing, the customer has asked
> me to make what is really a simple cosmetic change. I've done so on a branch
> called "cola_moss". But it could be several days or even weeks before the
> customer approves the change and the cola_moss branch can be merged with
> master. In the meantime, other development work continues on other branches.
> By the time I get back to the cola_moss branch I'll not remember what else
> was happening at the time it was created.

This is the whole 'keep it working'. Keep the changes as minimal as possible, 
one branch, one task, one change (functionally speaking) so the integration 
remains as clean as possible. If you anticipate a long life as a spur (prior to 
re-integration) regular merges from the original branch (or fast forwarding) 
are part of the overhead in keeping that spur alive.

By having a ticket / issue / bug open for the work, all commits and merges can 
be collected in one place so there is a single authority for the state of work 
on that issue.

> I've found some very useful stuff on line about workflow, but it's all about
> how to use Git, not how to record the process.
> So do developers generally just use the information obtainable from Git
> itself or do they keep external notes too; and if so, what do they look
> like?
> Thanks
> Roddie Grant

My 2 cents.

Alan Hawrylyshen
a l a n a t p o l y p h a s e d o t c a

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-us...@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to