When people have decent sized programming projects, what they have are usually a stable codebase and a development codebase. Stable means that it’s mostly bug-free, or at least they consider it to be so, while development means that they probably have new features added to the program or a quick-fix for a known bug which will then be polished until they think it’s stable enough for it to become stable. What they usually use for managing this kind of thing is source control management (SCM) systems.
Here, we’re going to talk about Git which is an SCM developed by Linus Torvalds and friends to manage the Linux kernel. Why Git? Because it is the best SCM tool out there ( or so Linus said in the following video. He apparently called Googlers ugly and stupid for using CVS or Subversion ).
What is Git?
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. For example, let’s say you are working on a project and you only have the stable code. How would you create a development branch where you can experiment with stuff without affecting the stable branch? You just make another directory and copy-paste the stable directory to the development directory right? Well with Git, you can work on just a single directory. How? I’ll show you how.
How to use Git?
First, you need to download and install Git. All the Git commands introduced If you’re on the major Linux distributions like Ubuntu or Mint, you most likely can just enter this on the Terminal:
sudo apt-get install git-core
or for Red Hat distros like Fedora:
sudo yum install git
For non-Linux users, go to the Official website. On Windows, you would enter the Git commands on Git Bash.
First of all, I’m going to say that I’m going to keep this tutorial as short as possible because Git is a really big topic and I don’t like my tutorials to be too long by covering every nooks and crannies. So I hid some details because I want people to get started as fast as possible andI think people have the capability to figure what those commands does. There’s always git help [command] and the Official documentation to the rescue too if people have questions.
So after you’ve done all that stuff in the previous section, create a folder anywhere you want for your Git project. Here, I’ll just call my folder “test”:
Next, we need to initialize the Git repository on that folder:
cd test git init
Now, let’s say we created a “main.c” file inside the folder.
To show what Git has to report to you about the files in the folder, type:
And it’ll list “main.c” under “Untracked files”. Tracked files are basically the files that you wanted to commit because what you wanted to do with that file has been done. So we tell Git to track the file:
git add main.c
If you check the status again, you’ll see that “main.c” will be listed under “Changes to be commited”. Let’s make the first commit!
git commit -m "Initial commit"
You’ll see that Git tells you some information about the commit:
- what branch it was on ( “master” )
- the first 7 characters of the SHA-1 checksum
- number of files changed
- number of lines added/removed
[master (root-commit) 20f5765] Initial commit 1 file changed, 1 insertion(+) create mode 100644 main.c
After that, you decided you want add 3 lines of code to your “main.c” and commit again ( remember, before commit, always add the files that you modified since last commit ):
git add main.c git commit -m "Second commit"
[master fd6b6e9] Second commit 1 file changed, 3 insertions(+), 1 deletion(-)
Git tracks all your commit history. So if you want to check the commit history, enter:
And really, that’s all you need to do to make Git keep snapshots of your files. Here’s a few additional tips and commands that may come in handy:
- git add -u – most of the time, you’d probably have many files, and it gets tiring to type “git add” on every single one of them. If you have added them before, and you want to add them again in a single command, this is what you use.
- git add -A – sometimes, you have new files…and a lot of them. You know you want to add all of those new files including the ones you added before. Use this command.
Usually, not all of the files in your Git directory needs to be tracked ( e.g. .o, .a, .so, executables ). So you create a file named “.gitignore” in the directory and inside the file, it looks like this:
*.[oa] # object files and static libraries *.so # shared object files main # executables
By now, you probably want to know how to “push” your Git repository onto a web server like Github. First thing to do is to go to Github, register an account and click on “New Repository” on your page. After you’ve created one, you can go to your Git directory on your computer from Terminal and add a remote server called “origin”:
cd test git remote add origin https://github.com//test.git
Now, you want to actually “push” your Git local repository onto the remote repository at Github:
git push origin master
Now, if you check your “test” repository at Github, you’ll see that it lists “main.c” ( or whatever files you have ). Next, let’s say you’re now on different computer and you want to “clone” the repository onto this computer, easy:
git clone https://github.com//test.git
If the repository on Github is updated by some other collaborators, you can update your current local repository by typing:
So you worked on “main.c” for a while, you think it’s stable enough and you want to do some experiments/bug-fixes with it without affecting the “master” branch yet. Let’s create another branch then:
git branch testing git checkout testing
What “git branch” does is just create another branch called “testing”. However, you’re still working on the “master” branch. So when you commit, you’re updating the “master” branch, leaving the “testing” branch behind. To switch to another branch, you use “git checkout”. A shortcut for those two commands is:
git checkout -b testing
After you worked on the “testing” branch for a while, you thought that “Well, this should make it to the master branch” and you want to merge them together. This is how you do it ( assuming you commited first ):
git checkout master git merge testing
If you decided that you don’t need the “testing” branch anymore anytime soon, you can just delete it:
git branch -d testing
IV. And that’s it for the basics!
Now that you know all the basics stuff, you should check the Official documentation out on the official website. There are a lot more things that aren’t covered here =)