Even when I’m the only one working on a project, I set it up in git. So any time I set up a new project, in my new project directory, I do this:

1. git init
2. Edit the file ./.git/info/exclude and add the following lines:
   build
   .xcodeproj/.mode*
   .xcodeproj/.pbxuser
   .DS_Store
   
3. git add .
4. git commit -a -m “Added project to repository.”
5. git clone ~/Dropbox/Shared/MySharedProject.git

Now, whenever you edit a file in your project,

1. git status
2. git commit -a -m “Comment for changes.”
3. git push

You’ll never need to do a pull if you’re the only one working on the project.

Dropbox will automatically upload the changes to your remote folder.

Let me know if you need further clarification.

-Matt

a) Just create the projects in dropbox and create the repo an let dropbox do the sync

b) you need to do the whole “clone, push, pull” operation because git will get all screwy otherwise?

Please advise. And thanks for writing the article, very useful

I learned decades ago that version control means never having to say you’re sorry. It’s obvious in a team environment, but absolutely critical when you’re flying solo…. your buddy in the next cube does NOT have the file you just barfed all over. If I had a grand for every time VCS (of whatever incarnation) saved my gluteus/project/job, I might not be able to retire, but I could definitely afford that chalet in Innsbruck.

If you’re not using version control, preferably not running on your dev machine, you’re a dilettante, a dabbler causing yourself more unknown pain than you imagine. Wake up!

It took me literally 5 minutes to get a git repository online using these instructions. The coolest part is that gitosis stores its configuration files in a git repository that it manages. So to change its configuration, you just edit your local git clone of the admin files, ‘git push’ them back to the server and they instantly take effect.

Simple: —Local/Offline version control —Local/Offline branching and merging —FAST No network access means no network overhead so faster —Not dirty when switching to a branch. One workspace no matter what branch you are on —Directories are not covered with .svn or CVS directories —Merging that actually WORKS. This is a VERY big deal when you actually start branching and merging.

But here is a thought. TRY IT. Play with it. If you don’t like it then fine go off and be happy. It seems you would rather have someone convince you (or argue with you) instead of spending the time deciding for yourself if git is for you.

And btw, the BS about SVN merging being a feature that needs to be fixed? Give me a break! It has never worked worth a damn in CVS and SVN is just as bad. It does require a whole new system because SVN’s design is flawed. Did you watch the Torvalds video? Do any research into the difference in how files/changes are handled between SVN, HG, BZR and GIT? Probably not. It is a design flaw and it can be fixed by not using subversion.

I guess I’d much rather hear about why I’d be happier with something else than why I’m an idiot for using what already works for me. :)

The point of git is not that it is distributed. That is a given and works great for the situation it was written for. Git can easily be used in a central repository configuration.

The point of git is that it does not suck when it comes to merging and handling the code. Subversion is absolutely terrible with merging and even worse with managing code. I ran into some of its amazingly poor design just this morning. Imagine this situation and it is only one example of many: Move a directory from one place to another (under a different parent) and then delete the parent. Then commit. Guess what, subversion blows chunks. You have to move, commit, delete, commit.