Scribd
Upload
12 views

Git Fundamentals

Uploaded by

pavan.n
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
12 views

Git Fundamentals

Uploaded by

pavan.n
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

Git fundamentals

What is Git?
A distributed version control system (VCS) whose primary user interface is the Unix command line. It
basically keeps a "non-human-readable" database of the files you put under version control ("track")
and provides commands to access and update that database.

Graphical user interfaces, integration in Integrated Design Environments, and web platforms
GitHub/GitLab/… have formed around the Git core software.

The aim here is not to tell you every single Git command in existence or even to teach you all the
functionality. The aim is to familiarize you with the principles of version control, some good practices,
and get you started on the practical matters.

Practical introduction by example


We're going to walk you through an example. The things we show you here will teach you all you need
to know to collaborate on your team project using Git.

Setting up
To initialize a new local repository do

Now try ls -a Notice anything interesting? You can also clone existing repositories from a (usually
remote) different location. Git supports this via http(s), ssh, etc.

We're going to create a remote repository on GitLab and clone it.


Please create an account on GitLab (http://gitlab.com) and create a public repository called myrepo.
Then clone it to your local machine by doing

At this point you could set some configurations.


To make settings for all repositories on your computer, add the flag --global after git config.

You should also set your user name and email like this:

These will be associated with your commits.

Monitoring 1
Your first best friend in Git is the command status :

It shows you the files in the repository, both tracked and untracked by Git. Use this command all the
time to know what's going on.

Committing
Commit = saved snapshot of tracked files. You can always revert to a commit! You can also compare
them, share them, … Commits are cheap. What do I mean by that? Committing in Git works in two steps.
First modified or untracked files are "registered" for the next commit by using add. This is called staging.
The staged files are then committed with commit :
Note: most other VCSs (e.g. Mercurial and SVN) don't have this two-step structure. They don't have a
staging area.

Note: in Mercurial and SVN, add is only used to put a previously untracked file under version control. In
Git, it has a wider meaning!

Then write a commit message. We'll give you hints for what is a good message.

Monitoring 2
Your second best friend is diff. It shows you changes (differences) between versions. Without
arguments, it shows all changes made to tracked files in the repository since the last commit.

(git diff can also be used to show differences between arbitrary revisions. You can google it.)

Use

to see the commit history on your current branch. I use git log -<number> a lot to only show the -
<number> last commits, e.g.

A question and a suggestion:


 What happens if you track files other than flat text files?
 Create a hidden file .gitignore containing file patterns you want Git to ignore. These files won't
show up in git status. E.g.
Branches
To check which branch you are on:

Working with remote repositories: sharing


See what our remote is:
A quick word on origin and master: these are the default names of the remote repository and the first
branch. They are not magical keywords and you could use different names. However, don't. Unless you
have a good reason.

A common workflow that your team could adopt:

Personally I like a model where every developer has one personal development branch on the shared
repository, named after them (e.g. stefan in my case). (Everyone can have as many additional local
branches as they like, but they're not tracked in the shared repository.) People push to their own
branch, then request a merge into the master/release/common development/whatever branch. At this
point, the others review the code to be merged for correctness, understandability, maintainability, style
& conventions, robustness, resource effectiveness. When any necessary changes have been
made/commited/pushed, the merge request is accepted.

Git's not perfect…


Git is widely used and has many powerful features, but it also has some annoying downsides. You might
already have noticed that it's sometimes quite unintuitive and difficult to use…

In fact, a tutorial like this glosses over the total mess that you will from time to time end up in with Git!

Here is a good post about problematic things in Git: https://stevebennett.me/2012/02/24/10-things-i-


hateabout-git.

It is very instructive to read it! You will realise that sometimes it's not you who's crazy, it's Git. There are
good alternatives to Git: Mercurial ( hg ), which is "better", and Bazaar ( bzr ), which I know nothing
about.

SVN is an older central (i.e. not distributed) VCS and not as powerful as Git and Mercurial. I don't use it
voluntarily.

You might also like