Ex No:7 CONTROL SYSTEMS COMMAND TO CLONE,

COMMIT, PUSH, FETCH, PULL, CHECKOUT, RESET, AND

DELETE
Aim:

Use version control systems command to clone, commit, push, fetch, pull, checkout, reset, and
delete repositories.

Description:

Git is a version control system (software) and GitHub is a source code hosting service. Git is a
version control system for tracking changes in computer files and coordinating work on those files
among multiple people.

A file in git goes through the following stages:

Lets Now, Understand the working of Git
Procedure
Setting Up Git

You need to setup Git on your local machine, as follows:

1. Download & Install:
o For Windows and Mac, download the installer from http://git-scm.com/downloads and
run the downloaded installer.
o For Ubuntu, issue command "sudo apt-get install git".
For Windows, use the "Git Bash" command shell bundled with Git Installer to issue
commands. For Mac/Ubuntu, use the "Terminal".
2. Customize Git:
Issue "git config" command (for Windows, run "Git Bash" from the Git installed directory.
For Ubuntu/Mac, launch a "Terminal"):
3. // Set up your username and email (to be used in labeling your commits)
4. $ git config --global user.name "your-name"
$ git config --global user.email "your-email@youremail.com"
The settings are kept in "<GIT_HOME>/etc/gitconfig" (of the GIT installed directory) and
"<USER_HOME>/.gitconfig" (of the user's home directory.
You can issue "git config --list" to list the settings:
$ git config --list
user.email=xxxxxx@xxxxxx.com
user.name=xxxxxx

Git Commands
Git provides a set of simple, distinct, standalone commands developed according to the "Unix
toolkit" philosophy - build small, interoperable tools.
To issue a command, start a "Terminal" (for Ubuntu/Mac) or "Git Bash" (for Windows):
$ git <command> <arguments>
The commonly-used commands are:
1. init, clone, config: for starting a Git-managedproject.
 2. add, mv, rm: for staging file changes.
3. commit, rebase, reset, tag:
4. status, log, diff, grep, show: show status
5. checkout, branch, merge, push, fetch, pull
Help and Manual
The best way to get help these days is certainly googling.
To get help on Git commands:

$ git help <command>

// or
$ git <command> --help
The GIT manual is bundled with the software (under the "doc" directory), and also available
online @ http://git-scm.com/docs.

Initialize a new Git Repo ( git init)

To manage a project under Git, run "git init" at the project root directory (i.e., "hello-git") (via
"Git Bash" for Windows, or "Terminal" for Ubuntu/Mac):
// Change directory to the project directory
$ cd /path-to/hello-git

// Initialize Git repo for this project

$ git init
Initialized empty Git repository in /path-to/hello-git/.git/

$ ls -al
drwxr-xr-x 1 xxxxx xxxxx 4096 Sep 14 14:58 .git
-rw-r--r-- 1 xxxxx xxxxx 426 Sep 14 14:40 Hello.class
-rw-r--r-- 1 xxxxx xxxxx 142 Sep 14 14:32 Hello.java
-rw-r--r-- 1 xxxxx xxxxx 66 Sep 14 14:33 README.md
A hidden sub-directory called ".git" will be created under your project root directory (as shown
in the above "ls -a" listing), which contains ALL Git related data.

Git Storage Model

The local repo after "git init" is empty. You need to explicitly deposit files into the repo.
Before we proceed, it is important to stress that Git manages changes to files between so-called
commits. In other words, it is a version control system that allows you to keep track of the file
changes at the commits.
Staging File Changes for Tracking ( git add <file>...)
Issue a "git status" command to show the status of the files:
$ git status
On branch master
 Initial commit

Untracked files:
(use "git add <file>..." to include in what will be committed)
Hello.class
Hello.java
README.md
nothing added to commit but untracked files present (use "git add" to track)
By default, we start on a branch called "master". We will discuss "branch" later.
In Git, the files in the working tree are either untracked or tracked. Currently, all 3 files
are untracked. To stage a new file for tracking, use "git add <file>..." command.
// Add README.md file
$ git add README.md

$ git status
On branch master
Initial commit

Changes to be committed:
(use "git rm --cached <file>..." to unstage) new
file: README.md

Untracked files:
(use "git add <file>..." to include in what will be committed)
Hello.class
Hello.java

// You can use wildcard * in the filename

// Add all Java source files into Git repo
$ git add *.java

// You can also include multiple files in the "git add"

// E.g.,
// git add Hello.java README.md

$ git status
On branch master
Initial commit

Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: Hello.java
new file: README.md

Untracked files:
 (use "git add <file>..." to include in what will be committed)
Hello.class
The command "git add <file>..." takes one or more filenames or pathnames with possibly
wildcards pattern. You can also use "git add ." to add all the files in the current directory (and all
sub-directories). But this will include "Hello.class", which we do not wish to be tracked.
When a new file is added, it is staged (or indexed, or cached) in the staging area (as shown in
the GIT storage model), but NOT yet committed.
Git uses two stages to commit file changes:
1. "git add <file>" to stage file changes into the staging area, and
2. "git commit" to commit ALL the file changes in the staging area to the local repo.
The staging area allows you to group related file changes and commit them together.
Committing File Changes (git commit)
The "git commit" command commits ALL the file changes in the staging area. Use a -m option
to provide a message for the commit.
$ git commit -m "First commit" // -m to specify the commit message
[master (root-commit) 858f3e7] first commit
2 files changed, 8 insertions(+) create
mode 100644 Hello.java create mode
100644 README.md

// Check the status

$ git status
On branch master
Untracked files:
(use "git add <file>..." to include in what will be committed)
Hello.class
nothing added to commit but untracked files present (use "git add" to track)

Commit ALL staged file changes via "git commit":

$ git commit -m "Second commit"
[master 96efc96] Second commit
1 file changed, 1 insertion(+)

$ git status
On branch master
Untracked files:
(use "git add <file>..." to include in what will be committed)
Hello.class
nothing added to commit but untracked files present (use "git add" to track)
Once the file changes are committed, it is marked as unmodified in the staging area (not shown in
"Changes to be committed").
Both "git diff" and "git diff --staged" return empty output, signalling there is no "unstaged" and
"staged" changes.
More on "git checkout" and Detached HEAD
"git checkout" can be used to checkout a branch, a commit, or files. The syntaxes are:
$ git checkout <branch-name>
$ git checkout <commit-name>
$ git checkout <commit-name> <filename>
When you checkout a commit, Git switches into so-called "Detached HEAD" state, i.e., the
HEAD detached from the tip of a branch. Suppose that you continue to work on the detached
HEAD on commit-5, and wish to merge the commit-5 back to master. You checkout the master
branch, but there is no branch name for your to reference the commit-5!!!
In Summary, you can use "git checkout <commit-name>" to inspect a commit. BUT you should
always work on a branch, NOT on a detached HEAD.

More on "git reset" and "git reset --hard"

$ git reset <file>
// Unstage the changes of <file> from staging area,
// not affecting the working tree.

$ git reset
// Reset the staging area
// Remove all changes (of all files) from staging area,
// not affecting the working tree.

$ git reset --hard

// Reset the staging area and working tree to match the
// recent commit (i.e., discard all changes since the
// last commit).

$ git reset <commit-name>

// Move the HEAD of current branch to the given commit,
// not affecting the working tree.

$ git reset --hard <commit-name>

// Reset both staging area and working tree to the given
// commit, i.e., discard all changes after that commit.

[TODO] Diagram
[TODO] --soft option
Summary of Work Flows
Setting up GIT and "Edit/Stage/Commit/Push" Cycle
Step 1: Install GIT.
• For Windows and Mac, download the installer from http://git-scm.com/downloads and run
the downloaded installer.
 • For Ubuntu, issue command "sudo apt-get install git".
For Windows, use "git-bash" command shell provided by Windows installer to issue command.
For Mac/Ubuntu, use "Terminal".
Step 2: Configuring GIT:
// Setup your username and email to be used in labeling commits
$ git config --global user.email "your-email@yourmail.com"
$ git config --global user.name "your-name"
Step 3: Set up GIT repo for a project. For example, we have a project called "olas1.1" located at
"/usr/local/olas/olas1.1".
$ cd /usr/local/olas/olas1.1

// Initialize the GIT repo

$ git init

$ ls -al
// Check for ".git" directory
Create a "README.md" (or "README.textile" if you are using Eclipse's WikiText in "textile"
markup) under your project directory to describe the project.
Step 4: Start "Edit/Stage/Commit/Push" cycles.
Create/Modify files. Stage files into the staging area via "git add <file>".
// Check the status
$ git status
......

// Add files into repo

$ git add README.md
$ git add www
......

// Check the status

$ git status
......

Step 5: Create a ".gitignore" (in the project base directory) to exclude folders/files from being
tracked by GIT. Check your "git status" output to decide which folders/files to be ignored.
For example,

# ignore files and directories beginning with dot

.*

# ignore directories beginning with dot (a directory ends with a slash)

.*/

# ignore these files and directories

www/test/
www/.*
www/.*/

The trailing slash indicate directory (and its sub-directories and files).
If you want the ".gitignore" to be tracked (which is in the ignore list):
$ git add -f .gitignore
// -f to override the .gitignore
Step 6: Commit.
$ git status
......

// Commit with a message

$ git commit -m "Initial Commit"
......

$ git status
......
Step 7: Push to the Remote Repo (for backup, version control, and collaboration).
You need to first create a repo (says olas) in a remote GIT host, such as GitHub or BitBucket.
Take note of the remote repo URL, e.g., https://username@hostname.org/username/olas.git.
$ cd /path-to/local-repo

// Add a remote repo name called "origin" mapped to the remote URL
$ git remote add origin https://hostname/username/olas.git

// Push the "master" branch to the remote "origin"

// "master" is the default branch name of your local repo after init.
$ git push origin master

Check the remote repo for the files committed.

Step 8: Work on the source files, make changes, commit and push to remote repo.
// Check the files modified
$ git status
......

// Stage for commit the modified files

$ git add ....
......

// Commit (with a message)

$ git commit -m "commit-message"

// Push to remote repo

$ git push origin master
Step 9: Create a "tag" (for version number).
// Tag a version number to the current commit
$ git tag -a v1.1 -m "Version 1.1"
// -a to create an annotated tag, -m to provide a message

// Display all tags

$ git tag
......

// Push the tags to remote repo

// ("git push -u origin master" does not push the tags)
$ git push origin --tags
.
Fetch/Merge Changes from remote ( git fetch/merge)
The "git fetch" command imports commits from a remote repo to your local repo, without
updating your local working tree. This gives you a chance to review changes before updating
(merging into) your working tree. The fetched objects are stored in remote branches, that are
differentiated from the local branches.
$ cd /path-to/working-directory

$ git fetch <remote-name>

// Fetch ALL branches from the remote repo to your local repo

$ git fetch <remote-name> <branch-name>

// Fetch the specific branch from the remote repo to your local repo

// List the local branches

$ git branch
* master
devel
// * indicates current branch

// List the remote branches

$ git branch -r
origin/master
origin/devel

// You can checkout a remote branch to inspect the files/commits.

// But this put you into "Detached HEAD" state, which prevent you
// from updating the remote branch.

// You can merge the fetched changes into local repo

$ git checkout master
 // Switch to "master" branch of local repo
$ git merge origin/master
// Merge the fetched changes from stored remote branch to local

git pull
As a short hand, "git pull" combines "git fetch" and "git merge" into one command, for
convenience.
$ git pull <remote-name>
// Fetch the remote's copy of the current branch and merge it
// into the local repo immediately, i.e., update the working tree

// Same as
$ git fetch <remote-name> <current-branch-name>
$ git merge <remote-name> <current-branch-name>

$ git pull --rebase <remote-name>

// linearize local changes after the remote branch.
The "git pull" is an easy way to synchronize your local repo with origin's (or upstream) changes
(for a specific branch).

Pushing to Remote Repo (revision)

The "git push <remote-name> <branch-name>" is the counterpart of "git fetch", which exports
commits from local repo to remote repo.
$ git push <remote-name> <branch-name>
// Push the specific branch of the local repo

$ git push <remote-name> --all

// Push all branches of the local repo

$ git push <remote-name> --tag

// Push all tags
// "git push" does not push tags

$ git push -u <remote-name> <branch-name>

// Save the remote-name and branch-name as the
// reference (or current) remote-name and branch-name.
// Subsequent "git push" without argument will use these references.
Result:

Thus, the control commands executed in GIT.