Effective Git Work flow

Linus Torvalds has quipped about the name git, which is Irish slang for a child born out of wedlock, and British English slang for a stupid or unpleasant person. Torvalds said: "I'm an egotistical bastard, and I name all my projects after myself. First Linux, now git." The man page describes git as "the stupid content tracker".

I have compiled a quick reference to effective git usage work flow to help maximize your productivity. If you're looking to learn basics of git, I will recommend you to first read through git manual pages. You can also read the excellent free tutorial on git to get up to speed. Last but not the least, you can always count on your the good old friend google.

Quickfire Do's and Don'ts

If you're already somewhat familiar with git, here's a short version of what you need to know.

• Don't develop on the master branch. Always create a development branch specific to the feature/issue you're working on. You can name the branch by ticket id and or feature/issue description. For example, if you are working on ticket #33, adding open-id authentication, you can name your development branch as 33-openid-auth. If you decide to work on another issue in the mean time, create a new branch for that issue -- don't work on both features on the same branch.
• Do not merge the upstream master with your development branch, instead rebase your branch on top of the upstream master branch.
• A single development branch should represent changes related to a single fix/feature. If you have to work on another issue/feature, create another branch.
• After your branch has been accepted into master, you may then delete the development branch from local and from remote, if you had pushed it to remote server. To delete a branch from remote: git push origin :33-openid-auth.

Step-by-step Workflow

1. Add your public key to your ssh keys under your remote repository account (github, unfuddle, bitbucket).
2. Clone a project from the remote repository.
   git clone git://github.com/vnykmshr/dummy.git
3. Don't forget to cd into your project.
   cd node
4. Switch to development branch and pull latest changes.
   git checkout development; git pull
5. Create a new local branch to work on new feature/issue.
   git checkout -b 33-openid-auth
6. Work on the feature on your development branch. Time passes, the remote repository may have accumulated new commits.
7. Add new files to git and commit your modified files on your development branch.
   git add <path/to/modified/added/files>; git commit -m 'descriptive message for your feature'
8. Fetch updates from the upstream to local.
   git fetch
9. Update your local repository with changes from remote.
   git checkout development; git pull
10. Repeat steps 6-9 until your development work is complete. Do a self-review of your code, test your code thoroughly and get your code peer reviewed.
11. Rebase your local development branch.
    git checkout 33-openid-auth; git rebase development
12. Push your change to remote repository only if you must.
    git push origin 33-openid-auth
13. When your code is ready to be deployed, merge your branch into upstream branch and push your changes.
    git checkout development; git merge 33-openid-auth; git push

What is git rebase?

Using git rebase helps create clean commit trees and helps keeping your code up-to-date with the upstream code easy. Read more about git rebase on Git Rebase man page.

Some Gotchas

Be careful not to commit any of your local configuration files, logs, or throwaway test files to the remote repository.

Most of the files can be included in .gitignore file and will be skipped from your commits, this is to remind you to ensure you do review your changes before you do a commit. Issue a git status command to display what changes would get added to your next commit.

Initial Configuration

Before starting to push your changes to remote, you should tell git about yourself, so that your changes can be attributed to you. After cloning a new repository, issue following commands;

git config user.name "Real name"
git config user.email "real@emailaddress.com"

You can add --global flag if you're working on multiple repositories.

Useful Alias

Aliases can be used to speed up development work as you would be working with these commands night and day. Making them short will not only help you remember some of the long commands, but can be quite addictive.

• Open the .git/config file to add your own aliases.
• Add your aliases to the [alias] block, add this block if not already present.

[color]
  diff    = auto
  status  = auto
  branch  = auto

[alias]
  hist    = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short
  lg      = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative
  st      = status
  co      = checkout
  ca      = commit --amend -C HEAD
  dh      = diff HEAD
  dd      = diff origin/development
  ds      = diff origin/staging
  dm      = diff origin/master
  md      = checkout origin/development
  extdiff = difftool -t meld
  files   = diff --name-only

To use one of your aliases, say hist, issue git hist and see the results. This can be useful to git log which produces rather cuber-some results.

Useful tip: Use git show <commit-hash> to see details pertaining a particular commit.

The most important trait for a good developer is how well he/she sets her development environment up, provided he/she makes the most effective use of available tools and technology. I have seen people committing same mistakes over and over, that's when it becomes to follow a standard practice and make it a habit.

I have tried to keep my git worries to the minimum by following simple steps described above. You must have your own way of doing things. It would be my pleasure if you could share a few of your best practices.

\m/