Git is a version control system that was designed by Linus Torvalds, first released in 2005. In contrast to CVS (Concurrent Versioning Systems) systems, which in its basics have a file as a processing item, in Git, the basics lie in working with the set of changes, that is, patches. This article is dedicated to those persons who are already familiar with version control systems, such as SVN, and want to know more about alternative version control solutions, and those who want to get tutorials on quick migration to Git.
The first difference that comes into view is that Git is oriented to work with 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 the operation git clone.
git clone gitosis@git.yourserver.com:yourproject.git /home/homeDir/myProjectNow you have a local copy of the repository in the myProject directory, and you are going to work on some new feature. The best practice for 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. The active branch is marked by the star. You may create a new branch with the command git branch.
#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 featureNotice that this operation didn’t create a new directory. All required info is in the .git directory. Using the local branches is very convenient. Imagine that you work on some serious feature that isn’t done yet, the project isn’t currently working as it should, and you need to make a quick bugfix on the production version. I know that this is a nightmare for everyone who has used the CVS. But in Git, you simply switch the branch, for example, to the master, by running this command:
git checkout masterDo 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 the current branch, you will need to use stashing first. To reset your working tree and save your changes to the stash, apply this:
git stash save “Work in progress for feature foo” Now you may do the bugfix or something like this, commit the changes, and return to working on your feature.
git apply stashThis will return the changes you’ve stashed. In case you have stashed more than one feature, you may list all of them by running the command
git stash listand return one, specifying the stash you want this way:
git stash apply stash@{1}Now let’s talk about interacting with the remote repository. As I said before, the commit is performed on your computer, so how do you get your changes to the remote repository? It is actually done in three stages. First, when you create a file in the project, it is untracked, and when you commit the changes, the untracked files won’t be committed. Here are the basic commands that are used for indexing:
#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 await commit, and files that are not indexed yet on the current branch, use the 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 contain compiled files. If you do 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 the extension .foo and to exclude all the files in the directory /out, so your gitignore file should look like this:
*.foo
/outNow, when you run git status, it won’t show you excluded files as ones that await indexing. Now, you are ready to commit the changes.
#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 who is gonna work with the branch, switch to the master branch, and run
git merge featureThat will merge the changes made in the feature branch to the master branch. Next, and the last step to get your changes on the server, run the command
git pushIf you have already finished the work in the branch, you may delete it:
git branch -d featureBut what if several people are going to work with the branch you created? In this case, you should push the branch to the server.
git push origin feature:refs/heads/featureWhere origin is the repository name, refs/heads/feature is the path to the branch description, which is placed in the /.git directory. In the last versions of Git, you may use
git push origin feature:feature.Further, you may update the branch this way:
git pull origin featureIn case if you want to join the development for one of the branches, run this:
git checkout --track -b feature origin/featureThis will create a local branch feature and switch to it. Another convenience about Git is how easy it is to revert the changes implemented here. In case you haven’t committed undesirable changes yet, you may revert the working tree by running this:
git reset --hard HEADFor restoring one file, run the following commands:
git checkout -- foo.bar
git checkout HEAD foo.barIf you have already committed one, but changes are not public yet, you may modify the last commit with the new one, just use the flag –amend while committing. But if the changes are already public, you should never use them. In this case, use
git revert HEADIt will create a commit, which will undo 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 the documentation.
