Re: need help adjusting workflow to git (or vice versa)

[Rob Browning <rlb@defaultvalue.org>]

Stephen Berman <stephen.berman@gmx.net> writes:

> I would be very surprised if either of these approaches is used by most
> developers using git, because if so, I'd have expected them to be part
> of the standard toolkit and well documented.  So I think my workflow is
> suboptimal for git.  What do people who have several branches of a
> single project repository and want to build from one of them without
> including changes from another in the build usually do?  Isn't that a
> common scenario, especially for Emacs developers?  What do you people do?

I don't know if this will help, but personally -- with git, in most
cases I only have one (or very few) clones, and I just switch branches
(a *lot*).

For example, if I were on say tmp/fix-foo, and I wanted to switch to
work on master, but I still had local changes that I wanted to come back
to later, I'd probably either use stash, or a trivial commit.

For example (via stash):

  $ git stash 'stuff I want to deal with later'
  $ git checkout master
  ... do whatever...
  $ git checkout tmp/fix-foo
  $ git stash pop

And now I'm exactly where I was (plus or minus any build detritus that
differs between the two branches.).

Though often it's more convenient to use an actual dummy commit since
git's stash is somewhat "one dimensional".  Here's the same thing via a
temporary commit:

  $ git commit -am 'stuff I want to deal with later'
  $ git checkout master
  ... do whatever...
  $ git checkout tmp/fix-foo
  $ git reset HEAD^  # "Undoes" the top commit, putting the changes back on disk.

And I'm again back where I was.

Some caveats:

  * If you have any new files, you'll need to "git add ..."  them before
    the "commit -am" or stash above, otherwise they'll be left out (and
    also be left alone in the current working directory).

  * If the build process isn't really solid (and even if it is), it may
    sometimes be helpful to run a "make clean" before you switch
    branches.  Alternately, you can use this command if you want to
    *completely* clean your tree -- likely more thoroughly, and possibly
    more quickly than via make:

      $ git clean -fdx

    But that deletes *everything* git doesn't know about, including
    ignored files, so be sure that's what you want.  You can see what
    it's going to do beforehand with the "-n" (--dry-run) option.

Note too that no working directory (copy) is more special than any
other, so if you have the disk space, you can always "cp -a" or rsync
your working dir before you do something you're uncertain about, and
move it back if things go horribly wrong (no one need ever know...unless
it's a push).

(Technically, if your working directory is clean, all you need is the
 .git subdir, but it's less complicated to save/restore the whole tree
 -- otherwise you may need a "get reset --hard HEAD" or similar
 afterward.)

Some other comments that might or might not be useful...

For what it's worth, I almost always work on a temporary branch.  It's
trivial to migrate the changes back to master (or wherever), via merge,
rebase, or cherry-pick, once I decide I'm ready to push.

I find gitk (--all) to be tremendously helpful as a tool to see what's
going on, and to see whether or not I did what I think I did, especially
when stumbling around unfamiliar bits of git.  Or, if you can't (or
don't want to) fire up a GUI, this may be useful:

  $ git log --decorate --oneline --graph

And as compared to "git status", if you want briefer status output,
perhaps

  $ git status -s  
  $ git status -s -uno
  
Another item in the category of "knowing what's going on" -- the fancy
git prompt component that Debian (at least) provides by default, i.e.:

      GIT_SHOW_DIRTYSTATE=true
      GIT_SHOW_STASHSTATE=true
      PS1='...$(__git_ps1)...'

Finally, I'd definitely recommend eventually learning "git rebase
--interactive ..." *for local use*.  I find it extremely useful.

(Note: I didn't talk about magit because I'm not using it heavily yet,
 but it's probably useful to understand some of the command line
 operations regardless.)

Hope this helps
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4