So you want to learn about Git. Awesome but if you still have second-thoughts here are 3 reasons why you should learn Git:
- The most obvious reasons i could give you is everyone uses it, it is extremely popular in the developer community and it is still growing. Its initial release was in 2005 and by the 2015 there were over 9 million users, 21.1 million repositories
- Because of its source control (a practice of tracking and managing changes to code,and prevents the conflicts when there are multiple changes to a code) is a is essentially a standard skill for programmers in the industry, for example you are working on a project with group of people, all of you work at the same time, it is almost guarantee that there will be problems with code repository, or your code will interfere with a code of your colleague. This is where Git has come through, GitHub has distributed version control system, and basically you copy your repository your system and make changes there. This will prevent interfering with codes or problems with repository.
- GitHub, If you ever heard of Git you must have heard of GitHub, but if you just started learning Git no problem we will explain what it is. GitHub is a community of developers, and that community of developers is constantly updating and improving open-source technology. Some of the most-used technologies today (for example Django and Node.js) are hosted on GitHub. If you already are interested in Git and its community than click HERE.
Table of Contents
1. What is Git?
Git is one of the most popular implementation of a distributed version control system. Its origins are from Linux kernel development. The core of Git was originally written in the programming language C, but was also re-implemented in other languages such as Java and Python.
1.1. Git repository
A Git repository contains the history of a collection of files starting from a certain directory. The processes of copying an existing Git repository via Git tooling is called “cloning”. If you clone a Git repository, Git will assume that you want to work in this repository as a user. If you want to delete a Git repository, you just delete a folder which contains the repository. Git also supports the creation of repositories targeting the usage on a server.
- “bare repositories” are supposed to be used on a server for sharing changes coming from different developers. These repositories do not allow the user to modify locally files and to create new versions of repository based on these modifications.
- “non-bare repositories” target the user. They allow you to create new changes through modifications of files and to create new versions in the repository. This is the default type which is created if you do not specify any parameter during the clone operation.
Next in line is Working tree, you can imagine working tree as a normal tree (that is why it is called tree) it has lots of branches and leaves. Well here instead of branches and leaves we have repositories. So working tree is a collection of local repositories that provides at least one collection of files which originate from a certain version of the repository. A file in the working tree can have different states. They are:
- untracked: the file is not tracked by Git repository (meaning: file was never staged or commited)
- tracked: the file is commited but not staged
- staged: the file will be included in next commit
- dirty/modified: the file has changed but the change is not stage
After modifying the working tree, there are two steps that needs to be done to persist changes in local repository
- add the selected changes to the “staging area” using “git add”
- commit the staged changed into the Git repositoriy using “git commit”
2. Installation of the Git command line
Ok that was enough of theories and facts moving on to practial part, which is as a headline says installation
2.1. Installation on Ubuntu
There are 2 easy steps
- open terminal
- write the following:
sudo apt-get install git
2.2. Installation on Windows
Windows version can be found here
Download the Windows version and follow the installer
3. Git configuration
The “git config” allows you to configure Git settings. They can be system-wide, user or repository specific.
System-wide configurations are not very common but if you want to use this kind of configuration type “--system” option for the git config command
configuration is also called global configuration and for this type of configuration type “--global” for git configuration
Repository configuration is used by typing “--local”. If neither “--system” or “--global” parameter is used, the settings is specific for the current Git repository
Before continuing with configuration you have to set up your credentials (username and email address) to be able to commit to a Git repository
To configure username write this:
git config –global user.name “Username”
To configure email address write this:
git config -global user.email "user[at]email.org"
One more thing before continuing, if you have Git version lower than 2.0 you need to use push configuration
git config –global push.default simple
by doing this you will configure Git so that “git push” pushes only active branch to your git remote repository. Versions 2.0 and higher have that as a default.
Ok finaly we can continue with using Git:
Now that you configured your credentials we can make an example of using Git.
Firstly we will make a directory where we will store our working tree (that will come later on)
# switching to home directory cd #creating a directory and switching into it mkdir Testing cd Testing #creating new directory inside Testing mkdir Files
Now that we have new directories we can create repository with a working tree
By using “git init” command we will create Git repository in current repository
#you need to be sure that you are still in the Testing directory cd ~/Testing #initialize the Git repository in current directory git init
After we have initialized our working tree we can now create few more files so after that we can check status of our repository
#swithcing to Git repository
cd ~/Testing
#creating an empty file in new directory
touch Files/data.txt
#creating new files with content
ls > test01
echo "something" > test02
echo "random" > test03
Now that we have some files with content in them, we can check status of our repository. To do that use “git status” command, it will show the status of working tree, which files have changed, which are staged or if some are not part of staging area.
After running “git status” command your output should look something like this:
On branch master
Intial commit
Untracked files:
(use"git add>file<..." to include in what will be commited)
Files/
test01
test02
test03
Nothing added to commit but untracked files present (use "git add" to track)
Now (as message suggested) we need to use “git add” command, this will allow us adding changes in the file system tot the staging area. You can add all changes to the staging area by simply putting “ .” at the end of command. Here is an example:
#adding all files to the Git repository
git add.
Now that we have added files in the repository, lets run “git status” again to see the changes.
The output should look something like this:
On branch master
Initial commit
Changes to be committed:
(use "git rm -cached<file>..." to unstage)
new file: Files/data.txt
new file: test01
new file: test02
new file: test03
Changing files that are staged
If you have made changes on one of your staged files before committing, you need to add the changes to the staging area.
#add a string to the test03
echo "foo2" >> test03
git status
Notice how we didn’t add them in the staging area so output should look something like this
On branch master
Initial commit
Changes to be committed:
(use "git rm -cached<file>..." to unstage)
new file: Files/data.txt
new file: test01
new file: test02
new file: test03
Changes not staged for commit:
(use "git add<file>..." to update what will be committed)
(use "git checkout--<file>..." to discard changes in working directory)
modified: test03
After adding them into the staging area using “git add .” the output should look like this
On branch master
Initial commit
Changes to be committed:
(use "git rm -cached<file>..." to unstage)
new file: Files/data.txt
new file: test01
new file: test02
new file: test03
Committing staged changes
Now that we added the files to the Git staging area, we can commit them in the Git repository using “git commit” command. This will create a new commit object with staged changes in Git repository and the HEAD points the new commit. The “-m” parameter (m stands for message) will allow you to specify the commit message. Here is an example:
#commiting file to the local repository
git commit -m"Initial commit"
Now we can use “git log” to see changes in Git commit. After running that command. The result should be something like this:
commit:306050803fcbd507df36a3108945e02908c823828
Author: its me <itsme@example.com>
Date: Son Sep 9 19:39:32 2018 +0100
Initial commit
Now after all that is done, lets say that you want to remove some of the files, you can do that like this:
#removing the "test03" file
rm test03
#add and commit the removal
git add .
git commit -m"Remove the test03 file"
4. Git in Eclipse
So after the CMD/Terminal configuration we are going to explain the Git in the Eclipse. Most of the Eclipse IDE already contains Git so we only need to implement it in Eclipse to make it accessible. Here is the guide how to do it:
- Select the Help tab and click Install new software
- In “Work with” section copy this:
http://download.eclipse.org/egit/updates Check all available tabs and click next- You will get to the “Install details” just click next, and then accept the terms of the license agreement and click Finish
Now we can Configure Git in Eclipse
Firstly we are going to configure the toolbar so we have easier access for Git usage. To do this follow the next steps:
- Window > Perspective > Customize perspective
- Click on “Action Set Availability” and select Git. This is important because if you dont do this, on “Tool Bar Visibility” you will see Git but you will not be able to choose and you will receive this message “’Git’ cannot be made visible because all of its children are in unavailable action sets”.
- You can now go back to “Tool Bar Visibility” and choose Git
Great! Now we have ‘Git’ section in our toolbar, next thing to do is set the Git Repositories view. Here are the steps of doing that:
- Window > Show View> Other
- Now you have a new window called “Show View”, locate Git and expand it
- Choose Git Repositories and click open
Now you should be able to see in lower left corner a Git Repositories tab. The content of the Git Repositories view shows the existing Git repositories and the important data of each repository.
Right-click on on an element in Git repositories view allows you to execute related Git operations. For example if you right click on a branch you can checkout the branch or delete it.
Don’t leave the Git repositories view yet, we will open a commit using Eclipse menu.
Navigate > Open Git Commit…
Now you will have to enter branch, tag or commit SHA-1. Once you do it, it will open a Git Commit. From there you can create a tag, branch. And also revert it.
Integrating Git into the Package and Project Explorer. The package Explorer view shows indicators on the files to show their status. The most important icons and their meanings are:
- Tracked – file is committed and has not changed.
- Untracked – file is neither staged nor committed.
- Ignored – file is flagged to be ignored by Git operations.
- Dirty – file has changed since the last commit.
- Staged – changes will be included in the next commit
- Added – staged but not yet committed (this one is similar to staged, but here the file was not under Git version control)
- Removed – the resource is staged for removals from the Git repository
- Conflict – a merge conflict exists for the file
And that is it. We have cover the basics of learning Git