From what I understood, when I run git clone, then start to add/edit files on my local repo, I have actually 2 repos : master and origin/master -where the later points to the remote- , I am getting this intuition from what git fetch does, It actually gets the latest version from remote repo to origin/master repo without merging it with local master, it is only when I call git merge that these remote changes are merged to local master

So first question: Am I understanding it correctly? I really have 2 repos on local

Second question: If this is the case, then why pushing a change to the remote server is a 2 step process (git commit then git push) , If I really have 2 local repos, I believe I will need to make 3 steps : commit to local master - merge to origin/master then push to remote/master ... how now this is only done via 2 steps, is there any implicit action that happens or am I getting something wrong?

CodePudding user response：

The thing that you call a repo is a branch in git terminology. A repo may contain a lot of branches. master and origin/master are two branches, the master represent your local files, while origin/master represents a state of master in remote repo origin. You can have a few remote repos and a few different branches same time. try to read the docs: https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches probably it give you more answers.

CodePudding user response：

The way git models things can be a bit confusing at first, so let's look at some key concepts for this scenario:

• a repository is a complete self-contained copy of history; you can pass information between repositories, but there is no "central source of truth" as far as git is concerned
• commits are the basic unit you deal with in git; a commit contains a snapshot of the entire repository, pointers to zero or more parent commits (one for a normal commit, two or more for a merge, zero at the very start of the history), and metadata about who committed it, when, etc
• branches in git are actually just names pointing to a single commit; from that commit, you can trace history backwards by looking at the parent pointers
• remotes are basically just information about where to get extra commits from
• remote-tracking branches are read-only branches used to record where those branch names point on a remote server

When you run git clone, you get the following:

• a brand new repository, entirely self-contained on your computer
• a remote called "origin", pointing at the server you cloned from
• some remote-tracking branches, recording where, at this point in time, the various branches on the remote server point
• a local copy of every commit in the remote server's history, across all branches
• a single local branch, which is checked out by default, pointing at the same place as the remote branch with the same name (normally "master" or "main")

You can then unplug your internet, and carry on working, creating as many commits and branches as you want in your local repository.

When you want to share those commits with other people, you use git push to send them to the remote server. This command has two main jobs: to send some commits to the remote server; and to tell the remote server to update a branch to point to one of those commits. Since it knows that the remote server has been updated, it can update your local read-only "remote-tracking branch" as well.

On the other hand, if you want to have copies of what other people have done on the remote server, you have to use git fetch or git pull. The purpose of git fetch is to ask the server where its branches point, update the local "remote-tracking branches" to match, and then fetch any new commits that you don't already have. git pull does the same thing, but also updates a local branch, either by moving the pointer directly (a "fast-forward merge") or by merging the two histories together.

So to answer more directly:

1. You do not have two repositories; master is a local branch, origin/master is a remote-tracking branch
2. You don't need to explicitly merge to origin/master, because its only purpose is to track where the branch points on the remote server