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
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
rebaseyour 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.
- Add your public key to your ssh keys under your remote repository account (github, unfuddle, bitbucket).
- Clone a project from the remote repository.
git clone git://github.com/vnykmshr/dummy.git
- Don't forget to
cdinto your project.
- Switch to
developmentbranch and pull latest changes.
git checkout development; git pull
- Create a new local branch to work on new feature/issue.
git checkout -b 33-openid-auth
- Work on the feature on your development branch. Time passes, the remote repository may have accumulated new commits.
- 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'
- Fetch updates from the upstream to local.
- Update your local repository with changes from remote.
git checkout development; git pull
- Repeat steps
6-9until your development work is complete. Do a self-review of your code, test your code thoroughly and get your code peer reviewed.
- Rebase your local development branch.
git checkout 33-openid-auth; git rebase development
- Push your change to remote repository only if you must.
git push origin 33-openid-auth
- 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
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.
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.
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 "email@example.com" You can add --global flag if you're working on multiple repositories.
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/configfile 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
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.