Git Basic and The mistake I have done in Git

#Install Git

How to installation git in Debian and Ubuntu

Install git via ubuntu terminal
$ sudo apt-get install git

Git version check
$ git --version
git version 2.17.1

#Git 1

Create a new repository and clone into local

Login to your github/bitbucket/gitlab account and create new repository

When you create your repository you will get this

# You can push your first commit from your local project using this command. 
# Go to your local project and execute following command to push your first commit.
$ echo "# git-practice" >> README.md
$ git init
$ git add README.md
$ git commit -m "first commit"
$ git remote add origin https://github.com/mahfuz110244/git-practice.git
$ git push -u origin master

You can also clone this repository to your local then manage your project. Suppose we want to start a new django project for git practice. First go to your desired location in local.

# Go to following directory where we want to clone git-practice repository
$ cd /var/www/
# Clone git-practice repository
$ git clone https://github.com/mahfuz110244/git-practice.git
Cloning into 'git-practice'...
warning: You appear to have cloned an empty repository.
# Check your clone repository
$ ls
$ betterstories  flask  git-practice  lily  react  react-js  revera_api  robi-winit
# Then go to your git-practice directory
$ cd git-practice/

#Git 2

How to push your first commit in GIT?

In the empty project I will add a django project mysite. Lets do it.

# Create virtual environment
$ virtualenv -p python3.6 venv
Running virtualenv with interpreter /usr/bin/python3.6
Using base prefix '/usr'
New python executable in /var/www/git-practice/venv/bin/python3.6
Also creating executable in /var/www/git-practice/venv/bin/python
Installing setuptools, pkg_resources, pip, wheel...done.
# Activate virtual environment
$ source venv/bin/activate
# Install django
$ (venv) pip install django
# make a django project mysite
$ (venv) django-admin startproject mysite
# Add a requirements file
$ (venv) pip freeze > requirements.txt
# Add a gitignore file
$ (venv) touch .gitignore

Let check and add the git commit file

# Check for commited file
$ git status
# Add all file for commit
$ git add .
# Check again for added commited file
$ git status

Now commit and push the added file

# Let put your first commit
$ git commit -m "[master] my first commit with a django project mysite"
# Let push your commit to master branch providing your github username and password
$ git push origin master

After sucessfully push you will find this

Let add a README file

# Create a README.md file
$ touch README.md
# Let commit and push this README.md file
$ git add .
$ git commit -m "[master] add a README file"
$ git push origin master
# Again you need to provide your github username and password
# We can save username and password checkout Git 6

#Git 3

How to create new branch and feature development branch in Git?

In professional development we need to create minimum three major branch must. Branches name should like this

• master - Production Server
• stage - QA/Staging Server
• develop - Developer default local server

Lets create this major branches

$ git checkout -b new-branch-name copy-branch-name
$ git checkout -b stage master
$ git checkout -b develop stage

Now we are in develop branch. Lets run the django project.

$ cd mysite/
$ python manage.py runserver 8000

We want to develop a django app polls. This is one of feature of this project. So we should make a feature branch copy from develop branch.

New branch name should be in this sequence username/token/branch-name-by-hyphen. Here

• username - Owner of the branch
• token - Branch type
• branch-name-by-hyphen - Branch name

Token

• feat - A feature branch
• hotfix - Hotfix changes for production issues
• bugfix - A bugfix branch
• chore - Cleaning up / organizing the code
• wip - Branched out for some WIP stuff that has to be pushed You can checkout this link for the convention of branch name. Convention

Lets create poll app feature branch.

# Checkout to new poll-app-feature branch 
$ git checkout -b mahfuz110244/feat/poll-app develop
# Create a django polls app
$ python manage.py startapp polls

Rest of the Polls app part, you can follow DJango official tutorial from this link Polls

Now commit and push this polls app.

#Git 4

How to merge branch in Git?

We will merge mahfuz110244/feat/poll-app branch to develop.

https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
# Merge mahfuz110244/feat/poll-app branch to develop
$ git checkout develop
$ git merge mahfuz110244/feat/poll-app
$ git push origin develop

# Merge develop branch to stage
$ git checkout stage
$ git merge develop
$ git push origin stage

# Similarly we can merge stage branch to master

#Git 5

How to save username and password in Git?

Every time we need to give credential when we push any commit to remote. We can save our username and password using below git command.

$ git config --global credential.helper store

#Git 6

How to unstage any added file in Git?

In our simple poll app, we’ll create two models: Question and Choice. A Question has a question and a publication date. A Choice has two fields: the text of the choice and a vote tally. Each Choice is associated with a Question.

# initial migration for Django App
$ python manage.py migrate
# Check for file changes that are not stage
$ git status
$ git add polls/models.py
# Check for commited file
$ git status

