In my blog post “How to do Ad Hoc Version Control” I suggested Mercurial as the DVCS to use. However, I read that Git is a very popular and powerful alternative to Mercurial. Over at the VIM Tips Blog, this post, shows how easy it is to create a local folder repository using Git. Very similar to Mercurial’s steps.
Linked on the Git site we also have this:
Create your own repository anywhere
If you want to get some version control on a simple local project (i.e., it doesn’t have a big remote repository or anything), then you can simply use git init to create your own standalone local repository. For example, if you’re working on some design concepts for a new application, then you could do something like the following:
Now you can add files, commit, branch, and so on, just like a “real” remote Git repository. If you want to push and pull, you’ll need to set up a remote repository.
git remote add
git pull master
Which is better Git or Mercurial?
For ad hoc use, it probably doesn’t matter. What matters is how easy it is to install, learn, and create repositories on demand. For large systems with many version control requirements, one must evaluate each alternative carefully. I’m sure advance use will be ‘difficult’ in any VCS system.
A nice recent blog post by C. Beust, “Git for the nervous developer”, provides a nice perspective on using Git, though perhaps not entirely relevant to the stated Ad Hoc usage scenarios. That post has a nice list of Git references.
What is an optimal ad hoc workflow?
In the original article I gave context for an ad hoc situation. For example, fixing some server configuration files. In that use-case, Git-Flow would be overkill. Perhaps even GitHub Flow too.
A simpler approach is having two “standard” branches: master and dev. The ‘master’ branch is the live or solution branch. The ‘dev’ branch is where you will make any changes or experiments. Rarely would you create a new branch off of dev. If the ad hoc situation is that complicated, you have other issues! In a “lone developer” workflow however, branching off of dev would be more common. Another ingredient is a separate local Git repo to serve as a backup.
The GitHub Flow is still very applicable, of course, and may be better then the above. The GitHub Flow reminds me of “The Flying Fish Approach” that was documented in the cvsbook.
Once one of these attempts on the dev branch (or github flow feature branch) produces a positive result (the dev branch is live while it is current branch), you merge it into the master branch and then tag the master branch. Each success is tagged, that way when the success turns out to be bogus or has unintended consequences, you go back to the last ‘good’ tag. If you don’t use tags, you can just use the commit SHA1 id. Remember the master is always the final live environment of the ad hoc situation.
Now how to use Git to do the above workflow? I don’t know. Still learning Git.
- Using git for Backup is Asking for Pain
- Git Cheatsheet. This one is interactive.
- Git Ready
- A successful Git branching model
- Using Git for Document/Software Version Control
- Version control on a 2GB USB drive
- Git for designers
- Git for the nervous developer
- GitHub Flow
- The Flying Fish Approach – A Simpler Way To Do It
- Using Git as a “Poor Man’s” Time Machine
- Using Git as a “Poor Man’s” Time Machine – Part Two
- What tools exist for simple one-off sharing of a git repo?
- For home projects, can Mercurial or Git (or other DVCS) provide more advantages over Subversion?