5 ms·

My Git Workflow

142 points by PStamatiou 18y ago

arockwell 18y ago
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 18y ago
  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 18y ago
    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 18y ago
      I've lost code with stash. Be wary.
- globalrev 18y ago
  I didn't catch how, could you explain?
  - arockwell 18y ago
    Rename 'origin' to 'github' in .git/config. This is from the 'ENLIGHTENMENT' section in the article.
    - lnguyen 18y ago
      Or just run the command git branch -m origin github
      - lnguyen 18y ago
        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.
- deleted 18y ago
  [deleted]
almost 18y ago
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 18y ago
  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.
- lnguyen 18y ago
  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.
wheels 18y ago
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 18y ago
  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-ness-git-rebase-interactive http://blog.madism.org/index.php/2007/09/09/138-git-awsome-n...
  - jmtulloss 18y ago
    Dude, that's awesome. You made my day.
  - meqif 18y ago
    If someone else is lazy like me, you can put the following in your ~/.gitconfig [alias] magic = rebase -i HEAD~10 Then you can just use 'git magic' instead of writing the full command.
    - silentbicycle 18y ago
      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-rev-parse.html 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.
tlrobinson 18y ago
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.
bprater 18y ago
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.
tdavis 18y ago
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 18y ago
  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.
sh1mmer 18y ago
I'd also recommend reading the "Git for computer scientists" linked in this post (http://eagain.net/articles/git-for-computer-scientists/ http://eagain.net/articles/git-for-computer-scientists/).

142 points by PStamatiou 18y ago

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 18y ago
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 18y ago
  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 18y ago
    I've lost code with stash. Be wary.
globalrev 18y ago
I didn't catch how, could you explain?
- arockwell 18y ago
  Rename 'origin' to 'github' in .git/config. This is from the 'ENLIGHTENMENT' section in the article.
  - lnguyen 18y ago
    Or just run the command git branch -m origin github
    - lnguyen 18y ago
      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.
deleted 18y ago
[deleted]

almost 18y ago

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 18y ago
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.
lnguyen 18y ago
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.

wheels 18y ago

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 18y ago
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-ness-git-rebase-interactive http://blog.madism.org/index.php/2007/09/09/138-git-awsome-n...
- jmtulloss 18y ago
  Dude, that's awesome. You made my day.
- meqif 18y ago
  If someone else is lazy like me, you can put the following in your ~/.gitconfig [alias] magic = rebase -i HEAD~10 Then you can just use 'git magic' instead of writing the full command.
  - silentbicycle 18y ago
    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-rev-parse.html 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.

tlrobinson 18y ago

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.

bprater 18y ago

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.

tdavis 18y ago

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 18y ago
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.

sh1mmer 18y ago

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