Syncing

Tracking branch

The branch that appears in the local repository tracking a branch in the remote repository. (normally it's called origin/master branch, but you can change the name)

Clone VS Fork

Forking is an action that's done on a hosting service, like GitHub. Forking a repository creates an identical copy of the original repository and moves this copy to your account. You have total control over this forked repository. Modifying your forked repository does not alter the original repository in any way.

Do you require a copy of a project, and do not need to sync your copy with the original project? If so, a clone is more suitable because it does not share a connection with the original repository.

Is Cloning a part of Forking?

To understand this, let us go back to the era before 2008 i.e. the pre-git era (if that term even exists). The open-source community is in full demand and people are experimenting and inventing technologies and software, no one has imagined. These open-source communities are experimenting with their own features and modifications and as a matter of fact, almost all of them have a feature called fork.

Fork in the pre-git era was cloning the software or anything that the user wants a personal copy of. If I fork a document, let say this article, I will have the same document on my account i.e. I will have a copy of this document. I can now use it, edit it modify it and if I want, I can send it back to the owner with some modification.

Then came GitHub. GitHub, like every other open-source, had a concept of the fork. Now, focus on the word concept that I have used to describe fork in GitHub. Forking in GitHub would create the same effect as other open-source platforms but the user was not able to edit the code. For this, they explicitly defined a command called git clone to clone the repository to work on it.

So, forking is a concept while cloning is a command in Git. Forking just acts as a middleman between the user and the upstream repository. Therefore, if you visit any other open-source community, you would find forking and cloning as the same concept, and people using that in an interchangeable way in the community.

Fetch VS Pull

TL;DR

• git fetch is a primary command used to download contents from a remote repository.
• git pull is the same thing as a git fetch + git merge

One main point when you want to use git fetch rather than git pull is *if your remote branch and your local branch both have changes that neither of the other ones has *.

In this case, you want to fetch the remote changes to get them under refs/remotes/<remote>/ and then perform a merge manually. Then you can push that new merge commit back to the remote.

This operation is safe to run at any time since it never changes any of your local branches under refs/heads.

Origin vs Upstream Clarification

• When Clone: Git created a connection for us automatically and gave this connection a short name of origin when we clone a project. We can manually set up a connection to the original or source remote repository, though. Typically, we'd name the short name upstream.
• When Fork: What might be confusing is that origin does not refer to the source repository (also known as the "original" repository) that we forked from. Instead, it's pointing to our forked repository. So even though it has the word origin is not actually the original repository.
• You can actually change the name of origin to mine and the name of upstream to source-repo. -Github suggest fork a repo on GitHub before cloning that fork locally

When a repo is cloned, it has a default remote called origin that points to your fork on GitHub, not the original repo it was forked from. To keep track of the original repo, you need to add another remote named upstream. git remote add upstream git://github.com/<original creator>/<original creator repo.>

What is a remote in Git?

A remote in Git is a common repository that all team members use to exchange their changes. In most cases, such a remote repository is stored on a code hosting service like GitHub or on an internal server.

In contrast to a local repository, a remote typically does not provide a file tree of the project's current state. Instead, it only consists of the .git versioning data.

Remote init

# Show remote details:
git remote -v

# Clone to localhost:
git clone https://github.com/user/project.git
# OR
git clone ssh://user@domain.com/~/dir/.git

# Clone to localhost folder:
git clone https://github.com/user/project.git ~/dir/folder

# Clone specific branch to localhost:
git clone -b branchname https://github.com/user/project.git

# Clone with token authentication (in CI environment):
git clone https://oauth2:<token>@gitlab.com/username/repo.git

Remote setup

# Add remote upstream from GitHub project:
git remote add upstream https://github.com/user/project.git

# Add remote upstream from existing empty project on server:
git remote add upstream ssh://root@123.123.123.123/path/to/repository/.git

# Fetch a custom branch:
git fetch upstream branchname:local_branchname

# Merge fetched commits:
git merge upstream/master

# Remove origin:
git remote rm origin

# Show remote branches:
git branch -r

# Show all branches (remote and local):
git branch -a

# Create and checkout branch from a remote branch:
git checkout -b local_branchname upstream/remote_branchname

# Compare:
git diff origin/master..master

Remote operation

# Push (set default with `-u`):
git push -u origin master

# Push:
git push origin master

# Force-Push:
git push origin master --force

# Delete remote branch (push nothing):
git push origin :branchname or:
git push origin --delete branchname

# Pull specific branch:
git pull origin branchname

# Fetch a pull request on GitHub by its ID and create a new branch:
git fetch upstream pull/ID/head:new-pr-branch

References

What is the difference between origin and upstream on GitHub?