Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

migrated from stackoverflow.com Aug 4 '11 at 13:16

This question came from our site for professional and enthusiast programmers.

    
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 Aug 4 '11 at 10:58
    
do you write tests? –  NARKOZ Aug 4 '11 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 Aug 4 '11 at 11:04
    
It's a good practice to set up a continuous integration system such as Integrity or Hudson when you're not alone on develop, linked to the develop branch... –  Andrea Salicetti Aug 4 '11 at 11:28
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 Aug 4 '11 at 11:47

3 Answers 3

up vote 17 down vote accepted

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 pay for it at github 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.
share|improve this answer
    
I'd also like to add git rebase to this list. –  alock27 Aug 4 '11 at 12:58

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.

share|improve this answer

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!

share|improve this answer
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 –  Ken Henderson Aug 5 '11 at 1:28

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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