On Jul 19, 8:29 pm, Roddie Grant <gitl...@myword.co.uk> 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. > > 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. > > 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?
I, presonally, do not (yet) use any specific techniques for this, but several possibilities of storing some meta-information with Git comes to mind. First, is the simple usage of "annotated tags" -- tags which contain messages attached to them. For instance, having created your "cola_moss" branch and finalized the changes made on it, you could tag its tip with an annotated tag and write in the annotation why the branch was created (what feature(s) does it implement/what bug(s) does it fix) and so on. When the customer returns back to you with the results of testing the branch, you could just do `git show that-tag` and get the idea about what to do next. You could employ the fact Git stores tags in subdirectories if they contain slashes, so you could sensibly name such tags, like this, for instance: $ git tag -a pending/cola_moss When you have dealt with the branch, you can also remove any tags pertaining to it. As a variation, in such a tag you could just record a URL of a ticket in your project's tracker or of a wiki page describing the situation etc. Second, it's possible to "graft" a new empty tree onto an existing Git repository, and by "empty tree" I mean "a tree which shares no history with the rest of the repository" which differentiates it from "normal" trees which are created by the means of "forking" existing trees. Such a tree could be used to store any metadata in any format you like. In the simplest form this could be just a text file with certain notes. Creating such a tree looks a bit like voodoo but is in fact nothing special: $ git symbolic-ref HEAD refs/heads/meta $ rm * $ rm .git/index $ touch notes.txt $ git add notes.txt $ git commit -m "Create new `meta' branch" $ git branch master * meta Then, when you need to update any bit meta info about your repository, you check out that "meta branch", update it, then switch back. In any aspect, it behaves exactly as any other branch.  contains more background info on such branches. 1. http://madduck.net/blog/2007.07.11:creating-a-git-branch-without-ancestry/ -- 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 git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.