# Now unstage the models.py file
$ git reset HEAD polls/models.py

#Git 7

How to change the last commit log message in Git?

Let’s say you just committed and you made a mistake in your commit log message. So we can change the commit log message using git amend command until push to the remote.

# Change most recent Git commit message
$ git commit --amend -m "an updated commit message"

Sometimes we forget to add any file in the commit. But after commit we can add the missing file using git amend command.

# Edit models.py and enums.py git add models.py git commit 
# Realize you forgot to add the changes from main.py git add main.py 
$ git commit --amend --no-edit

#Git 8

How to rollback to last commit push or any commit push in Git?

First you need to know the last push commit id or desired commit id HEAD No that you want to rollback. Using git reflog you can get your HEAD No.

Reflog

Reference logs, or “reflogs” are a mechanism Git uses to record updates applied to tips of branches and other commit references. Reflog allows you to go back to commits even though they are not referenced by any branch or tag. After rewriting history, the reflog contains information about the old state of branches and allows you to go back to that state if necessary. Every time your branch tip is updated for any reason (by switching branches, pulling in new changes, rewriting history or simply by adding new commits), a new entry will be added to the reflog.

$ git reflog

# show output
66a1920 HEAD@{0}: commit (amend): [mahfuz110244/feat/poll-app] update models
044c2fd HEAD@{1}: commit (amend): [mahfuz110244/feat/poll-app] add only one file, forget to another
0a4b7d3 HEAD@{2}: commit (amend): [mahfuz110244/feat/poll-app] add only one file, forget to another
fa36d58 HEAD@{3}: commit (amend): [mahfuz110244/feat/poll-app] add only one file, forget to another
282ad96 HEAD@{4}: commit: (amend): [mahfuz110244/feat/poll-app] add only one file, forget to another
fd0d72b HEAD@{5}: commit (amend): [mahfuz110244/feat/poll-app] add only one file, forget to another
e2dac0a HEAD@{6}: commit: (amend): [mahfuz110244/feat/poll-app] add only one file, forget to another
4ce2732 HEAD@{7}: commit (amend): [mahfuz110244/feat/poll-app] give proper log message
01a644e HEAD@{8}: commit: [mahfuz110244/feat/poll-app] give wrong log message
e3a6a13 HEAD@{9}: commit (amend): [mahfuz110244/feat/poll-app] add enums in model
afa4e27 HEAD@{10}: commit: [mahfuz110244/feat/poll-app] forget to add one file and give wrong message
abcd935 HEAD@{11}: commit: [mahfuz110244/feat/poll-app] add Question and Choice models in Polls App
b125266 (origin/stage, origin/develop, stage, develop) HEAD@{12}: checkout: moving from stage to mahfuz110244/feat/poll-app
b125266 (origin/stage, origin/develop, stage, develop) HEAD@{13}: merge develop: Fast-forward
acc7800 (origin/master, master) HEAD@{14}: checkout: moving from develop to stage
b125266 (origin/stage, origin/develop, stage, develop) HEAD@{15}: merge mahfuz110244/feat/poll-app: Fast-forward
acc7800 (origin/master, master) HEAD@{16}: checkout: moving from mahfuz110244/feat/poll-app to develop
b125266 (origin/stage, origin/develop, stage, develop) HEAD@{17}: commit: [mahfuz110244/feat/poll-app] add poll app

Now if you want to rollback your last push

$ git reset --hard HEAD@{1}
$ git push -f

If you want to rollback HEAD No 6 e2dac0a this commit just replace the HEAD No

$ git reset --hard HEAD@{6}
$ git push -f

#Git 9

How to switch branch without commit in Git?

Sometimes we need to switch between branches because of we don’t want to commit this or we have no time because of some urgent work of different branch. We can do that using git stash command.

Stash

The git stash command takes your uncommitted changes (both staged and unstaged), saves them away for later use, and then reverts them from your working copy.

Git Stash Pop

You can reapply previously stashed changes with git stash pop. Popping your stash removes the changes from your stash and reapplies them to your working copy.

$ git stash
$ git checkout desire_branch
$ git checkout stash_branch
$ git stash pop
$ git stash list

Git Stash Apply

Alternatively, you can reapply the changes to your working copy and keep them in your stash with git stash apply

$ git stash
$ git checkout desire_branch
$ git checkout stash_branch
$ git stash apply
$ git stash list

Suppose you have stash multiple times. You need to go to specific stash. Suppose you have two stash and you want to pop stash no 1.

$ git stash
$ git stash list
$ git stash pop stash@{1}

#Git 10

How to delete a Git branch locally and remotely?

