Git & GitHub (Part-II)

Git & GitHub (Part-II)

List of Concepts Involved:

  • Git commands

  • Git branches

  • Git merging

Git Commands

[1] -: git version

  • This command is used to check the version of the git.
kenil@kenils-MacBook-Pro ~ % git --version
git version 2.39.2
  • If you haven't installed git, you'll see an error message like,
-bash: git: command not found

[2] -: git help

  • If we want to see the list of commands then we can use the git help command,
git help

[3] -: git config

  • It is used, when git Software is used first time on your system.

  • The command will set the developer identity like name, email, etc...

  • This configuration Information will be used by git software for every push operation encountered.

  • This command is used to provide a list of configurations,

  •       git config --list
  • To set the username and email,

  •       git config --global "your-name"
  •       git config --global "your-email"

    This command is only required the first time you install the git software.

  • global - It indicates the user can work with git commands from different drives of the computer.

  • Note - To display the location of the git configuration held by the git software,

  •       git config --list --show-origin

[4] -: git init

git init
  • Normally a folder will be created in the developer's workplace and inside the folder, the source code will be placed.

  • Normally this is the first command which we execute to set up the git for operations like clone, push, pull, etc...

  • This command internally creates one folder called .git

  • If .git folder is not visible to you after the git init command, then you can see by, pressing command + shift + .(dot) on mac or Windows + shift + .(dot) on Windows.

  • .git folder is used by git software to identify the folder which should participate in pushing to "local" and "remote" repositories.

[5] -: git status

git status
  • This command is used to check the status of the working directory.

  • Note - git status normally will give output in the following ways,

    a.untracked files(red colour) => This means that files are present still in the working area and these files can't be committed to the "local repository" nor to the "remote repository".

    b.tracked files(green colour) => It means the files are moved from the working area to the stage area, so these files can be committed to the "local repository" or to the "remote repository".

    c.modified files(red colour) => It means the files are still present in the working area and these files can be staged or it can be also restored back to the normal phase.

[6] -: git add

  • To send the code from the workspace to stage area we have to use the following command,

      git add <file_name>
  • If we want to push all the files from the workspace to the stage area, we use the following command,

      git add .
      git add --a

[7] -: git rm

  • It is also possible to un stage the file from the stage area to the workspace by using the following command,

      git rm --cached <file_name>

[8] -: git restore

  • To restore the old file we use the following command,

      git restore <file_name>

[9] -: git commit

  • The files which are ready for commit should be in the stage area, to perform the commit operation we use the following command,

      git commit -m "some message" <file_name>
  • If you don't specify the file name, then it will commit all the files present in the local repository.

[10] -: git pull

  • It is used to fetch the latest changes made in the remote repository to the working directory.

      git pull

[11] -: git clone

  • It is used to clone the repository to the working directory of the developer.

      git clone <url_of_repository>

[12] -: git clone

  • It is used to push code from local repository to the remote repository.

      git push -u origin main

[13] -: git show

  • This command is used to show the metadata and content changes of the specific commit.

      git show <commit_id>
  • Let's pause our discussion about the "command" and focus on understanding branches in Git. This will help us better understand the next set of commands.


  • Git by default provides us with an independent line of development known as a branch.

  • Usually, the default branch is the master branch.

  • To understand the branch, Assume three developers working on the same project. Suppose developer-2 wants to add some feature to the project. Developer-2 injects the feature directly onto the master branch. What if the feature is not working properly? Git provides the concept of branches to deal with this type of problem.

  • Developer-2 has to create an independent line of development to add some features to the project.

  • This independent line of development is called branches.

  • Some Commands,

    [i] -: git branch

    • To see the total branches present currently.

    • The highlighted text shows the current branch.

    git branch

[ii] -: git branch <branch_name>

  • To create the new branch this command is used.

      git branch <branch_name>

[iii] -: git checkout <branch_name>

  • To switch from one branch to another this command is used.

      git checkout <branch_name>

[iv] -: git merge <branch_name>

  • Suppose you have two branches called kenil and main. main is your project's primary branch and kenil is your project's local branch you created.

  • If you want to the merge kenil branch with the main branch then you have to first switch from kenil to main.

  • After you reach the main branch use the following command,

      git merge kenil

[14] -: git log

  • This command is used to list the version history for the current branch.

      git log --follow <file_name>

[15] -: git fetch

  • It is used to get only updated branch details from the remote repository into the local repository.