keeping track of what a branch is for

keeping track of what a branch is for

[E R]

Ok - here's another one...

I've started to create a lot of branches (like one per feature I'm
working on), but I'm starting to have trouble keeping track of what
each branch is for. Also, I'd like to keep track of a todo list for
each branch.

Is there a good way to keep track of these details with git? Using a
repository file kinda works except when merging back into the master
branch.

Re: keeping track of what a branch is for

[Junio C Hamano]

E R <pc88mxer@gmail.com> writes:

> Ok - here's another one...
>
> I've started to create a lot of branches (like one per feature I'm
> working on), but I'm starting to have trouble keeping track of what
> each branch is for. Also, I'd like to keep track of a todo list for
> each branch.

I have to admit that I do face this exact problem in managing git.git
itself, which is an example of a topic-heavy project management, and I
cannot say I have managed to solve it within the canned set of tools git
gives, but the workflow I established makes it manageable, and it consists
of three ingredients:

 (1) Name your (eh, "my") branch just like you name your function.

     You probably learned in programming 101 course the importance of
     giving a good name to your functions.  The same principle applies.
     When I see kb/checkout-optim branch, I know it is about optimizing
     the checkout command, and it came from Kjetil Barvik.  I can tell
     that jc/maint-1.6.0-read-tree-overlay is about the bugfix to the
     "overlay" feature of read-tree command, and the fix would apply as
     far back as the 1.6.0.X series, not just the current maintenance.

 (2) I also use a few custom scripts (Meta/WC, Meta/git-topic.perl and
     Meta/UWC) to manage "What's cooking" messages you see on the list.
     Probably some of the computations git-topic.perl does can be more
     generalized (it currently relies on the convention to name topic
     branches with a slash in their names, and you have up to three
     integration branches such as master, next and pu).

     After accumulating new patches on top of topics and merging more
     topics to integration branches (such as master and next), I run
     Meta/WC which in turn runs Meta/UWC to read the last issue of "What's
     cooking", and the raw material that should go in the next issue of
     the message (generated by Meta/git-topic.perl), and the comments on
     each topic in the last issue is merged to produce the draft of the
     next issue.  I add further text to it to describe new deveolopment to
     existing topics and comment on new topics before sending it out, and
     another cycle begins.

 (3) I also have a custom script Meta/GRADUATED to cull topic branches
     that have been merged to their final destination, and list possible
     backporting for older maintenance series.