Sometimes we make mistake in branch creating like we need to create a new branch that copy from master branch but mistakely we have created branch from develop. So we need to delete that branch from locally. If we push this branch in remote then we also need to delete branch from remote.

# Delete from remote
$ git push -d <remote_name> <branch_name>
# Delete from local
$ git branch -d <branch_name>
# Note that in most cases the remote name is origin. In such a case you'll have to use the command like so.
$ git push -d origin <branch_name>
#To delete the local branch use one of the following:
$ git branch -d branch_name
$ git branch -D branch_name

The -d option is an alias for –delete, which only deletes the branch if it has already been fully merged in its upstream branch. You could also use -D, which is an alias for –delete –force, which deletes the branch “irrespective of its merged status.”

#Git 11

Git Rebase

According to the git documentation, the rebase command will reapply commits on top of another base tip. This definition might be a little daunting. It’s easier to explain rebase as a procedure that adds the changes of the current branch to the tail of another branch.

The primary reason for Git rebasing is to maintain a linear project history. In rebase, you change your branch that’s being rebased so it looks like it was branched off a new base instead of the original. The process rewrites the commits, so you’ll end up with different commit IDs.

The golden rule of git rebase is to never use it on public branches.

$ git checkout feature-branch
# Commit some task and then rebase master for latest codebase.
$ git rebase master

# Checkout master branch and merge feature branch
git checkout master
git merge feature-branch

Additional links:

• https://benmarshall.me/git-rebase/

#Git 12

Git Merge vs Rebase

• Merge takes all the changes in one branch and merges them into another branch in one commit.
• Rebase says I want the point at which I branched to move to a new starting point

So when do you use either one?

Merge Let’s say you have created a branch for the purpose of developing a single feature. When you want to bring those changes back to master, you probably want merge (you don’t care about maintaining all of the interim commits).

Rebase A second scenario would be if you started doing some development feature branch and then another developer made an unrelated change and merge that to base branch. Rebase is quite often a good idea to do before merging because you can resolve any conflict in your feature branch with base branch.

Git Rebasing Example In this example, we will first create a test case with master and feature branch. Then we will do a standard merge. Next, we will recreate the test case and perform rebase and merge.

Creating Master and Feature Branches

Here is the scenario we will create:

In the above example, we are taking the following path:

# Commit A: we add a.txt file in the ‘master’ branch
git checkout master
touch a.txt
git add -A
git commit -m "Commit A: added a.txt"

# Commit B: we add b.txt file in the ‘master’ branch
touch b.txt
git add -A
git commit -m "Commit B: added b.txt"

# Commit C: we add c.txt file in the ‘master’ branch
touch c.txt
git add -A
git commit -m "Commit C: added c.txt"
git status

# We go to the ‘feature’ branch
git checkout -b feature master 
# Commit E: we modify a.txt in ‘feature’ branch
echo aaa > a.txt
git add -A
git commit -m "Commit E: modified a.txt"

# Commit F: we modify b.txt in ‘feature’ branch
echo bbb > b.txt
git add -A
git commit -m "Commit F: modified b.txt"

Simple Merge

Let’s use the log command to check both branches.

# Results for ‘master’:
$ git checkout master
# Switched to branch 'master'
 
$ git log --oneline
2bbde47 Commit C: added c.txt
b430ab5 Commit B: added b.txt
6f30e95 Commit A: added a.txt
 
$ ls
a.txt    b.txt    c.txt

# Results for ‘feature’:
$ git checkout feature
# Switched to branch 'feature'
 
$ git log --oneline
0286690 Commit F: modified b.txt
7c5c85e Commit E: modified a.txt
b430ab5 Commit B: added b.txt
6f30e95 Commit A: added a.txt
 
$ ls
a.txt    b.txt

# Notice how the feature branch does not have Commit C

# Now let’s run merge ‘feature’ branch with ‘master’ branch. You will be asked to enter a comment. 
# In the comment, add “Commit G:” at the beginning to make it easier to track.

$ git checkout master
# Switched to branch 'master'
 
$ git merge feature
Merge made by the 'recursive' strategy.
a.txt | 1 +
b.txt | 1 +
2 files changed, 2 insertions(+)

# Results for ‘master’:
$ git checkout master
Already on 'master'
 
$ git log --oneline
 d086ff9 Commit G: Merge branch 'feature'
 0286690 Commit F: modified b.txt
 7c5c85e Commit E: modified a.txt
 2bbde47 Commit C: added c.txt
 b430ab5 Commit B: added b.txt
 6f30e95 Commit A: added a.txt
 
 $ ls
 a.txt b.txt c.txt
 
# Results for ‘feature’:
$ git checkout feature
# Switched to branch 'feature'
 
$ git log --oneline
0286690 Commit F: modified b.txt
7c5c85e Commit E: modified a.txt
b430ab5 Commit B: added b.txt
6f30e95 Commit A: added a.txt
 
