In the previous post we have talked about why you should use a version control software for your design work and explained a bit about how they work. Now we’ll use one of them to show how to set up a workflow and avoid common problems.
- Part 1 – why and how
- Part 2 – setup and examples (this one)
We’ll be using Mercurial. It is a distributed system, pretty simple to use and very convenient for the task at hand. You can download and install it from an official web page. It is available for the OS X, Windows and different *nix systems. You will install command line tool and we will use it here to focus on the meaning of the action, not on the tool’s interface, but for regular work you can download a TortoiseHG (visual interface) that will help you navigate and maintain the repository.
After the installation is finished, go to your terminal (command prompt on Windows) and write:
You will get a Mercurial Distributed SCM title and a list of common commands. You can get a list of all the commands with the
hg help command. OK, everything’s working so let’s get to work. Navigate to a folder where you want to start a new project or put an existing one under a version control. When there, type:
$ hg init
At first glance nothing happens, but if you look closely you’ll see we’ve got a new
.hg folder. That’s our local repository where all the revisions are kept. Everything else is a working copy.
We’ll add a file to the folder to work with (or you can use existing files if you have them). I’ll use sphere.svg, but any file(type) you can edit will do. I have drawn an orange circle inside the sphere.svg. Now type:
$ hg status
We’ve got this:
It means the file is not under version control. Type:
$ hg add sphere.svg
Now the hg status (or hg st) will show:
That means the file has been added to the version control and that will be saved to the repository on our next commit. Let’s do that now:
$ hg commit -u YourName -m "Our sphere is still only an orange circle."
If you type
hg log in the terminal you’ll see a history of the project starting to appear.
Whew! We’ve done it. Our first commit and one of the actions you hang around most. I must congratulate you. It’s not easy if you do it for the first time. But be assured, when you finally get it, you’ll be wondering how you ever managed without it.
Let us do another iteration of change and commit and than we’ll have a bigger picture of what we’ve done. Let us add a gradient on the sphere and commit.
$ hg commit -u YourName -m "A nice gradient."
If we would type
hg log and make a pretty picture of what it said, this is what it would look like.
But what does it all mean?
It means you have a documented history of all the changes you’ve made. Better yet, with the
update command you can go back in time and load any state in the working copy and review it. A repository is also a backup protecting you from any creative process (madness) that could ruin what you did earlier. If we would change something on our sphere and then some more and some more and it would finally look like a blue triangle. If we decided that it’s not what we want, we can very easily return to our latest state (last commit) with:
$ hg revert sphere.svg
More basic commands and a real-life example
Let us call John and Amy for help. John was also working on an orange sphere but he wants to improve it. He doesn’t have enough time because he has to work on other files in the project so he would like Amy to help. Amy agrees but would like to see how the sphere came to life so she could gather some more inspiration. The best way to do this would be to clone the whole repository. That way Amy would not interfere with John’s work and would have a complete history for reviewing. John types:
$ cd .. $ hg clone project_John/ project_Amy/
Amy takes her repository and starts working. She makes two changes on sphere.svg and commits after each one.
$ hg commit -u Amy -m "Added some shadows to the sphere." $ hg commit -u Amy -m "Gloss effect for the final touch."
John’s and Amy’s repositories now look like this.
If John is satisfied he’ll want to take in Amy’s changes. He’ll need to pull them and update his working copy to the latest change. He navigates to his project folder and types:
$ hg pull path_to_Amys_repository $ hg update
In that moment the repositories are synced as explained in Part 1.
Resources and closing remarks
In these two parts we have laid a ground for some basic usage. A version control software is much more powerful and I encourage you to go through the Mercurial guide to find out more commands, use cases and workflows.
rollback are some of the useful commands you should check out.
The workflow will be determined by your experience and the type of the project. Here are some notes I have found helpful when using a version control system for a design.
- Use clone repositories for testing, new features or some other work you’re not sure will end up in the final product. If it’s good, you’ll push the changes back to the original repository, and if not, the original one was not disturbed. Extra clone costs you nothing, messed up original work and a repository can cost you … well, a lot.
- Commit often. When you commit you don’t have to worry about the direction you’ll take next. If you mess up, revert.
- When having a more complex project consisting of multiple file types that need to interact to get a final product I always have a Screenshots directory. I create snapshots (in PNG) of the changed work inside (ex. website homepage). That way I can update to an earlier revision and quickly scan the screenshot to see the state of the work.