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?
Whats the work flow with 2 people on a project
git;github;gitflow
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 upstream.One of you commit all the code to a local git repository and push it to this upstream repository.The other team member can clone this repository.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.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 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: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 upstream.