Friday, April 6, 2018

Introduction to GIT


  1. Getting a Git Repository
  2. Recording Changes to the Repository
  3. Viewing the Commit History
  4. Working with Remotes

1 Getting a Git Repository

This guide contains the basic commands required to work with Git.

How to get a Git repository

You can get a Git repository in two ways:

  • turn a local directory into a Git repository
  • get a copy of an existing repository
Initializing a Repository in an Existing Directory

You have a project directory, not under version control, you want to control with Git

  • go to the directory of the project
  • type git init

The git init command create a .git subdirectory that contains the files required by the Git repository.

Cloning an Existing Repository

To get a copy of an existing Git repository use the clone command

  • you can clone a project's repository you want to contribute to.

For example, you can clone the Oracle's First Cup Java Tutorial with the following command:

  • $ git clone
  • it is said that the command pulls down or check out a working copy of the latest version

To clone the Oracle's First Cup Java Tutorial in a target directory of your choice use the command:

  • $ git clone firstCupJavaTutorial

2 Recording Changes to the Repository

Recording Changes to the Repository

Now, you want to make change to files and commit snapshots into your repository.

Files in your working directory can be in two states: traked and untraked.

  • Traked files are files that were in the last snapshot.
    • traked files can be: unmodified, modified and staged
    • when you clone a repository, the files in your working directory are all traked and unmodified
  • Untraked files are files in your working directory that were not in the last snapshot or in the Staging area.
    • a file just created is in the untracked state
Checking the Status of Your Files

The git status command allows you to determine in which state your files are.

If you run the git status command after a clone, you should see an output like the one below:

user@host:~$ cd firstcup-examples/
user@host:~/firstcup-examples$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean

The Git status command also tell you in which branch you are on: master is the default branch.

Adding a new file to your project

Add a new file, the README file, to your project and run the git status command to see what has happened.

user@host:~$ cd firstcup-examples/
user@host:~/firstcup-examples$ vim README
user@host:~/firstcup-examples$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

Untracked files:
  (use "git add ..." to include in what will be committed)


nothing added to commit but untracked files present (use "git add" to track)

The git status command shows the README file as untracked.

Tracking New Files

To begin traking a new file, you use the git add command.

user@host:~/firstcup-examples$ git add README

Run the git status command, again. The README file now is traked and staged.

user@host:~/firstcup-examples$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

Changes to be committed:
  (use "git reset HEAD ..." to unstage)

 new file:   README

Staging Modified Files

Modify the file and run the git status command.

user@host:~/firstcup-examples$ vim
user@host:~/firstcup-examples$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

Changes to be committed:
  (use "git reset HEAD ..." to unstage)

 new file:   README

Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)



The modified file appears under the “Changes not staged for commit” section.

  • run the git add
  • run the git status command again
user@host:~/firstcup-examples$ git add
user@host:~/firstcup-examples$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

Changes to be committed:
  (use "git reset HEAD ..." to unstage)

 new file:   README


Both files are staged

The git add command is used to:

  • to start traking new files
  • to stage modified files
  • to mark merge conflict as resolved

If you modify the file again, the file will appear both in the staged files and in the unstaged files.

$ vim
$ git status

On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD ..." to unstage)

    new file:   README

Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)


Every time you modifiy a staged file, you have to run git add to stage the latest version of the file.

Ignoring Files

Suppose you have a class of file you don't want Git to automatically add to staging area or show as being untraked.

  • you can create a file named .gitignore with patterns of names of files that are to be ignored.

Below a sample .gitignore file for java projects.

# Compiled class file

# Log file

# Package Files #

# virtual machine crash logs, see

The first line tells Git to ignore any files ending in “.class” — class files that are the product of building your code. The second line tells Git to ignore log files, etc.

The rules for patterns in the .gitignore file use standard glob patterns that shells employ.

Viewing Your Staged and Unstaged Changes

The git diff command shows you what has changed, but is more accurate than the status command.

  • while the status command shows you which files are changed, the diff command shows you what is changed
  • the diff command shows you the patch: the lines of code added and removed.
  • use the git diff command to see:
    • what you have changed but not yet staged
    • what you have staged and you are going to commit

The command git diff without arguments shows you what you have changed but not yet staged

  • the command compares what is your working directory and what is in your staging area.

The command git diff --staged (or git diff --cached) shows you the changes you have staged and are going to be committed

  • this command compares the changes you have staged to your last commit
Committing Your Changes

When you want to take a snapshot of your project, commit your changes.

The simplest way to commit is to type the git commit command:

  • this launches the editor you configured with the git config --global core.editor command
  • the editor displays a default message:

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Your branch is up-to-date with 'origin/master'.
# Changes to be committed:
#       modified:
#       new file:   README

The default message contains an empty line and the latest output of the git status command. If you run the command git commit -v , the -v option put the diff of your change in the commit message.

Alternatively, you can use the commit command with the -m flag and pass an inline message for the commit

  • for example: $ git commit -m "fix the xxx bug in the YYY file"

A commit records a snapshot of the changes you prepared in the staging area. Things in the working directory you didn't stage do not take part in the commit. You can always revert to or compare your project to a snapshot you previously recorded.

Removing Files

To remove a file from the git repository run the git rm <file> command

  • the git rm <file> command delete the file from working directory and staging area
  • after using the rm command, you have to commit the changes

The bash rm <file> command only remove the file from the working directory

How to make Git stop to trak a file and keep it in your working directory

  • to mark a file as untraked, it means the file is removed from the staging area
  • to stop traking a file run the git rm --cached <file> command
Moving Files

To rename a file in git use the git command: git mv <file-from> <file-to>

