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.
1
git clone gitosis@git.yourserver.com: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.
1
2
3
4
5
6
#creating new branch 'feature'
git branch feature
#switching to the branch that you created
git checkout feature
#or do the same operations in one line
git checkout -b feature
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:
1
git checkout master
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:
1
git stash save “Work in progress for feature foo”
Now you may do the bugfix or something like this, commit the changes and
now return to working on your feature.
1
git apply stash
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
1
git stash list
and return one, specifying the stash you want this way:
1
git stash apply stash@{1}
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:
1
2
3
4
5
6
#indexing newFile file
git add newFile
#reset index for newFile file
git rm newFile
#indexes all the untracked files
git add .
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:
1
2
*.foo
/out
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.
1
2
3
4
#commits and writes a commit message
git commit -m "Initial commit"
#indexing all the untracked files, commits and writes a commit message
git commit -a -m "Initial commit"
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
1
git merge feature
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
1
git push
If you are already finished the work in branch, you may delete it:
1
git branch -d feature
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.
1
git push origin feature:refs/heads/feature
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
1
git push origin feature:feature.
Further, you may update the branch this way:
1
git pull origin feature
In case if you want to join the development for one of the branches run
this:
1
git checkout --track -b feature origin/feature
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:
1
git reset --hard HEAD
For restoring one file run following commands:
1
2
git checkout -- foo.bar
git checkout HEAD foo.bar
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
1
git revert HEAD
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
documentation.