{"thread":{"id":"18413","subject":"keeping track of what a branch is for","startedAt":"2009-03-19T17:36:44Z","lastAt":"2009-03-19T19:46:50Z","messageCount":2,"participants":["E R","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"108553","messageId":"3a69fa7c0903191036u24bbf613had88dbebb24335c4@mail.gmail.com","threadId":"18413","inReplyTo":null,"subject":"keeping track of what a branch is for","fromName":"E R","fromEmail":"pc88mxer@gmail.com","sentAt":"2009-03-19T17:36:44Z","receivedAt":"2009-03-19T17:36:44Z","isPatch":false,"sender":{"key":"pc88mxer@gmail.com","avatar":null},"body":"Ok - here's another one...\n\nI've started to create a lot of branches (like one per feature I'm\nworking on), but I'm starting to have trouble keeping track of what\neach branch is for. Also, I'd like to keep track of a todo list for\neach branch.\n\nIs there a good way to keep track of these details with git? Using a\nrepository file kinda works except when merging back into the master\nbranch.\n"},{"id":"108568","messageId":"7vr60t8fdh.fsf@gitster.siamese.dyndns.org","threadId":"18413","inReplyTo":"3a69fa7c0903191036u24bbf613had88dbebb24335c4@mail.gmail.com","subject":"Re: keeping track of what a branch is for","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-19T19:46:50Z","receivedAt":"2009-03-19T19:46:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"E R <pc88mxer@gmail.com> writes:\n\n> Ok - here's another one...\n>\n> I've started to create a lot of branches (like one per feature I'm\n> working on), but I'm starting to have trouble keeping track of what\n> each branch is for. Also, I'd like to keep track of a todo list for\n> each branch.\n\nI have to admit that I do face this exact problem in managing git.git\nitself, which is an example of a topic-heavy project management, and I\ncannot say I have managed to solve it within the canned set of tools git\ngives, but the workflow I established makes it manageable, and it consists\nof three ingredients:\n\n (1) Name your (eh, \"my\") branch just like you name your function.\n\n     You probably learned in programming 101 course the importance of\n     giving a good name to your functions.  The same principle applies.\n     When I see kb/checkout-optim branch, I know it is about optimizing\n     the checkout command, and it came from Kjetil Barvik.  I can tell\n     that jc/maint-1.6.0-read-tree-overlay is about the bugfix to the\n     \"overlay\" feature of read-tree command, and the fix would apply as\n     far back as the 1.6.0.X series, not just the current maintenance.\n\n (2) I also use a few custom scripts (Meta/WC, Meta/git-topic.perl and\n     Meta/UWC) to manage \"What's cooking\" messages you see on the list.\n     Probably some of the computations git-topic.perl does can be more\n     generalized (it currently relies on the convention to name topic\n     branches with a slash in their names, and you have up to three\n     integration branches such as master, next and pu).\n\n     After accumulating new patches on top of topics and merging more\n     topics to integration branches (such as master and next), I run\n     Meta/WC which in turn runs Meta/UWC to read the last issue of \"What's\n     cooking\", and the raw material that should go in the next issue of\n     the message (generated by Meta/git-topic.perl), and the comments on\n     each topic in the last issue is merged to produce the draft of the\n     next issue.  I add further text to it to describe new deveolopment to\n     existing topics and comment on new topics before sending it out, and\n     another cycle begins.\n\n (3) I also have a custom script Meta/GRADUATED to cull topic branches\n     that have been merged to their final destination, and list possible\n     backporting for older maintenance series.\n"}]}