The Thing About Git - The Diigo Meta page

• 23 Sep 09
  

  Damon Snyder

  git tutorial

• 17 Sep 09
  

  tosh .

  git dvcs atomic commits

• 13 Sep 09
  

  Yuri Baranov

  git development tutorial howto

• 18 Jun 09
  

  martin t

  git development howto versioning

• 15 May 09
  

  Vitaly Babiy

  Development Git

• 17 Feb 09
  

  Isk Aldur

  git

• 01 Feb 09
  

  Martin Carel
  • The Index is also sometimes referred to as The Staging Area, which makes for a much better conceptual label in this case. I tend to think of it as the next patch: you build it up interactively with changes from your working copy and can later review and revise it. When you’re happy with what you have lined up in the staging area, which basically amounts to a diff, you commit it. And because your commits are no longer bound directly to what’s in your working copy, you’re free to stage individual pieces on a file-by-file, hunk-by-hunk basis.
• 20 Jan 09
  

  Neil Saunders

  git rcs tutorial

• 16 Jan 09
  

  Chris Lasher

  "Git means never having to say, 'you should have'." A tutorial about teasing out logical commits in Git.

  for:third for:abml for:behindtherabbit for:gidrew82 for:hokietux for:jemerick for:jewdan for:nuin for:rvidal tutorial for:mndoci for:neilfws for:ramblurr reference scm git distributed for:dansullivanblk

• 10 Dec 08
  

  m k

  git

• 24 Nov 08
  

  drew Reece

  Staging and committing multiple changes

  git howto reference versioncontrol

• 19 Nov 08
  

  Antti Kaihola

  git tutorial scm commit partial

• 25 Sep 08
  

  Tabrez Iqbal

  git

• 22 Jul 08
  

  Stanton Teters

  How git has affected his workflow. Includes a bit of comparison to other source control tools.

  dvcs source-control scm programming development git delicious-import

• 09 Jul 08
  

  Adrian Bengtson

  General

• 20 Jun 08
  

  Jonathan Broad

  git introduction versioncontrol webdev distributed scm

• 10 Jun 08
  

  Matt M

  git tutorials

• 03 Jun 08
  

  Nigel Sim

  git

• 19 May 08
  

  Daniel Jomphe

  versioning versioncontrol comparison git learning

  • Version control systems have traditionally required a lot of up-front planning followed by constant interaction to get changes to the right place at the right time and in the right order. And woe unto thee if a rule is broken somewhere along the way, or you change your mind about something, or you just want to fix this one thing real quick before having to commit all the other crap in your working copy.
  • You can work on five separate logical changes in your working copy – without interacting with the VCS at all – and then build up a series of commits in one fell swoop. Or, you can take the opposite extreme and commit really frequently and mindlessly, returning later to rearrange commits, annotate log messages, squash commits together, tease them apart, or rip stuff out completely. It’s up to you, really. Git doesn’t have an opinion on the matter.
  • 22 more annotations...
  • • Git is quite different in this regard. You can work on five separate logical changes in your working copy — without interacting with the VCS at all — and then build up a series of commits in one fell swoop. Or, you can take the opposite extreme and commit really frequently and mindlessly, returning later to rearrange commits, annotate log messages, squash commits together, tease them apart, or rip stuff out completely. It’s up to you, really. Git doesn’t have an opinion on the matter.

    • I’ve personally settled into a development style where coding and interacting with version control are distinctly separate activities. I no longer find myself constantly weaving in and out due to the finicky workflow rules demanded by the VCS. When I’m coding, I’m coding. Period. Version control - out of my head. When I feel the need to organize code into logical pieces and write about it, I switch into version control mode and go at it.

      
      
      

      I’m not saying this is the Right Way to use Git: in the end, it all goes to the same place. I’m saying that this is the way I seem naturally inclined to develop software, and Git is the first VCS I’ve used that accommodates the style.

    • I've personally settled into a development style where coding and interacting with version control are distinctly separate activities. I no longer find myself constantly weaving in and out due to the finicky workflow rules demanded by the VCS. When I'm coding, I'm coding. Period. Version control – out of my head. When I feel the need to organize code into logical pieces and write about it, I switch into version control mode and go at it.

      
      
      

      I'm not saying this is the Right Way to use Git: in the end, it all goes to the same place. I'm saying that this is the way I seem naturally inclined to develop software, and Git is the first VCS I've used that accommodates the style.

    • The big problem here is models.rb - it’s “tangled” in the sense that it includes modifications from two different logical changes. I need to tease these changes apart into two separate commits, somehow.

      
      
      

      This is the type of situation that occurs fairly regularly (to me, at least) and that very few VCS’s are capable of helping out with. We’ll call it, “The Tangled Working Copy Problem.”

    • Git means never having to say, “you should have”
    • I run into The Tangled Working Copy Problem so often that I've devised a manual process for dealing with it under VCS’s that punt on the problem. For instance, if I were using Subversion, I might go at it like this:

    • The Index is also sometimes referred to as The Staging Area, which makes for a much better conceptual label in this case. I tend to think of it as the next patch: you build it up interactively with changes from your working copy and can later review and revise it. When you're happy with what you have lined up in the staging area, which basically amounts to a diff, you commit it. And because your commits are no longer bound directly to what’s in your working copy, you're free to stage individual pieces on a file-by-file, hunk-by-hunk basis.

      
      
      

      Once you've wrapped your head around it, this seemingly simple and poorly named layer of goo between your working copy and the next commit can have some really magnificent implications on the way you develop software.

    • Taking Control of Your Local Workflow
    • We want to commit all of the changes to synchronize-bookmarks and some of the changes to models.rb, so let’s add them to the staging area:
    • add bin/synchronize-bookmarks
    • add --patch models.rb
    • Stage this hunk [y/n/a/d/j/J/?]?

    • The magic is in the --patch argument to git-add(1). This instructs Git to display all changes to the files specified on a hunk-by-hunk basis and lets you choose one of the following options for each hunk:

      
      
      
      • y – stage this hunk
      • _n_ – do not stage this hunk
      • _a_ – stage this and all the remaining hunks in the file
      • _d_ – do not stage this hunk nor any of the remaining hunks in the file
      • _j_ – leave this hunk undecided, see next undecided hunk
      • _J_ – leave this hunk undecided, see next hunk
      • _k_ – leave this hunk undecided, see previous undecided hunk
      • _K_ – leave this hunk undecided, see previous hunk
      • _s_ – split the current hunk into smaller hunks
    • I like to review that the changes in the staging area match my expectations before committing:

    • I like to review that the changes in the staging area match my expectations before committing:

      
      
      

      $ git diff --cached
      [diff of changes in staging area]

    • git diff --cached

    • I also like to verify that my unstaged / working copy changes are as I expect:

      
      
      

      $ git diff
      [diff of changes in working copy that are not in the staging area]

    • Everything looks good, so I commit the staged changes:

      
      
      

      $ git commit -m "fix bookmark sucking problems"

    • git add --patch is actually a shortcut to features in git add --interactive, a powerful front-end for managing all aspects of the staging area. The git-add(1) manual page is a treasure trove of worthwhile information that’s often passed over due to the traditional semantics of VCS “add” commands. Remember that git-add(1) does a lot more than just add stuff – it’s your interface for modifying the staging area.
    • git commit --amend takes the changes staged in the index and squashes them into the previous commit. This lets you fix a problem with the last commit, which is almost always where you see the technique prescribed, but it also opens up the option of a commit-heavy workflow where you continuously revise and annotate whatever it is you're working on. See the git-commit(1) manual page for more on this.
    • And then there’s git rebase --interactive, which is a bit like git commit --amend hopped up on acid and holding a chainsaw – completely insane and quite dangerous but capable of exposing entirely new states of mind. Here you can edit, squash, reorder, tease apart, and annotate existing commits in a way that’s easier and more intuitive than it ought to be. The “INTERACTIVE MODE” section of the git-rebase(1) manual page is instructive but Pierre Habouzit’s demonstration is what flipped the light on for me.
    • There’s a section of the Git User’s Manual called The Workflow that describes, at a fairly low level, the various interactions between the working copy, the index, and the object database.
