Whats the work flow with 2 people on a project

Question

I come to you as a newbie programmer who's been working on his own project (which is progressing nicely). My co-founder has also been learning how to program and has reached a point where he could probably start fixing some things and making some things happen.

He asked a very good question, which was "how will this work". Something I could only theorize about as I've never programmed with someone else. Could you advise me on the best work flow. We use git.

Should we own specific parts of the system? Checking code in? Code review?

How do you work with >1 dev?

Answer 1

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.

1. 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 host them on github for free or install and host your own gitorious server.
2. 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 upstream.
3. One of you commit all the code to a local git repository and push it to this upstream repository.
4. The other team member can clone this repository.
5. A set of minimum commands you'll need to learn are clone, pull, push, add, commit, log, status, diff, branch, stash, apply, reset, format-patch, branch. Learn more about them from gittutorial.
6. 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.
7. 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.
8. 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.
9. Repeat steps 7 and 8.

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:

1. 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.
2. The reviewer can apply the patches with git apply. This applies the patch but does not create a commit.
3. Review the code and email back with suggestions.
4. Repeat 1-2-3 until satisfactory.
5. The reviewer confirms that the patches can be pushed upstream.

Answer 2

I use github and all its functionality for this. check it out at http://www.github.com/ So you can use branches, forks, issues, pull requests to work with your partner.

Answer 3

The first thing I would do is look into a central code repository so that changes can be merged and kept in sync between your two projects. SVN is a good easy one that I have used in the past and it's been around long enough that it's fairly mature SVN.

After that I would identify between the two of you the roles either of you are going to play i.e.

1. Are you going to write functionality of the code in tandom or is one person going to do bug fixes while the other continues on with features.
2. Do you want to create a set of basic coding standards i.e. brace position, private member variable naming, variable and method naming convention (CamelCase etc)
3. How often do you need to check in. I would suggest at least once a day to ensure you are both seeing what the other is doing especially early on. Although always ensure before a checkin the code is buildable.
4. He's the boss, but are you going to be the programming lead?

Good luck!