•git clone: Get the complete project from remote to your local machine

•git pull origin <branch_name>: Get the new changes from remote branch to local branch
•git push origin <branch_name>: Send your local branch changes to the remote branch
•git remote add <name> <url>: Add a new remote repo link to your local repo
•git remote -v: List all the remote repo URLs linked to your local repo

For Linux
Type the following commands from the Shell.
$ sudo apt-get update

$ sudo apt-get install git

After successful installation of Git, you can configure your user name and e-mail ID using
the following commands.
$ git config --global user.name "First Last"

$ git config --global user.email "[email protected]"

Git Terminologies
Before starting with the basics, let's explore a few terminologies:
• Git Repository: A directory with .git folder, where all the contents are tracked for
changes.
• Remote: It refers to a server where the project code is present. For example, Github
and Gitlab.
• Commit: It is similar to version. When you make changes in a file, you need to commit
the changes in order to save and create its new version, which will create a unique
commit hash (like version number).
• Origin: It is a variable where Git stores the URL of your remote repository. For
example, origin => www.github.com/username/myrepo
git init adds .git folder and initializes the current folder to track its changes
•git status displays the current state of the staging area and the working directory, that
is, which files are added/removed/modified
•git diff shows the exact changes with line and column number
•git add adds the changes to the staging area. If you have added a new file, this
command starts tracking the file for modifications.
•git commit will save all the changes with a unique hash number in the local repository
•git push sends the changes to the remote repository (server)
The following are the three stages in the Git workflow:
•Working Area: You can edit files using your favorite editor/Integrated Development
Environment (IDE).
•Staging Area: You have made the changes and added the changes to Git. You can still
make changes here. (From the analogy explained in the next card) It is like taking an
item out of the box, where the box is the staging area. (git add)
•Local Repository: You have finalized the changes and committed them with a new
hash and proper message. (git commit)
Remote Repository: You can now push the changes to online platforms like Github or Gitlab
from where others can collaborate. (git push)
Git works in three stages known as The Three Trees: Working Area, Staging Area, and Local
Repository, which means Git maintains three states of a file. To understand this better, let us
take an analogy of a box.
Assume you are packing items in the house in different boxes and labeling them to identify
it later.
•Get a table and keep all the items that you want to pack underneath. ( git init)
•Now you might select specific kitchen items, dust them, and club similar items (like
spoons) together. (doing changes - Working area)
•Add the items that are ready to the box. (git add - Staged)
•Seal the box and add a label - 'Kitchen Items'. (git commit - Committed)
After git commit, a unique hash is created and the changes are saved.
If you do not want Git to track any file/directory, you can add the file/directory
to .gitignore file. To track an empty directory, you need to add .gitkeep to that empty directory,
as Git ignores them by default.

To visualize the commands and see how your repository

changes with time, you can try out Git commands
in visualizing-git.
When a directory is part of a repository, it is called a Working Directory. A working directory contains the
latest version downloaded from the repository, together with the changes that are to be committed. All
changes are made in the working directory.
To view the files that have changed between your working directory, and those previously committed to
the repository, use the command git status.
The output of this command is called the "working tree status".

Hint:
All files are "untracked" by Git unless mentioned otherwise.
Once a file has been added to the staging area, it must be committed to the repository. The command git
commit -m "commit message" moves files from staging to the repository, and records the time/date, author,
and a commit message that can be used to add additional context and reasoning to the changes, such as a
bug report number.
Only changes added to the staging area are committed. Files in the working directory that have not been
staged, are not included.

Task
Use git commit -m "<commit message>" to commit the staged file.

Hint:
Each commit is assigned a SHA-1 hash, which enables you to refer to the commit in other commands.
Step 5 - Git Ignore
Sometimes there are particular files or directories you never want to commit, such as local development
configuration. To ignore these files, create a .gitignore file in the root of the repository.

The .gitignore file allows you to define wildcards for the files you wish to ignore. For example, *.tmp will
ignore all files with the extension '.tmp'.

Any file matching a defined wildcard will not be displayed in a git status output, and will be ignored when
the git add command is attempted.

Task
Add and commit a .gitignore file to the repository to ignore all *.tmp files.

Hint:
The .gitignore should be committed to the repository to ensure that the rules apply across machines.

