2. Topics covered:
GIT Introduction
GIT Benefits over different tools
GIT workflow
GIT server creation
How to use GIT for first time.
3. GIT- Introduction
Git is a distributed revision control system with an emphasis on speed, data
integrity, and support for distributed, non-linear workflows. Git was initially
designed and developed by Linus Torvalds for Linux kernel development in 2005,
and has since become the most widely adopted version control system for
software development.
As with most other distributed revision control systems, and unlike most client–
server systems, every Git working directory is a full-fledged repository with
complete history and full version-tracking capabilities, independent of network
access or a central server. Like the Linux kernel, Git is free software distributed
under the terms of the GNU General Public License version 2.
4. Benefits of GIT over Clearcase
• Atomic commits
• Proper change sets
• Speed
• A proper history browser (so that you can see what changed for a commit,
rather than the individual file nightmare of clearcase)
• Reduced maintenance cost and overhead
• No licensing cost
• GIT is actually being maintained (I know clearcase 8 has a new GUI, but the
underlying tools will still be the same old clunky and rotten relics)
• Merges that are more sophisticated than the dumb text merges of clearcase,
allowing a more flexible branching strategy
• Considerably lower overhead for a developer (can you imagine any system
with higher developer overhead than clearcase!)
• MUCH, MUCH, MUCH easier branching and merging.
• No VOB locking during backups.
• Easier to back up
5. Git has a 'clean' command. SVN desperately needs this command, considering
how frequently it will dump extra files on your disk.
Git has the 'bisect' command. It's nice.
SVN creates .svn directories in every single folder (Git only creates one .git
directory). Every script you write, and every grep you do, will need to be written to
ignore these .svn directories. You also need an entire command ("svn export") just
to get a sane copy of your files.
In SVN, each file & folder can come from a different revision or branch. At first,
it sounds nice to have this freedom. But what this actually means is that there is a
million different ways for your local checkout to be completely screwed up. (for
example, if "svn switch" fails halfway through, or if you enter a command wrong).
And the worst part is: if you ever get into a situation where some of your files are
coming from one place, and some of them from another, the "svn status" will tell
you that everything is normal. You'll need to do "svn info" on each file/directory to
discover how weird things are. If "git status" tells you that things are normal, then
you can trust that things really are normal.
You have to tell SVN whenever you move or delete something. Git will just figure
it out.
Benefits of GIT over SVN
6. GIT –Basic Workflow
First, we need to install git in our system. It can
be done in many ways. I am giving an example
of Linux. I am using “Ubuntu 13.04 ” Linux
flavor to explain. So, its very simple to install
using below command:
sudo apt-get install git
7.
8. Now, git is installed in your machine. Just verify it once by running this command:
git --version
Then, someone needs to create the central repository on a server. If it’s a new
project, you can initialize an empty repository. Central repositories should
always be bare repositories (they shouldn’t have a working directory), which
can be created as follows:
git init --bare MyProject.git
9. You might have noticed the –bare repository created above ended in .git. By
convention, bare git repositories should end in .git. For example, project1.git.
The .git ending of a directory signals to others that the git repository is bare.
The Bare repo contains below things initially:
10. Since now we have a git repo ready at our server. Now we have to make use of this
centralized repo. All we need to do, is to clone this repo to have a local copy of ours.
Cloning a repo also needs some permission. Now we will check two approaches.
1. Cloning a repo in same server (IP), with different user name. I have one other user
in my server “sharma”.
2. Cloning a repo in different server (IP) will need some special feature “ssh”.
Create a pub file with your details, using the below command;
ssh-keygen -t rsa -C anuj.sharma@gmail.com
It will create few pub files, out of which you can just do,
cat .ssh/id_rsa.pub
It will be having "anuj.sharma@gmail.com" at the end, just to verify it got
generated with your details. It can be seen in the below snapshot.
11. Create a file with authorized_keys name, and add your pub files to it.
cat .ssh/authorized_keys
Now change the permissions of authorized_keys as it will act an important
role in providing access to other users.
chmod 700 .ssh/authorized_keys
It can be seen in the below snapshot.
12. You may add as much as pub files as you want. It will act as an authentication for your
git repo. Now whenever any user want to clone, git admin has to provide access
by adding a pub file to authorized_keys. And your clone command would be
something like this.
git clone server@IP:/home/anuj/git_repos/MyProject.git
It will not ask for password, if pub file is already added.
13. So, now we have local repo of our own.
We have to check which repo we are using, we can use “git remote -v” to check the
same. It will display the git repo, your are in.
Now, we have to add few things to our git config, so that it will give the information of
user. We need to use below commands as shown in snapshot.
14. Now, we can start working on our repo. Lets create a test file in git repo “abc.txt”. git
status will give the . It can be shown in below snapshot.
The red color shows that file is not a part of git yet. For this we need to add this file to
git repo, using “git add”
15. Since this file is added to git, color has been changed to green. It means, it is now
added to staged area of git, from where we can proceed to commit. It can be shown
below:
-s is used for “signed-off by user”
-m is used for “message”
We can check the git log, how it will look.
Commit-id show above is unique to a change.
16. This presentation ends here, In my next presentation, we will go bit deep and
cover most of the commands with their use cases. Till then you may check the
commands on my blog:
https://anujparashar.wordpress.com/2013/12/29/git-commands-cheetsheet/
Thank you….
