My Git Workflow(gweezlebur.com)
gweezlebur.com
My Git Workflow
http://gweezlebur.com/2009/01/19/my-git-workflow.html
26 comments
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.
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.
For anyone who wants to know more about branching and workflow processes, I'd recommend checking out the book Software Configuration Management Strategies and Rational ClearCase by Brian White.
Yes, I know it's a book on a commercial vcs and doesn't directly have anything to do with Git. But ClearCase with UCM has an equally powerful branching capability and in some ways is easier to use and manage (from a developer perspective). And there's probably at least 10 years of development and actual large-scale use behind it. It's good stuff, or at least the theory and workflows (just tune out the CC implementation parts).
FYI, my background was as a consultant in enterprise version control dealing with a number of different products: PVCS, Dimensions, Harvest, Starteam and ClearCase. All centralized and all working in completely different ways. I'd spent over three years on ClearCase architecting, implementing and managing a large-scale deployment before picking up Git.
Yes, I know it's a book on a commercial vcs and doesn't directly have anything to do with Git. But ClearCase with UCM has an equally powerful branching capability and in some ways is easier to use and manage (from a developer perspective). And there's probably at least 10 years of development and actual large-scale use behind it. It's good stuff, or at least the theory and workflows (just tune out the CC implementation parts).
FYI, my background was as a consultant in enterprise version control dealing with a number of different products: PVCS, Dimensions, Harvest, Starteam and ClearCase. All centralized and all working in completely different ways. I'd spent over three years on ClearCase architecting, implementing and managing a large-scale deployment before picking up Git.
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.
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.
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.
There's a couple of other good tidbits in there if you're still a git neophyte like myself.
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".
# 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".
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.
Otherwise, I use a new topic branch instead of stashing. Branching takes so little effort.
I've lost code with stash. Be wary.
[deleted]
I didn't catch how, could you explain?
Rename 'origin' to 'github' in .git/config. This is from the 'ENLIGHTENMENT' section in the article.
Or just run the command
git branch -m origin github
git branch -m origin github
Ooops... my bad should have been
git remote rename origin github
Had branches on the mind and didn't catch it till just now and the edit window is closed.
For the most part you can tweak most of the configs via command-line: git branch, git remote, or git config. I switch between those and editing the .git/config directly depending on the scope of the changes.
git remote rename origin github
Had branches on the mind and didn't catch it till just now and the edit window is closed.
For the most part you can tweak most of the configs via command-line: git branch, git remote, or git config. I switch between those and editing the .git/config directly depending on the scope of the changes.
I'd also recommend reading the "Git for computer scientists" linked in this post (http://eagain.net/articles/git-for-computer-scientists/).
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.
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.
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.
Some good info in the article, though I think these comments have some better stuff.
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.
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".
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...
"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...
If someone else is lazy like me, you can put the following in your ~/.gitconfig
[alias]
magic = rebase -i HEAD~10
Just keep in mind that it hardcodes the operation to the last ten generations of commits, which is not necessarily what you want. See "SPECIFYING REVISIONS" in the man page for git-rev-parse (http://www.kernel.org/pub/software/scm/git/docs/v1.6.1/git-r...) for all the different ways you can format the HEAD~10 part.
Then again, I have an alias "git cia" for "commit -a"... Just remember where to look it up if you need something more elaborate.
Then again, I have an alias "git cia" for "commit -a"... Just remember where to look it up if you need something more elaborate.
Be careful not to rewrite history you have already pushed.
I always use
I always use
git rebase --interactive origin/master
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...
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...
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.
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.
Because some people like to commit a lot...I once had a project where I committed after every red/green cycle. If specs were green and there was uncommitted code, I committed.
That's only useful for me, during tight development loops, not to a historian looking back at what I actually did. So before I push to others, I squash it to a changeset, possibly keeping all the commit messages in the single commit.
That's only useful for me, during tight development loops, not to a historian looking back at what I actually did. So before I push to others, I squash it to a changeset, possibly keeping all the commit messages in the single commit.
Dude, that's awesome. You made my day.
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.