Git History
With multiple developers pushing new commits and changes, you might want to view the
history of everything that happened with the repository.
Git provides the following commands, which allows you to read and review your repo's
history:
• git log
• git show
• git diff
Before learning more about these tools, you must first understand the HEAD and Dot
operators.
HEAD is a reference variable that always points to the tip of your current branch,
that is, recent commit of your current branch.

HEAD can be used with the following symbols to refer to other commits:

•Tilde symbol (~): Used to point to the previous commits from base HEAD
•Caret symbol (^): Used to point to the immediate parent commit from the current
referenced commit
You can use both tilde and caret symbols in combination with HEAD to refer specific
commit:
•HEAD means (the reference to) the recent commit of current branch -> F
•HEAD^1 means First parent of F -> E
•HEAD^2 means Second parent of F -> error as there is only one
immediate parent commit
•HEAD~1 means (the reference to) one commit before HEAD -> E
•HEAD~1^1 means First parent of E -> C
•HEAD~1^2 means Second parent of E -> D
•HEAD~1^3 means Third parent of E -> error
 •HEAD~3 means (the reference to) three commits before HEAD -> B

Double Dot Operator

•It is the default operator in git diff
•git diff master..feature or git diff master feature command will display all the differences from
G to C (that is, including F and G)

Triple Dot Operator

•It shows the difference between master and feature branch starting at the last
common commit E.
•git diff master...feature command's output would be the difference in feature branch
(that is, only A, B, and C)

Git Log
Git log command shows the list of commits in the current branch. You can use it in the
following ways:
• git log -2 displays the history of last two commits
• git log commit_id shows the history starting from commit_id
• git log filename displays the list of commits for the file
Flags
You can enhance the output of git log command using these optional flags:
• --oneline: Fits the log output to a single line
• --decorate: Adds a symbolic pointer to the output
• --graph: Gives a graphical representation to the log output
• --grep=<pattern>: Filters the log output and displays the output which matches the
specified pattern
For example, git log --oneline

all right so now I want to talk about some tips and tricks we can use with a git log command
you've seen that command come up quite a bit just get log and the standard command is
just gonna print to you each commit the entire shocky the author the date and the message
that was in it and it's just gonna have to scroll through all of them and you know a lot of
times you guys saw me use git log - - one line which is just gonna condense everything it's
very nice you can just kind of see quickly but git log has a lot of very nice tools with it that
will allow us to kind of search and manipulate our git log and what it returns to allow us to
kind of get a better picture so for example just kind of off the back here we can do git log
one-line and let's say I only want to see the last three commits because it's very possible in
your project you are gonna be dealing with hundreds of commits you know if you're doing
with an open-source project you might very well be dealing with thousands of commits so I
want to say just show me the last three commits so just after my command I just do a dash
3 just going to show me the most recent last three commits maybe I want to do show me
the commits since and let's see here I'm just gonna do 2013 June today's the 18 so I'll say
since the 17th it's gonna say oh well we have one commit that was made on June 18th
today and that was this commit everything else was before this commit so I'm not going to
show it to you well now let's say hmm well you know maybe I want to see those commits
why I say git log - - until equals I'm gonna do 2013 - oh six let's do the ninth so there were
no commits I want to say show me all the commits until that day so it's saying no commits
were made before that day well maybe if I do the 15th oh there we go so it's said oh we
have three commits actually we're done on June 15th so this is a very nice feature of if you
need to go back to a certain day that's always nice you can even do a you know gets pretty
smart it can read straight-up text I can say since 2 dot weeks nope sorry nope that's not
why I'm into since and then I do equals two weeks ago there you go and now it's gonna
show me all the commits for the last two weeks so you know that's always a really nice
feature you know that's come pretty much all of them so I'm gonna have to get through that
another thing we can do is get log author equals Joe so show me all the commits that Joe
did oh well pretty much all of them that's nice I can search by their email too I could say
show me get log from you know I can do to shock ease so I can do the shocky of one
commits let's just go ahead and do it I'm gonna do a git log one-line I can do a git log from
let's do I'm gonna I want all of these commits let's say I know the two commits I want to see
all of these and the messages that were made between them so I can do seven three seven
seven one seven F I just do dot dot and then I do seven one F to a be seven so that's going
to show me all the this commit this commit of this commit and this met these four cool
sorry these four commits and so pretty much that dot dot all it did was say all of them in
between these two so I have these four commits right here if you want to kind of see oh oh
there's a story between these two commits there's a lot of these I could go on there's a stat
which shows you more of here's individually what was each added for each one we could do
as you can see that once you do these you get really long let's do git log one-line and look at
some others git log there's format equals short that's going to get rid of that whole when it
was added it's gonna try to simplify things again we know we both know there's really long I
think one line is still the best way to go I'm not gonna you know show you everything the
one there's tons of them one one that I like to do the most popular one here I'll just
combine a lot of them I can do online graph or one line sorry one line graph all decorate so
that's gonna show me where my head my master is it's gonna decorate which allows for
these different colors show all of them and one line so it's also gonna have this nifty little
branch tool on the side which can visually show you where the branches are and we're
going to get into branches in our next section here but this is a very useful kind of combo
that you can use to allow yourself to see the big picture and it's also going to show you
what head you're on and what branch you're on so hopefully look up online if you're looking
kind of for more ways but know that there are a lot of useful tools in order for you to search
and manipulate the git log command you .