3 Viewing the Commit History

Viewing the Commit History

If you want to see the history of all the commits on a repository, use the git log command

The git log command (used without arguments) lists the commits made in a repository from the most recent to the oldest ones.

  • for each commit, it shows checksum, author, date and message

The git log command option -p or --patch shows the difference or patch for each commit.

The git log command option --pretty=<option> produces different output according to the option passed

  • for example git log --pretty=oneline produce a single line information
  • other options are --pretty=short, --pretty=full and --pretty=fuller
  • you can also pass a format string to specify your own output format
  • the --graph log option adds an ASCII graph showing branch and merge history

4 Working with Remotes

Working with Remotes

If you want to collaborate on a Git project, you must know how to handle remote repositories. A remote repository is a version of a project that is hosted on a machine connected to the internet or network. A Git project can have multiple remote repositories, each one is read-only or read/write.

Working with a remote repository implies:

  • pushing and pulling data to and from repositories
  • adding new repositories and removing invalid repositories
  • managing different branches

Note: it is possible to have a remote repository on the same host you are.

Showing Your Remotes

The git remote command lists which remote severs have been configured:

  • if your repository was cloned, the remote command prints origin
  • origin is the default name Git gives to the server from which your repository was cloned.
  • the -v option lists name and URL for each remote repository.
  • name and URL are used when reading and writing to that remote
user@host:~$ git clone
Cloning into 'firstcup-examples'...
remote: Counting objects: 194, done.
remote: Total 194 (delta 0), reused 0 (delta 0), pack-reused 194
Receiving objects: 100% (194/194), 29.64 KiB | 210.00 KiB/s, done.
Resolving deltas: 100% (69/69), done.
user@host:~$ cd firstcup-examples/

The firstcup-example Java repository has only one remote.

user@host:~/firstcup-examples$ git remote

See name and URL of the remote of the firstcup-example repository

user@host:~/firstcup-examples$ git remote -v
origin (fetch)
origin (push)

A repository with multiple remotes allows to work with many collaborators

  • you pull contributions from any remotes
  • you may additionaly have permission to push your commits, but you can't understand that here

If you run the git remote -v command on a repository with multiple remotes, the output is likely to look like this:

$ cd grit
$ git remote -v
backstab (fetch)
backstab (push)
cho45 (fetch)
cho45 (push)
merten (fetch)
merten (push)
softdrink  git:// (fetch)
softdrink  git:// (push)
origin (fetch)
origin (push)
Adding Remote Repositories

The git remote add <name> <url> command adds a new remote repository.

  • you can reference the remote you added by its name
  • you can use the remote's name in the command line, while executing commands to pull contributions
  • the git clone command implicitly adds that remote repository under the name "origin"
Fetching and Pulling from Your Remotes

The git fetch <name> command gets data from that remote repository.

  • after the command execution, you have all that remote's branches, which you can merge or inspect
  • the git fetch origin command pulls data from the origin remote, added when your repository was cloned

The git fetch command only download data the local repository and does not merge them.

  • the git fetch command does not modify the current working directory
  • you have to merge the downloaded data into your working directory manually

Git Branching

When you run the git command, Git creates a commit object and stores this object in the Git repository. If you commit again, the following commit stores a reference to the commit that came immediately before it. As you make more commits, the history of your project creates a stream of snapshots in the Git repository.

A branch in Git is simply a movable pointer to one of these commits. When you make the first commit, this creates a branch, which is named by default master. The master branch points to the last commit you made. Every time you commit, it moves forward automatically.

In versioning systems, the term branching is used to indicate that you diverge from the main line of development and continue to work and commit into a different line. In Git, the creation of a new branch implies the creation of a new pointer to commit objects.

If a repository has several branches, Git knows what branch you’re currently on by using a special pointer called HEAD. The HEAD is a pointer to the local branch you’re currently on: usually you are on master.

A Git 'tracking branch' is a local branch that is connected to a remote branch. When you push and pull on that branch, it automatically pushes and pulls to the remote branch that it is connected to

If your current branch tracks a remote branch, the git pull command fetches data from the remote and tries to merge that remote branch in your current branch.

  • as the git clone command implicitly sets your local master branch to track the master branch on the remote you cloned from, the git pull command fetches data from the origin remote and automatically tries to merge it into your working tree
  • generally, it’s better to use the fetch and merge commands explicitly than the pull command
Pushing to Your Remotes

To share your work, you push the commits you have done to a remote that you have write access.

The git push <name> <branch> command pushes the branch to the remote with that name

  • for example: git push origin master pushes the master branch to the origin remote
$ git push origin master

The above push command works only if nobody has pushed since you cloned your repository.
If somebody has already cloned and pushed:

  • your push will be rejected
  • you have to fetch their work and merge it with yours, before being allowed to push
Inspecting a Remote

The git remote show <name> command shows information about a remote repository.

  • for example: git remote show origin
  • the output lists: the URL for the remote repository, traking branches and how your local branches are configured for the push and pull commands

An output of the git remote show command may look like below:

$ git remote show origin
* remote origin
  Fetch URL:
  Push  URL:
  HEAD branch: master
  Remote branches:
    master tracked
    dev-branch tracked
  Local branch configured for 'git pull':
    master merges with remote master
  Local ref configured for 'git push':
    master pushes to master (up to date)
Renaming and Removing Remotes

The command git remote rename <from-name> <to-name> change a remote's name.

  • when you rename a remote also tracking branches are renamed

The command git remote remove <name> removes a remote.

  • when you remove a remote, you also remove tracking branches with that remote

No comments :

Post a Comment