• 25 Apr 08
  

  Elijah Lofgren

  git versioncontrol scm programming vcs development svn tutorial toread

• 22 Apr 08
  

  Ben Damman

  git scm

• 14 Apr 08
  

  Derek Mahar

  git scm vcs version-control comparison tutorial article read

• 13 Apr 08
  

  geheimdienst

  vcs

• 

  Chu Yeow Cheah

  git

• 11 Apr 08
  

  Joel Bennett

  A good description of how Git is different than other version control systems -- makes me almost interested in using it.

  development sourcecontrol scm vcs git articles blogs

• 

  knowuh not saying

  vcs git article howto versioncontrol development programming source

• 09 Apr 08
  

  Marc Ordinas i Llopis

  Author describes nice feature in git, comments give nicer feature in bzr.

  versioning tool

• 

  kanzen zen

  Linux Development

• 

  Klaus Kämpf

  git blog

• 

  Pistos Christou

  git version control versioncontrol scm vcs source code tangled working copy

• 

  Jeremy James

  git versioncontrol development article

• 

  Kai Lautaportti

  Hunk based committing with git add --patch

  development git

• 

  Peter Morelli

  vcs

• 

  David narayan

  git development programming scm software

• 08 Apr 08
  

  Jack Baty

  git

• 

  Geraldo Medrano

  git scm subversion vcs

• 

  Scott Moody

  git subversion overview article tutorial howto

  • The thing about Git is that it’s oddly liberal with how and when you use it. Version control systems have traditionally required a lot of up-front planning followed by constant interaction to get changes to the right place at the right time and in the right order. And woe unto thee if a rule is broken somewhere along the way, or you change your mind about something, or you just want to fix this one thing real quick before having to commit all the other crap in your working copy.

    
    
    

    Git is quite different in this regard. You can work on five separate logical changes in your working copy – without interacting with the VCS at all – and then build up a series of commits in one fell swoop. Or, you can take the opposite extreme and commit really frequently and mindlessly, returning later to rearrange commits, annotate log messages, squash commits together, tease them apart, or rip stuff out completely. It’s up to you, really. Git doesn’t have an opinion on the matter.

  • If you took The Tangled Working Copy Problem to the mailing lists of each of the VCS’s and solicited proposals for how best to untangle it, I think it’s safe to say that most of the solutions would be of the form: ”You should have XXX before YYY.”

    
    
    

    • Subversion: You should have committed the experimental changes to a separate branch before working on the bookmark stuff.

    • Bazaar: You should have shelved your experimental changes before working on the bookmark stuff.EDIT: My mistake. bzr shelve solves exactly this problem.

    • CVS: You should have RTFM before wasting everyone’s time with such a lame question.

• 

  Avdi Grimm

  git vcs

  • Here’s a general principal I would like my VCS to acknowledge: moving from the present point B to some desired point C should not require a change in behavior at point A in the past. More simply, the phrase: “you should have,” ought to set off alarm bells. These are precisely the types of problems I want my VCS to solve, not throw back in my face with rules for how to structure workflow the next time.
• 

  Frank Colcord

  Ruby

Page Comments

• 
  Avdi Grimm on 2008-04-08
  Informative article about Git's workflow, or rather lack thereof.

Would you like to comment?

Join Diigo for a free account, or sign in if you are already a member.