Git Show
git show is a versatile command which is similar to git log, but with few additional features.

You can pass different arguments like:

• commit_id
• tree
It shows the author's name, timestamp, commit message, and difference from the previous
commit.
For commit range git show --oneline HEAD~2..HEAD, it gets resolved, and each commit is
displayed individually

Git Diff
git diff function takes two input datasets and outputs the changes between them.

Datasets can be commits, branch, files and more.

git diff HEAD~1 HEAD shows the difference between two commits.

Let us take a sample git diff output as follows.

diff --git a/sample.txt b/sample.txt

index 8d3g6cv..f94e50c 574641

--- a/sample.txt

+++ b/sample.txt

@@ -1 +1 @@

-this is a git diff test example

+this is a diff example

• The linediff --git a/sample.txt b/sample.txt displays the input file for git diff
• --- a/sample.txt +++ b/sample.txt
The changes from a/sample.txt are marked with --- and changes from b/sample.txt
are marked with +++ symbol.

Cheat Sheet
• git log -p: Prints full details of each commit
• git log --grep-reflog=<pattern>: Shows the list of commits when commit message matches
regular expression pattern
• git log --follow ./path/to/filename: Shows the history for the current file
• git show: Outputs content changes of the specified commit
• git diff --color-words: Output has only the color-coded words that have changed
• git diff –staged: Shows the file differences between staging and the last committed
version
• git diff .path/to/file: Shows changes in a file compared to the previous commit

Local to Remote
In the previous topic, whatever you have learned was mostly limited to your local
machine. To collaborate with other developers, you need to push your work to the remote
repository, and vice-versa, you need to pull others' work from remote to contribute your
work to the project.
In Git, remote is a repository on a server where all your team members can place
the code to collaborate

Remote URL Types

You can keep your project code in remote servers like GitHub, GitLab or on a self-hosted
server. Git sets a default name for your remote URL as origin
Remote URL can be one of the two types:
• HTTPS URL like https://github.com/user/repo.git: You can clone/push using your user name
and password
• SSH URL, like [email protected]:user/repo.git: You need to configure SSH keys in
Github/Gitlab account and local machine
Keep reading to find out the Git commands used to collaborate with other developers.

Git Clone
To get source code of an already existing project from remote repo (For example, Github),
you can use git clone <url> command.
For example, git clone https://github.com/facebook/react.git
This command downloads the complete project, all branches, commits and logs from the
given remote URL (react repo here) to your local machine.

Git Pull
Your teammate has pushed the changes to the project's remote repo where you are also working.
You can now pull the changes to your local machine using any one of the following commands.
• git pull is the convenient shortcut key to fetch and merge the content.
• git pull <remote_name> <branch_name>
• git fetch command downloads the remote content to your local repo, without changing your
code changes.
• git fetch <remote_name> <branch_name> fetches the content from that specific branch in
remote to your current working area
• git merge command merges the fetched remote content to the local working tree.
• git merge <remote_name>/<branch_name> merges the content to the specified branch.
Git Push
To keep your changes and work in remote repo, you need to push the branch using the
command git push <remote_name> <branch_name>
Git push takes two arguments, namely:
• <remote_name>
• <branch_name>
For example, git push origin master, where:
• origin will contain the remote URL
• master is the branch that is pushed (We shall discuss branches later in this course)

