views:

199

answers:

3

I am a single man shop developing a handful of desktop applications and websites. I started using GIT for version control a few months ago, and I am reasonably happy with it, but my usage is pretty clumsy and I am wondering what the workflow should be for a single user.

Right now, I have a .git folder in each of my project folders. I commit my changes every once in a while and I just keep working on the working copy.

I never pull anything from the Git repository (the working copy is still there, would it get overwritten by Git?), and I am not quite sure what would happen if I created a branch (Where is the branch created? Same folder?)

In other words, I am using Git mostly to see differences with old versions when needed, while still working the same old way.

It's fine, and even a basic set-up like this has advantages, but I feel that I am missing the point.

What should the workflow be like for a one-man shop?

+5  A: 

I never pull anything from the Git repository (the working copy is still there, would it get overwritten by Git?),

With git, the "working copy" is a repository! The "pull" command is for pulling changes from other repositories. As a single developer you do not need it.

and I am not quite sure what would happen if I created a branch (Where is the branch created? Same folder?)

In your local repository, yes.

It's fine, and even a basic set-up like this has advantages, but I feel that I am missing the point.

Most of git's "new exciting" features are geared towards collaboration. Remember that it was developed to support the development of the Linux kernel, where literally hundreds of people contribute and simply keeping track of and merging the commits is a full-time job. Some of the features are useful pretty much only in such an extreme scenario.

But there are also some big advantages for single developers.

What should the workflow be like for a one-man shop?

Your current workflow is OK (assuming that you make regular backups; a remote repository can server that purpose as well). It could be improved by using feature branches. This allows your version history to be cleaner when you work on several things at the same time (and can prevent serious mistakes sometimes).

A somewhat related, very useful git feature is the stash.

Michael Borgwardt
Ah, I see. I thought the repository was the content of the .git folder. Thanks for the explanations.
Sylverdrag
@Sylverdrag: the .git folder is where git keeps all the data about commits, branches, etc., so one could consider it to be "the repository" while the rest of the folder represents "the working copy". But most users don't make this distinction.
Michael Borgwardt
A: 

I think for your purpose exactly how you use it is fine. Branches are created in the same repository as your working copy.

Maybe you should consider making some backup copies for your git projects to another machine. Then you can just push your changes there and don't loose your work if your computer crashes.

Kungi
A: 

I never pull anything from the Git repository

clone / pull / push commands are for interacting with ohter repos (e.g. repos in other dir using git's file:// protocol)
Maybe that's what you are missing here (e.g. import parts of your other git repos, begin new project based on another repo and so on)

would it get overwritten by Git?

Almost everything in git may be recovered. Just one condition: you should have been commited it before. So commit early, commit often, and it will be fine.

and I am not quite sure what would happen if I created a branch (Where is the branch created? Same folder?)

A branch is just a specific commit. So it is created where all your commits are.

takeshin