I’ve got a contract to write part of a program. The person writing the other part is in another city. I want to find a convenient way to send changes back and forth. For other reasons, I’d like to learn to use git as a distributed VCS and email changes back and forth. (I’ve worked with SCCS, RCS, and PVCS before, always with locking. I want to push myself to learn how to better use branching & merging and to not depend on a central server.)
We need to do the following two tasks (pretty standard list):
(a) Each of us contribute to bug fixes and new features that require changes to both parts.
(b) Compile and package binaries for customers.
(We also need to work separately on features that don’t depend on the other, but I assume that anything that works for task (a) will work for this also.)
Background: The other guy has never used a VCS before; he’s a little resistant to the idea. He didn’t even know that they don’t all still use locking checkouts. I’d need to understand everything we do in enough depth that I can help him over the rough spots with not much frustration on his part. He’s also very uncomfortable with storing the source on a server, which is another reason to prefer emailing changes. We can easily encrypt them.
Other possibly relevant context: We’re using Delphi on Windows as our development environment. It’s extremely unlikely we’d ever add another developer. We only need to package customer versions a couple of times a year, if that. The number of customers will probably never exceed ten.
Questions:
1) Should I use this project to learn techniques for distributed development? Or is that so much overkill that I should just do something simpler? I don’t mind spending some extra time on the learning, but no more than a couple of weeks.
2) Assuming ‘Yes’ to question 1, what workflow should we use for each of the tasks above?
3) What Windows GUI programs will do all the required tasks? (I’m very comfortable with command line stuff; he’s not.)
Thanks for your help.
I have written a pretty detailed tutorial on ‘gitting started’ that shows what I’ve learned so far about using git. It’s at http://xorandor.com/GittingStarted if you want to read it so far. I tried to write it for a git novice who knows a little bit but not a whole lot about VCSs in general. I plan to add to that as I learn more.
I have been in involved in training and supporting users which were forced to make the switch from source-safe to subversion. There has been a surprising amount of user resistance. It’s been over a year now and I still regularly get called in to fix things when ‘subversion broke my stuff‘ (it’s never the case of course).
Knowing this, I would be very hesitant to try and help someone make the switch from no VCS at all to git (which is probably not the most user-friendly VCS around). Especially if they hate the idea of a VCS. Doubly so if you can’t be there helping them at their desk.
So consider: some causes are just lost causes. Unless you are going to work with this person for a long time, you may be better off setting up a repository just for yourself. You can let him email changed files to you and vice versa. At least git will make it easy for you to see which files changed since the last integration point.