Working with Existing Projects

Peter is new to the project. For a particular task, he created ten new files in his
local machine. His technical lead said there is a common repo where all the team
members place their code. He asked Peter to push his files to the same repo.
What should Peter do?
In such a scenario, you can connect your local repo with an existing remote repo using git
remote add command.

Git Remote
The syntax to link your local repo with remote repo is:
git remote add <remote_name> <remote_url>

It takes two arguments, namely:

• <remote_name>, let us take default name origin
• <remote_url>, let us take https_url https://github.com/play/repo.git
For example: git remote add origin https://github.com/play/repo.git

Note: Y
A Branch is a copy of your complete project, where you can add new changes and develop
new features. Technically, it is a collection of commits.
When you create a new Git project, it has a branch called master by default. Even in the
projects you clone from Github/Gitlab, a master branch is always present. Master branch
usually has the stable and working version of your application, and hence it can be
modified only by a few access-controlled users.

To build new features without affecting the current working code, you need to:
•Create new branch from the master git branch <branchname>. Here you will write code
for the new feature.
 •Merge the feature branch with the master (or other branch where you want it to be).
You can merge two branches locally or in remote.
Keep reading to learn more about branches in Git.

Branch Operations
You can do the following with branch:
• Creating new branch: git checkout -b <branch-name>
• Pushing branch from local to remote repo: git push origin <branch-name>
• Renaming branch:
• Renaming local branch: git branch -m old-name new-name
• Renaming remote branch: git push origin :old-name new-name
• Deleting branch:
• Deleting local branch: git branch -d <branch-name>
• Deleting remote branch: git push origin -d <branch-name>

In a project, two developers need to build sign-in and sign-up pages at the same
time. How can they do that without affecting the existing application?

They can create new branches for each new feature, such as signin and signup branches and
work on the features parallelly.

Building New Feature: Signin

For a new feature to be built:
• Create a new branch from the master branch: git checkout -b signin
• Add your new code in the new feature branch: git add -A
• Commit your changes once done: git commit -m "add signin page"
• Push your changes to the remote: git push origin signin
As your sign-in feature is ready in a different branch, now you can merge it with the master
branch.

Note: Merging will be discussed in the next topic.

To see the difference between two branches (master

branch and test branch), you can execute the following
command
git diff master test
Cheat Sheet
• git branch -a: Lists all the branches
• git branch -d <branch-name>: Deletes the branch in local repo
• git checkout -b: Creates a branch and switches to it
• git checkout <branch-name>: Switches to the provided branch

Integrating Changes
Once you have developed your feature in a separate branch, you need to integrate the
feature and master branch. You can do that using one of the following two commands:
• merge
• rebase
git merge <branch>: Merges <branch> to current branch
•git rebase <base>: Rebases the current branch onto the base (branch name, commit ID,
tag)
•git rebase -i <base>: Performs interactive rebase. Launches editor where you can
specify command on each commit to transform it.
•git rebase --abort: Cancels rebasing and goes back to the previous commit
•git rebase --continue: Continues rebasing after resolving the rebase conflicts
•git pull --rebase: Fetches the remote copy and rebases it into the current branch of the
local copy

Create a new repository for every new project

•Create a new branch for every new feature
•Let branches be temporary, that is, delete the merged branch
•Write a good descriptive commit message, where:
•The first line should not be more than 75 characters
•Fix, Feature, or Update is present at the start of your commit message
•Use Pull Request (PR) to merge your code with master.

You started the Journey by exploring the Prodigious Git course and then completed
the Interstellar Git.
Let us have a quick recap of the concepts covered in this course:
1.git cherrypick (Moving commits between branches)
 2.git stash (Saving changes temporarily)
3.git submodules (Adding a subproject)
4.git Blame (Finding the author of a line)
5.git Bisect (Finding the commit which introduced a bug)
6.git reflog (Retrieving deleted commits)
7.git hooks (Automating things using script)
Hope you enjoyed the course!

Git Checkout Bye!