I work in a team which uses git, where 40+ developers are working on multiple code repositories(100+) at any given point of time. We also started out with very few developers, growing the team size in a span of few years. In the beginning though with few people you can get away with knowing only a bare minimum of git. Over time you will improve your git fu, discovering powerful features.
- You'll need a place to host your code. Consider using github or gitorious. Both are free to use, but your repositories will be public and visible to others. If you would like private repositories you can pay for it at github or install and host your own gitorious server.
- In the beginning it's better not to worry about advanced workflows which involve forking, pull requests. You can begin by using git in a centralized manner (shudder!). Treat your hosted copy as the authoritative copy of your source code. Lets call this repository
- One of you commit all the code to a local git repository and push it to this
- The other team member can clone this repository.
- A set of minimum commands you'll need to learn are
branch. Learn more about them from gittutorial.
- Either of you can now work on any part of the code. Do not worry what happens when both of you edit the same file. Git is really good at handling merges and fixing conflicts.
- Make small atomic commits and write good log messages. Use the present tense for commit logs. You can make any number of commits as you like to your local copy as it does not affect the other person's work.
- When you think your code is ready to be shared with others, publish it to the
upstream repository. A good practice is to always pull before you push. This way you keep your repository in sync with others changes.
- Repeat steps
Once you are comfortable with this workflow you can progress into more advanced stuff like - topical branches, forking, pull requests, merging, interactively rebasing commits etc.
If you really want code reviews, it's doable with git and email alone. When your team size grows beyond 10+ this is ideally done better with some kind of online tool. So in practice there are many ways of doing this, and this is just one simple way:
- Create a set of commits to be reviewed with
git format-patch. This will generate a set of patch files. Email these patches to the reviewer.
- The reviewer can apply the patches with
git apply. This applies the patch but does not create a commit.
- Review the code and email back with suggestions.
- Repeat 1-2-3 until satisfactory.
- The reviewer confirms that the patches can be pushed