$ ls
a.txt    b.txt

In the ‘master’ branch, you will notice there is a new commit G that has merged the changes from ‘feature’ branch. Basically, the following action has taken place:

In the Commit G, all the changes from feature branch have been brought into the master branch. But the feature branch itself has remained untouched due to the merge process. Notice the hash of each commit. After the merge, E (7c5c85e) and F (0286690) commit has the same hash on the feature and master branch.

Merging with Rebasing

Let’s repeat step 1 to create the master and feature branches again.

# Results for ‘master’:
$ git checkout master
# Switched to branch 'master'
 
$ git log --oneline
7f573d8 Commit C: added c.txt
795da3c Commit B: added b.txt
0f4ed5b Commit A: added a.txt
 
$ ls
a.txt    b.txt    c.txt

#Results for ‘feature’:
$ git checkout feature
# Switched to branch 'feature'
 
$ git log --oneline
8ed0c4e Commit F: modified b.txt
6e12b57 Commit E: modified a.txt
795da3c Commit B: added b.txt
0f4ed5b Commit A: added a.txt
 
$ ls
a.txt b.txt
# Let’s rebase from the ‘feature’ branch.

$ git checkout feature
# Switched to branch 'feature'
 
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: Commit E: modified a.txt
Applying: Commit F: modified b.txt
Then merge ‘feature’ into ‘master’.

$ git checkout master
# Switched to branch 'master'
 
$ git merge feature
Updating 7f573d8..9efa1a3
Fast-forward
 a.txt | 1 +
 b.txt | 1 +
 2 files changed, 2 insertions(+)
 
# Results for ‘master’ branch:
$ git log --oneline
9efa1a3 Commit F: modified b.txt
8710174 Commit E: modified a.txt
7f573d8 Commit C: added c.txt
795da3c Commit B: added b.txt
0f4ed5b Commit A: added a.txt
 
$ ls
a.txt    b.txt    c.txt

#Results for ‘feature’ branch:
$ git checkout feature
# Switched to branch 'feature'
 
$ git log --oneline
9efa1a3 Commit F: modified b.txt
8710174 Commit E: modified a.txt
7f573d8 Commit C: added c.txt
795da3c Commit B: added b.txt
0f4ed5b Commit A: added a.txt
 
$ ls
a.txt    b.txt    c.txt

Notice that after the rebase and merge both branches are the same. Also, the hashes for E and F have changed in both branches. Basically, in the rebase scenario, this is what happened:

That’s why there is no new commit. The E and F commits have been recalculated and latched to the end of the ‘master’ branch.

Rebasing is a useful tool when you want to clean up the history of your work. However, there is a danger which has given birth to the golden rule.

Additional links:

• https://linuxhint.com/git-rebase-tutorial/
• https://www.atlassian.com/git/tutorials/merging-vs-rebasing

#Git 13

Git Cherry Pick

Cherry picking in Git means to choose a commit from one branch and apply it onto another. When you are working with a team of developers on a medium to large sized project, managing the changes between a number of git branches can become a complex task. Sometimes you don’t want to merge a whole branch into another, and only need to pick one or two specific commits. This process is called cherry picking.

When should we use Cherry Picking?

Let’s say you are working in an project where you are making changes in a branch called new-features. You have already made a few commits but want to move just one of them into the master branch. From new-features branch run git log –oneline to get a better log of your commits history. Note that the commit id is what we need to start the cherry picking.

# Checkout the branch where you want to cherry pick the specific commits. In this case master branch:
$ git checkout master

# Now we can cherry pick from new-features branch:
$ git cherry-pick d467740
# This will cherry pick the commit with hash d467740 and add it as a new commit on the master branch. 
# Note: it will have a new (and different) commit ID in the master branch.

# If you want to cherry pick more than one commit in one go, you can add their commit IDs separated by a space:
$ git cherry-pick d467740 de906d4

# If the cherry picking gets halted because of conflicts, resolve them and
$ git cherry-pick --continue

# If you want to bail of this step out altogether, just type:
$ git cherry-pick --abort

# In case you needed to cherry pick a merge instead of a commit, you can use:
$ git cherry-pick -m 1 <commit-id>

Caution!

Cherry picking is commonly discouraged in developer community. The main reason is because it creates a duplicate commit with the same changes and you lose the ability to track the history of the original commit. If you can merge, then you should use that instead of cherry picking. Use it with caution!

Additional links:

• https://www.previousnext.com.au/blog/intro-cherry-picking-git
• https://www.atlassian.com/git/tutorials/cherry-pick

Note: If you have any query or any upgradation of my writing or any mistakes please comment and suggest me. You are warmly welcomed always.