Software Development - Revision Control

Jan 16, 2010

Git With The Program.

I have recently switched from primarily using Subversion at home to using Git, so that I can use GitHub. I am glad I did, as Git actually seems much easier to use, among other things. There are some good tutorials online, but I will run through the absolute minimum to use Git offline for a standalone, no branches, project.

First, there are some things you need to do ONE TIME, and never again, before you put your first project within git:


	$ git config --global user.name 'Joe Blow'
	. . .
	$ git config --global user.email 'joe_blow@mailhost.com'
	. . .

If more than two people work on the project, it might be helpful to know where to direct blame, er, praise, right?

OK, now for the stuff you have to do once per project:


	$ cd my/project/src

I know I left that script somewhere. Of course, I thought I was going to throw it away, but now I have to work on it some more...


	$ git init

Make Git create all of its hidden files and directories so that it can track the files in your project. Yes, this is a bit easier than what you have to do in Subversion, and lowers the friction so you can more easily Always Use Version Control. [1]


	$ git add .

Recursively tag everything nested within the current directory as un-garbage.


	$ git commit -m 'save existing work'

Now save all of your prior work, just in case, before you start screwing around with it, break it, and wish you could go back to when it mostly worked.

From this point on, making changes and saving them is pretty much the same workflow (and "sub commands") as CVS or SVN:


	$ git status

Which files did I change? Huh, why did I change that one?


	$ git diff

Let's have a detailed look at the changes (defaults to all files). Oh, I remember now. Yeah, we want to keep that. Of course, if you wanted to back out an erroneously dirtied file, you need commands outside of this tutorial -- however, Git is good about prompting you about possible options, so you can frequently avoid a trip to the documentation!


	$ git commit -a -m 'added feature X'

Mission accomplished! Save it. Let the cycle begin anew. Note that the -a will add new files to the project, rather than ignoring them.

You may notice that I have stuck to the command line interface here. There is a plugin for NetBeans for Git, which I have. I like how it highlights (on the editor margin) uncommitted changes to a file, but I don't use it much otherwise. Command lines are easier to document, and to automate with aliases and scripts.

Notes:

While looking for one of the likely suspects for the "always" rhetoric, I stumbled across this software configuration management article. The author makes an excellent point about "task branches", so that you can work on a feature in peace, with fallback points, and then merge it to the release branch when it is stable, and you know you are looking for integration issues only then. I worked on a team that forbade this practice, limiting access to the command to create a branch, due to a vendor promoted SCM policy that was implemented. I tried to talk them out of it, but, no joy.

Finally, the link I found for this was not exactly what I was looking for. I was hoping to find an excerpt from "Rapid Development" (McConnell) or "Pragmatic Programmer" (Hunt and Thomas).

Last Month

Contact me:

yahoo.com

Software Development - Revision Control - RoboProg's

Git With The Program.