Git is a version control system, that was designed by Linus Torvalds, first released in 2005. In opposite to CVS (concurrent version systems) systems, which in it’s basics have a file as a processing item, in the Git basics lays work with the set of changes, other words, patches. This article dedicated to that persons, that is already familiar with the version control systems, such as SVN, and wants to know more about alternative version control solutions and persons that wants to get a tutorials about quick migration to the Git.
First difference that comes into view, is that Git is oriented to work with the local repositories. So basic operations, like commit are performed for the local repository on your computer. Let’s take a simple guide for the basic operations you gonna use. Checking out the project copy from the repository on the server is performed by operation git clone.
git clone firstname.lastname@example.org:yourproject.git /home/homeDir/myProject
Now you have local copy of the repository in myProject directory and you are going to work on some new feature. The best practice of doing it is to create a new branch. By default, after you have cloned the repository, you are at the branch called master, you may tell that, after viewing the branches with the command git branch -a. Active branch is marked by the star. You may create new branch with the command git branch.
Notice that this operation didn’t create a new directory. All required info is in the .git directory. Using of the local branches very convenient. Imagine that you work on some serious feature, that isn’t done yet, project isn’t currently work as it should and you need to make a quick bugfix on the production version. I know that this is a nightmare for everyone that have used the CVS. But in Git, you simply switching the branch for example to the master running this command:
Do the bugfix, commit the changes and get back to work on your feature. The only moment about switching the branch is if you haven't done that part of work yet, that could be a commit, but you need to switch the branch now, or you need to make some other changes to current branch, you will need to use stashing first. To reset your working tree and save your changes to the stash, apply this:
Now you may do the bugfix or something like this, commit the changes and now return to working on your feature.
This will return the changes you’ve stashed. In case if you have stashed more than one feature, you may list all of them running command
and return one, specifying the stash you want this way:
Now let’s talk about interacting with the remote repository. As I said before, commit is performed on your computer, so how to get your changes to the remote repository? It is actually done in three stages. First, when you create some file in the project, it is untracked, and when you will commit the changes, the untracked files won’t be commited. Here are the basic commands that are used for indexing:
To look at the indexed files that awaits commit, and files that are not indexed yet on the current branch use command git status.
In every development process, there are some files that shouldn't be on the server, like files, created by the development framework, or files in out/ and target/ directories, that contains compiled files. If you will not ignore them, command git add . becomes useless. To ignore some files, create a file named .gitignore in the top level directory of your project. For example, you want to exclude files with extension .foo and to exclude all the files in directory /out, so your gitignore file should be look like this:
Now, when you will run git status, it won’t show you excluded files as ones that awaits indexing. Now, you are ready to commit the changes.
Now you have several options available, depending on how you are planning to use this branch. If you are the only person that is gonna work with the branch, switch to the master branch, and run
That will merge the changes, made in feature branch to the master branch. Next, and the last step to get your changes on the server, run the command
If you are already finished the work in branch, you may delete it:
But what if several people are going to work with the branch you created? In this case, you should push the branch to the server.
Where origin is the repository name, refs/heads/feature is the path to the branch description, that is placed in the /.git directory. In the last versions of Git, you may use
Further, you may update the branch this way:
In case if you want to join the development for one of the branches run this:
This will create local branch feature and switch to it.
Another convenience about Git is how reverting of the changes implemented here. In case if you haven’t commited undesirable changes yet, you may revert the working tree by running this:
For restoring one file run following commands:
If you have already commited one, but changes are not public yet, you may modify the last commit with the new one, just use flag --amend while commiting. But if the changes are already public, you should never use it. In this case use
It will create commit, that is undoing all the changes in HEAD.
So this is the basics you should know to start working with Git. To learn more about Git, please read http://book.git-scm.com