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.