Re: question concerning branches

From: Theodore Tso <tytso@mit.edu>
Date: Aug 19, 2009, 20:39 UTC
Message-ID: <20090819203917.GH27206@mit.edu>
In-Reply-To: <4a8c51f5@wupperonline.de>

On Wed, Aug 19, 2009 at 09:45:00PM +0200, Ingo Brueckl wrote:

Show 12 quoted lines

> Jakub Narebski <jnareb@gmail.com> writes:
> 
> > You finish old work (or stash it away), _then_ you begin new work.
> 
> Ok, this helps me a little bit to understand.
> 
> The branches aren't designed to split my work, but rather something to
> collect the different parts of my work.
> 
> But as software development often is something where you are coding on
> several issues at the same time which can't be committed immediately, it
> sounds that 'stash' is the developer's best friend.

Context switching has overhead; so it's usually better to try to complete one task before switching to another. Granted, sometimes it can't be done, but it's something you should really try to do.

Also, commits are easier to review if they are kept small; if you localize changes into separate commits, it's often easier to detet problems when doing "git bisect", for example. So if you are often needing to switch while leaving something that isn't ready to be committed, you might want to ask yourself if you are putting too many changes into a single ocmmit.

Personally, in the cases where I can't finish a commit before I need to switch away to another branch, my preference is to not use "git stash", but instead to create a topic branch, and then check in a partially completed change on the topic branch, which I can later ammend using "git commit --amend" (or if I have multiple commits on the topic branch, "git rebase --interactive"). This is because I can use the commit description to leave myself some notes about what still needs to be done before the commit can be finalized.

						- Ted