• About Tanya
  • Privacy Policy
  • Contact
  • Git Basics and Workflow

    Git basics and finally making a pull request

    Git Basics

    Central location where a version of a project is stored and managed
    Remote repository
    versions of a project hosted on a network somewhere such as the Internet. There can be several remotes for a particular project with read-only as well as read-write permissions given to a user. Projects are managed on these remotes, also pulled from and pushed to them during collaboration for their further development.
    Local repository
    versions of a project on a user’s local system, personal computer
    The repository where the original project exists. It is initiated with the master branch.
    The repository derived from the original, that is, the upstream repository. It is initiated with the master branch as well, and has all the other supplementary branches present in the upstream repository.


    The image below describes the workflow of the image. For further understanding, it is recommended to follow the guide step-by-step. You can practice on this blog’s repository with commands as illustrated below.

    Git Basics and Workflow

    Git Basics and Workflow

    Fork the main repository

    is used to copy the repository the owner organization’s profile to our personal or remote profile.

    Go to the repository of the own organization and press the Fork button.

    HTTP form

    Clone the main repository

    It generates a copy of the existing repository on the local system with its parent in the remote. It copies the .git directory, the most important of all.

    git clone [upstreamRepoURL] will clone, that is copy the GitHub repository from the upstream remote branch to the local system

    * The main repository must be forked even when cloned, to allow updating a version of the project as described below
    * You should ensure that you have entered the apt URL in the field [upstreamRepoURL]. The URL must be of the remote repository containing the main version of the project, the one it has originated from.

    $ git clone https://github.com/Tanya-Jain/The-Stellar-Adventurer.git

    This would create a directory in the local system for the repository named “The Stellar Adventurer” and initialize a .git directory inside it. All the data from the upstream would have been pulled inside it with a working copy of the latest version checked out.

    If you want to clone the repository into a directory named something other than “The Stellar Adventurer”, you can specify that as the next command-line option, git clone [upstreamRepoURL] [directoryName]

    $ git clone https://github.com/Tanya-Jain/The-Stellar-Adventurer.git blogIFollow

    That command does the same thing as the previous one, but the target directory is called blogIFollow.

    The directory of the GitHub project

    In your terminal window, enter into the directory of the repository you have forked. (Using cd)

    [email protected] ~$ cd blogIFollow

    Git Configuration for a recently forked repository

    Working with remotes

    Showing the remotes

    Use git remote -v to list the remote repositories with permission for fetching and pushing of changes along with the HTTP URL. -v refers to the option --verbose. Not using this option would only list the name of the remotes.

    [email protected] ~/blogIFollow [master]$ git remote -v
    origin    https://github.com/Tanya-Jain/The-Stellar-Adventurer.git (fetch)
    origin    https://github.com/Tanya-Jain/The-Stellar-Adventurer.git (push)

    Inspecting the remotes

    To get an extensive list on details regarding a specific remote, use git remote show [remoteRepositoryName]. This command displays the following details:
    * remote short-name
    * URL
    * Fetch URL
    * Push URL
    * HEAD Branch
    * Remote branches
    * Local branches configured for git pull
    * Local references configured for git push

    Configuring the remotes

    We are doing this to ensure our .git directory is correctly configured for further editing and managing of the files.

    Now, remove both the remote repositories using the command git remote remove [remoteRepositoryName]
    There, wouldn’t be any output if the branches are tried to be listed with git remote -v.

    Removing remotes
    [email protected] ~/blogIFollow [master]$ git remote remove origin

    Now, the forked repository needs to be added in the branch to both fetch as well as push the changes.

    Adding remotes

    git remote add [remoteRepositoryName] [url] or git remote add [remoteRepositoryName] [SSH]
    It is advisable to use SSH as it is beneficial to get the work done faster by not needing to enter the password multiple times. Though the first time it would be compulsory to enter the password.

    [email protected] ~/blogIFollow [master]$ git remote add origin https://github.com/newUser/The-Stellar-Adventurer.git
    [email protected] ~/blogIFollow [master]$ git remote add upstream https://github.com/Tanya-Jain/The-Stellar-Adventurer.git

    The remote repository has been given the name origin and will be used to push the changes from the local system to the newUser‘s remote repository. The original remote repository has been named to upstream and will be used to fetch the changes from the main repository, that is, Tanya-Jain‘s remote repository.

    The following configuration is achieved:

    [email protected] ~/blogIFollow [master]$ git remote -v
    origin    https://github.com/newUser/The-Stellar-Adventurer.git (fetch)
    origin    https://github.com/newUser/The-Stellar-Adventurer.git (push)
    upstream    https://github.com/Tanya-Jain/The-Stellar-Adventurer.git (fetch)
    upstream    https://github.com/Tanya-Jain/The-Stellar-Adventurer.git (push)

    Working with branches

    Branches can be thought of like that of a tree. Different users work on different branches which emerge originally from the main repository, the bark of the tree.

    It is advised to implement your code on different branches. Preferably, a unique branch should solve a unique issue. This branch shall be removed once the code has been merged into the main repository.

    Working on the main branch can lead to several conflicts as the usage of code increases. It increases the risk in the manipulation of the code in the main repository, especially if you are among the managers of the repository as well.

    Displaying branches

    The branch used in the .git directory by the newUser‘s remote can be listed out via git branch

    [email protected] ~/blogIFollow [master]$ git branch
    * master

    Create a new branch to work on

    To create a new branch git branch [newBranchName]

    [email protected] ~/blogIFollow [master]$ git branch develop-data
    [email protected] ~/blogIFollow [master]$ git branch
    * master
    [email protected] ~/blogIFollow [master]$ git status
    On branch master
    nothing to commit, working directory clean

    To push the made branch as commit

    [email protected] ~/blogIFollow [master]$ git push origin develop-data
    Username for 'https://github.com': Tanya-Jain
    Password for 'https://[email protected]':
    Total 0 (delta 0), reused 0 (delta 0)
    To https://github.com/Tanya-Jain/The-Stellar-Adventurer.git
    * [new branch] develop-data -> develop-data

    git push -u [remoteRepositoryName] [newBranchName] will push the newly made branch from local to the upstream remote. Hence, the main repository will have this new branch as well.

    3 Stages of updating versions of a project

    You have successfully set up your local repository with a branch ‘develop-data’. Go on and edit your files which shall go through 3 main stages:

    1. The Working tree/directory

    Modified files

    Files are initially saved here after editing, known as modified files. These files have been originally been obtained after a pull from the main remote and saved into the local repository for further editing.

    The Working directory contains a version being modified of a particular branch activated. One can switch among branches via git checkout [branchName].

    [email protected] ~/blogIFollow [master]$ git checkout develop-data
    [email protected] ~/blogIFollow [develop-data]$

    2. The Staging area or the Local Index

    Staged files

    The modified files in the local need to be staged in this area for further addition the remote. Use git add /path/to/file to add files and git rm /path/to/file to remove files from the staging area.

    The files store data of what changes will be present in the next commit. They are added to the staging area in form of snapshots. The different version in the project are indeed saved as different versions of snapshots per file in GitHub version control.

    Storing data as snapshots of the project over time.(Source:git-scm)

    Storing data as snapshots of the project over time. (Source:git-scm)

    [email protected] ~/blogIFollow [develop-data]$ git status
    On branch develop
    Changes not staged for commit:
    (use "git add <file>..." to update what will be committed)
    (use "git checkout -- <file>..." to discard changes in working directory)
    modified: assets/css/main.css
    Untracked files:
    (use "git add <file>..." to include in what will be committed)
    h -u
    no changes added to commit (use "git add" and/or "git commit -a")
    [email protected] ~/blogIFollow [develop-data]$ git add assets/css/main.css index.html

    git status helps to check the status of the staging area.

    Untracked Files
    Files that are recently created but never committed, or files that are not being tracked at all for addition to thee .git directory.

    3. The Git directory

    Commit files

    This directory contains the metadata and object database for a project. It is the one copied to local system on cloning a remote. On commit, the snapshot of the version staged for commit is permanently stored in the .git directory.

    [email protected] ~/blogIFollow [develop-data]$ git commit

    This would open the default text-editor. The first line entered will be the title of the commit message. Leave a line and type the description for the commit explaining the changes implemented in this new version of the project. This is the suggested format for a commit message.

    Always explain your code in as much required detail as possible. It should not leave anyone in any assumption.

    For a fast-track process, one may use git commit -m "Title of Commit Message" to quickly commit the staged snapshot and avoid typing the description of the commit.

    Difference in snapshots

    To check the difference in snapshots from two different versions of the project, the one on upstream remote and the other on the local, use git diff

    [email protected] ~/blogIFollow [develop-data]$ git diff

    Pull = Fetch + Merge

    Fetching data

    git fetch [remoteRepositoryToFetchFrom] is used to fetch data from the remote repository to the local repository.

    Merging data

    git merge is used to merge data of the local repository with the working directory.


    git pull [remoteRepositoryToPullFrom] [branchToPullFrom] performs two functions at once, that is, it first performs a fetch to the local repository and then immediately tries to merge the changes in the local repository to the working directory, as much as possible.

    [email protected]:~/blogIFollow [develop-data]$ git pull upstream master

    At times, you would encounter an error stating fail to pull. This is because of conflicts in the two versions of your file which must be resolved manually before merge can take place.

    It would be of the form:
    statements in the working directory version —— statements in the fetched version —-

    The lines generated to enclose the above-mentioned statements should be removed completely before the successful merge of files. Also, the two statements should be manually merged so as not to allow any compromise in your code.


    To finally push the snapshot of the new version of the project from the local to the remote, use git push [upstreamRepository] [branchWorkingOn]

    [email protected]:~/blogIFollow [develop-data]$ git push origin develop-data

    Pull Request

    Go the URL of the remote on the Internet and review your commits. Once satisfied, make a pull request by clicking a green colored button on top-right.

    Leave a Reply

    %d bloggers like this: