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?

  • 1
    My best hint is to have a look at this: nvie.com/posts/a-successful-git-branching-model It is one (good) way to organize code in team, and we use it too
    – Andrea Salicetti
    Commented Aug 4, 2011 at 10:58
  • do you write tests?
    – NARKOZ
    Commented Aug 4, 2011 at 10:59
  • ...@NARKOZ - not yet. We kinda jumped right in. Its something I would like to do, just bought a book in fact.
    – Geoff Wright
    Commented Aug 4, 2011 at 11:04
  • 2
    @Geoff Wright: Please go into your profile and accept (hit the checkmark button next to) some of the answers that people have so graciously provided to your questions: stackoverflow.com/users/661241/geoff-wright
    – iwasrobbed
    Commented Aug 4, 2011 at 11:47
  • 1
    Use bitbucket.com for private repositories Commented Aug 6, 2015 at 14:58

3 Answers 3


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.
  • I'd also like to add git rebase to this list.
    – awilkening
    Commented Aug 4, 2011 at 12:58
  • 1
    I disagree that stash, apply, format-patch are part of minimum knowledge. I usually wait a few months before teaching those things. I would guess that >50% of dev's don't stash. Commented Aug 19, 2015 at 10:35
  • 1
    Call upstream origin and it will help make other examples (which normally use origin) easier to follow. Commented Aug 19, 2015 at 10:36

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.


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!

  • 1
    SVN is a decent option (and I'm currently using it at work)... but Git and Hg I have found to be a bit better since I can commit locally (and revert when I did something dumb) without forcing others to deal (if they svn update) with my code that may not work. Honestly I started using Git at the office for this reason but I can still publish my changes back to SVN using git-svn Commented Aug 5, 2011 at 1:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.