Monday, July 25, 2011

Working with Git - Part 1 - Our initial experience

When Adku first opened shop, we used Subversion for source control. Since then, we’ve migrated over to the wonderful world of Git and wanted to share why we moved and some aha moments we’ve experienced along the way.

Why we moved to Git
  1. Speedy commits and updates, subversion commits got to be painfully slow - sometimes taking minutes
  2. Cheap local branching
  3. Better merging. e.g. merges follow renames and code moves
  4. Better support for file renames and file permission changes
  5. Interactive commits or the ability to commit partial files

Our aha moments
  1. A “commit” is essentially a diff with a pointer pointing to the commit we created a diff from
  2. A “branch” is a pointer that can be updated to point to any commit
  3. Deleting a “branch” is akin to deleting the pointer to that commit, if you have another “branch” (pointer) pointing to that commit, your changeset will NOT disappear
  4. A “remote” is a reference to a clone of this repository. This clone is usually hosted on another machine but it can also be another repository on your own hard drive.
  5. “git pull” is effectively the same thing as a “git fetch && git merge”
  6. “git fetch” is safe to re-run and does NOT update any files in your branch. It updates your knowledge of where the “remote” repository thinks it is.
  7. “git rebase origin/master” works by uncommiting all your commits in reverse order, updating your branch to origin/master, then replays your commits in order
  8. Your repository will continue to think a branch exists on a “remote” repository even if it was deleted by another developer. To remove branches that don’t actually exist on the “remote” anymore, you can run “git fetch --prune”

At the end of the day, we realized that these insights did not come cheaply. We invested a lot of time trying to understand Git and we recognized that we could not afford to have every new hire spending weeks getting up to speed on a version control system.

We ultimately decided to write bash scripts for the most common developer actions to help encapsulate all our Git knowledge and best practices. The culmination of that project is a development model we’re calling Dr. Git (Develop/Release with Git) which we’re excited to share in a following blog post.

4 comments:

  1. Actually... a commit is a snapshot, not a diff.
    But it *can be viewed as* a diff with the previous commit by simply diffing the two snapshot.

    It's better to think it as a snapshot because you'll not understand merge commit otherwise.

    A merge commit X is a commit with multiple parents commit, say A and B.


    A -----
    |--- X
    B -----

    The merge commit is a snapshot that is different from both the A and the B commit.

    if you *show* the commit X you can see it as empty if you had no conflict resolution or you'll see the conflict resolution only, but that's git presenting you with that information doing a three-way diff, X is a snapshot :)

    hope I clarify for the other readers too ;)

    ReplyDelete
  2. checkout http://gitboxapp.com/, it's a mac client, if you haven't. I'm a fan

    ReplyDelete