Git Step by step– (6) Git remote repository

All of the GIT operations that appear in the previous article are based on the local repository, but working on a daily basis requires more than one person to work with in your own code warehouse. So, here we begin to introduce git remote repositories.

In a git system, users can push/get updates from other developers via the Push/pull command, which is less efficient for a workgroup. Therefore, in a git system, there will be a central server, everyone through the central server to push/get updates.

To facilitate this example, I use multiple directories to simulate multiple users and hub servers so that you don't have to build a git server.

• Hub Server: C:\VM\CentralRepo
• User Wilber:c:\vm\wilberworkspace
• User Will:c:\vm\willworkspace

git remote repository command to set up a central server

We know from the previous article that we can build a git repository through "git init", where we use "Git init--bare" to build a central repository, and note the "--bare" parameter, which is described later.

Here, an empty central server is built.

Clone a warehouse

In Git, there are two ways to build a git repository: one is to build a new repository through Git init, and the other is to clone an existing Git repository via the git clone command.

Since the hub server, user will can copy a git repository via the clone command.

As you can see from the clone action above, you need to give the address of the destination repository in the Clone command, and Git supports HTTP, ssh, and git native protocols for cloning. Here we use the local directory for demonstration purposes.

At this point, user will clones an empty repository from the central server and will then be able to work in this local repository.

Updated Push and pull

will now add a "calc.py" file to the local repository and submit it to the local repository.

In order for other users to get this update, will needs to push this update to the hub server.

Now the user Wilber through clone to obtain the warehouse copy on the central server, and the "Git log" will update has been automatically clone.

Now that Wilber has submitted a new update, will can get this update from the central server via pull.

--bare

Now let's take a look at the "--bare" option used when setting up a central server.

The GIT init--bare method creates a bare repository, which is called a bare repository because it stores only the version information submitted by Git history and does not allow the user to perform various git operations on it.

There is a bare repository because the repository initialized with GIT init allows users to perform all of the GIT operations in that directory. However, other users will be prone to conflict when updating push comes up. In this case, it is best to use the "--bare" option to create a bare repository.

Upstream warehouse (upstream repository)

In a git system, "origin" is usually used to indicate a warehouse. We can see all the branches in the upstream repository through the "Git branch-r" command, then use the name of Origin/name-of-upstream-branch to fetch the contents of the Remote tracking branch.

As can be seen from the above, for Wilber warehouses, the upstream branch of the master branch is the master branch of the hub server.

Through the content of the previous article, we can build two new "release-1.0" and "release-1.1" branches on the central server, and through the pull command, the user Wilber see these upstream branches.

--set-upstream-to

When we are of course to follow the previous article in the local warehouse to establish a branch, our pull operation will encounter the following problems, we are prompted that this branch does not have any trace information. Think about it too, we should associate the branch in the local repository with the upstream branch. At this point, we can use the "--set-upstream-to" command to correlate with git prompts.

Of course, in GIT we can create affiliate branches directly from "Git checkout-b localbranchname origin/remotebranchname". It is generally recommended that the name "Localbranchname" be set to the same name as "Remotebranchname".

Patch of the Ox fork

Patch is definitely a useful thing in git. Assuming that Wilber and will continue to work in a network-free environment, Wilber has an update and will needs to work on the next step based on this update. In the case of a centralized code-versioning tool, there is no way to work, but in git we can copy the Wilber update to Will by patch.

There are two ways to patch in Git: one is to generate a standard patch from Git diff, and the other is to generate a git-specific patch from Git format-patch.

A patch based on "Git diff"

Suppose you now Wilber update the "calc.py" file and generate a patch from "Git diff".

Below, we copy the Wilberpatch file to Will's working directory, and then apply the patch via "git apply" to get the Wilber update.

A patch based on "Git Format-patch"

Also using the example above, this time we use "git format-patch" to generate patches.

Note the parameter "Origin/master" of the "Git Format-patch" command, which means to find out the difference between the current master and Origin/master and then generate a patch.

To copy the patch file to Will's working directory, we apply the patch through the "Git AM" command.

Comparison of two patch types

Here's a quick look at the comparison of the two patch methods.

• Patch Compatibility: "Git diff" generates a strong patch compatibility. That is, if someone else's code repository is not git, you must use a git diff-generated patch to be accepted by another version control system.
• Patch Merge Tip: for "git diff" patches, you can use Git apply--check to see if patches can be applied cleanly and smoothly to the current branch, and if "git format-patch" generates patches that don't hit the current branch, Git am will give you hints to help you resolve conflicts, both of which have better hints.
• Patch Information Management: There is a lot of information in patches generated through "git Format-patch", such as the name of the developer, so it is reasonable to use this name in the repository when applying patches.

Summarize

Through this article, we learned about the commands and operations of the remote repository. In fact, this is the most common way of working in git, everyone through the central server to exchange and new.

At the same time, we have seen git patch tools, patch is a very common way to exchange updates.

Git Step by step– (6) Git remote repository