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.
views:
489answers:
7Should you use this projet to learn git? I would say yes.
Besides the inherent benefits of source control, I using git has the advantage of having full copies of the repository on each developers system.
One thing I would do on top of each having a repository, is to have each of you sync with a central server every day or so.
The workflow would go like:
- You make changes to your local git repository as often as you can.
- At a fixed interval (once a day, after a big bug fix or feature, etc) push your repository up to a central repository located on your web host or another git hosting provider (aka, GitHub).
- Always pull changes from the central repository instead of each others repository. You can treat the central repository as your release repo, and this will avoid confusion as to which repo (yours or his) is the most current.
I know that the whole point of a distributed version control system is to not have a central repo, but I really like having that extra copy offsite. If anything it gives you yet another copy of the repository for backup purposes.
As far as git on windows, I would check out the illustrated guide to running git on windows. The built in git-gui leaves a lot to be desired, but it is functional and usable.
Also, since your partner is new to source control, I would recommend Eric Sink's excellent Source Control HOWTO. It gives you a lot of great information about the how of source control.
I am pretty new in git, but maybe the fastest way to start is this:
With git you can create two repositories on your computer.
One for your work, and second for the work that he sends to you.
There nice tutorial to start (as mentioned by Nick)
This tool is good if you work with windows/subversion before TortoiseGit
My point : don't start to teach him until you feel very good in git, make a both repos/branches in your computer.
I'd just configure autosetuprebase on each and just start with a pretty simple setup.
Embrace the conflicts you get -- those are the changes that would've otherwise been lost.
Im my experience, Git is not very well supported on Windows, yet.
For a similar, but IMHO more user-friendly DVCS, see Mercurial (a.k.a. Hg). It has a Tortoise-client and a rather friendly command-line tool too.
There's also Visual Studio and Eclipse plugins for Mercurial (I think NetBeans too). They work reasonably well and are a great add-on to the other tools. (Stuff get's added/deleted/renamed automatically and basic syncronization tasks (push/pull) work fine.)
It looks like git has built-in emailed patches functionality. I've not used it though, so I can't speak for its usefullness.
Since the other developer isn't familiar with revision control concepts, I suggest starting slowly.
My suggested workflow consists of a repository on your side that he can "git clone". Show him how he can fetch changes from that and have him mail his changes back to you. Show him how git can mail changesets around. This way, you are going to be the one who will have to worry about edit conflicts which tend to be a great source of confusion for people who have never used version control systems before.
The other guy has never used a VCS before; he's a little resistant to the idea.
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.