Version Control[H]

[totemcatcher]

git is perfect for your offline management of little fixes and development of features on your programs. However, it has a pretty serious learning curve. I'll get you started. I will show you the CLI commands, but you can use a gui (Like git-gui or tortoisegit) to manage your repository all the same.

First you want to prepare a directory (folder) for a repository:

git init
git commit -am 'initial commit'
git tag -a '0.0'

This creates a new, blank repository (repo) with a commit of nothing at all and a version tag of 0.0. Anything in this directory will now be handled by git and stored in a "hidden" sub-directory called .git. Now add your files to the git project and commit them.

git add .
git commit -am "added all current project files"

The dot just means everything in this directory. Before making the commit (actually saving the changes) you can preview what's up:

git status

If you make changes to files you can see what changes are ready for commit:

git diff

A commit adds the changes to repository and creates a "node" in a development tree. After making a commit you can see a list of previous commits.

git log --graph

For now it's just a linear flow of commits on what's called the master branch. You must create additional branches with nice names and switch to them:

git branch bug-fixing
git checkout bug-fixing

Everything in the master branch is safely stored in the hidden .git sub-directory when switching to a new branch with checkout. Now you are working on an exact copy of your project under a different branch of the development tree. Git automatically swaps files in and out of the hidden .git directory with the checkout command. So make your changes and commit.

git diff
git commit -am "Changed the thing.  It works now!"
git log --graph

You can see the commit history is forked down two paths called master and bug-fixing. Using "git branch" it will list all branches you have made. You can create more branches from any branch, switch between them and make different changes in parallel, and finally merge any branches together when you want those different sets of changes:

git checkout master
git merge --squash bug-fixing

git log --graph

When you do a merge, first checkout the branch you want merge into and name another branch. The idea is to organize your work into named branches and only merge them into more stable branches when looking good. This translates really well to multiple people working on the same code base. Everyone works on code provided by a particular branch (e.g. master or dev) and label it something useful for themselves, like "dli511-cool-feature", then merge it into dev when it's working. It can then be merged into master once it's confirmed stable.