Re: Questions about branches in git

[David Aguilar <davvid@gmail.com>]

On Thu, Jan 28, 2010 at 05:04:36PM -0500, Nicolas Pitre wrote:
> On Thu, 28 Jan 2010, Mike Linck wrote:
> 
> > Well, even gitk can't show me the information I'm looking for if the
> > parent branch ended up fast-forwarding to include the changes made in
> > the topic branch.  As far as I can tell there is *no way* to tell what
> > changes were made in a particular branch after a fast-forward has
> > taken place, which seems to make it hard to organize fixes for
> > specific topics/bugs/tickets.
> 
> You should consider using tags in conjunction with your bugs/tickets 
> system.  The fork point for a bug fix may be tagged, as well as the last 
> commit representing the bugfix completion (not the merge point though).  
> This way you can always retrieve the exact set of commits forming up 
> that bugfix, regardless if it was merged back into the main branch with 
> a fast forward or not.
> 
> 
> Nicolas

Tags, combined with --no-ff, should help you out a bit.
If you're worried about devs forgetting to configure the no-ff
then you might be able to help them out if you have any control
over /etc/gitconfig on their systems.  That gives you a
standard, global way to set defaults.

This table gives a great summary of 'git log' commands for
inspecting branches.

http://book.git-scm.com/3_reviewing_history_-_git_log.html


As far as "what's the way to do branches right in git" then
there is no "one single way" because git is a framework upon
which you can build your ideal workflow.  That said, there are
some very good examples to follow.  For example, there is much
that can be learned by studying how git.git's branches are
managed.

http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html

This webcast covers a few more workflows and is a very good
crash course:

http://www.gitcasts.com/posts/railsconf-git-talk

-- 
		David