masterbranch 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.
Go to the repository of the own organization and press the
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
In your terminal window, enter into the directory of the repository you have forked. (Using
[email protected] ~$ cd blogIFollow
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)
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
* Fetch URL
* Push URL
* HEAD Branch
* Remote branches
* Local branches configured for
* Local references configured for
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.
[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.
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)
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. Preferrably, a unique branch should bsolve 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 manipulation of the code in the main repository, specially if you are among the managers of the repository as well.
The branch used in the .git directory by the
newUser‘s remote can be listed out via
[email protected] ~/blogIFollow [master]$ git branch * master
To create a new branch
git branch [newBranchName]
[email protected] ~/blogIFollow [master]$ git branch develop-data [email protected] ~/blogIFollow [master]$ git branch develop-data * master [email protected] ~/blogIFollow [master]$ git status On branch master nothing to commit, working directory clean
[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.
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:
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]$
The modified files in the local need to be staged in this area for further addition the 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.
[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.
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.
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
[email protected] ~/blogIFollow [develop-data]$ git diff
git fetch [remoteRepositoryToFetchFrom] is used to fetch data from the remote repository to the local repository.
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 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 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
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.