

My Git Workflow - PStamatiou
http://gweezlebur.com/2009/01/19/my-git-workflow.html

======
almost
It's really useful to see articles like this. With something like git it's not
good enough to just know how it works and how to use the commands. The real
power seems to come in learning the new working processes that let you take
advantage of its power.

I say this as someone who's just beginning to see the amazing possibilities
with quick branching. I've started working on all new features in their own
branches and it's really making my life easier. I used to do a limited form of
that in Darcs, but I just ended up with so many directories it got unworkable.
With Git it's all neatly tucked away and I have Emacs and my shell set to
always display the branch I'm working in so I never (ok, almost never) get
confused.

~~~
projectileboy
Agreed. I also agree with the author that Git feels weird if you're used to a
centralized VCS (e.g., Subversion). The fact that Git is respectful (for lack
of a better word) of your local file system leads to behavior that actually
makes perfect sense, but is nonetheless surprising coming from Subversion (as
a concrete example, the first time I created some new files and then ran git
reset --hard, I was surprised to see that my new files were still there
(because I hadn't yet added them)).

It's like the old saying that anyone can learn Lisp in a day, but it'll take
three days if you already know C. Anyone can learn Git in a day, but it'll
take three if you already know SVN.

------
bprater
For everyone writing articles like these, this is an excellent example on how
to get people into a technology.

Instead of giving them 15 commands to try to figure out, you hand them three.
When they get these three, you give them another situation and hit them with
more functionality.

Had I known that I could do most of my Git work with a couple commands, I
wouldn't have spent two days reading every last thing about Git I could find.

------
arockwell
That was worth reading to find out that I could rename origin to github. For
some reason I find the word origin really confusing.

There's a couple of other good tidbits in there if you're still a git neophyte
like myself.

~~~
lbrandy
For example, this bit:

# git stash (all my changes are saved away, and I have a clean tree)

# Fix the bug

# git commit -a -m "bugfix"

# git stash pop (changes are back)

This is the type of stuff that make SVN people "get it".

~~~
llimllib
I only do that if the "bugfix" is miniscule; I've forgotten stashes, and had
severely painful efforts to merge them back in. Now I only stash for a very
brief period of time.

Otherwise, I use a new topic branch instead of stashing. Branching takes so
little effort.

~~~
PStamatiou
I've lost code with stash. Be wary.

------
sh1mmer
I'd also recommend reading the "Git for computer scientists" linked in this
post (<http://eagain.net/articles/git-for-computer-scientists/>).

------
tlrobinson
Nice summary. When switching from Subversion I exclusively did his first
workflow, which is essentially treating git like svn ("it's like subversion
but you have to commit _twice_ ").

Recently I've been transitioning to a workflow a little more like his second
one, and I see the benefits, it's just hard to remember the commands and what
sequence they need to be executed in.

------
tdavis
My workflow involves a master branch for the dot-com site and two others for
some content-specific subdomains. Because of this, I find cherry-pick
absolutely wonderful.

Some good info in the article, though I think these comments have some better
stuff.

~~~
ivey
Yeah, I didn't do more than just mention cherry-pick, but that's really a
great way to show how different git is from SVN. There's no way to do that, or
anything close, with SVN.

------
wheels
I have to say I was hoping to see a little more magic in there. I've only been
using Git for two weeks, feel like I still don't have my head completely
around it, and the only thing covered I didn't know about was "stash".

~~~
ivey
Here's some magic, then. Say you've got a bunch of commits that you haven't
pushed yet, and you don't like the way you did them. You worked on one thing
for a while, fixed something else, worked on another thing, went back to the
first thing: it's a mess.

"git rebase --interactive HEAD~10" will bring up a $EDITOR window with the
last 10 commits listed. You can rearrange them, squash them into each other,
delete some entirely. Save the file, and git will happily rewrite history for
you.

See this blog post for a little more detail:
[http://blog.madism.org/index.php/2007/09/09/138-git-
awsome-n...](http://blog.madism.org/index.php/2007/09/09/138-git-awsome-ness-
git-rebase-interactive)

~~~
nikz
What is the big deal about keeping a clean history?

It's always seemed so much effort than it's worth.

Besides, isn't it better to keep a history of what _actually_ happened?
Something about being doomed to repeat it comes to mind...

~~~
lnguyen
Ideally what you want is a "useful" history, not an actual one. And by
"useful" I mean one where the changes in each commit are related to a
specific, self-contained update (feature addition, bug fix, etc.).

That way you can branch at any point in the commit history and be sure it'll
run cleanly or cherry-pick a change without having to remember everything that
it might depend on. And you get exactly what you want and nothing more.

