Git fully parsed remote repository interaction

Article Directory

1. 1. git fully resolved remote repository interaction
   1. 1.1. The concept of a central warehouse
   2. 1.2. local branch and remote branch
   3. 1.3. Pull and Fetch
   4. 1.4. about Donations

The concept of git-fully-resolved remote repository Interaction Central Warehouse

Although Git is a distributed version control tool, it also has the concept of remote repositories. For various purposes, we sometimes need to have a shared remote repository, such as a warehouse on GitHub, a warehouse for testing and deployment in our company project, and so on.
The general procedure is to first create a warehouse on the public server, and then each developer clones the repository for their own development, and then push to the remote repository for test deployment after the development is complete.

Clone project from remote repository:

1 2 3 4 5 6 7

[Email protected] gitwork]$ [[email protected] gitwork]$ git clone [email protected]:wustrive2008/gittest.git Initialized empty Git repository in/home/centos/gitwork/gittest/.git/ Remote:counting objects: 4, done. Remote:compressing objects: 100% (3/3), done. Remote:total 4 (Delta 0), reused 0 (Delta 0), pack-reused 0 Receiving objects: 100% (4/4), 4.15 KiB, done.

The remote repository for the above example is on GitHub, and of course if we're doing a company project, it's very rare for security and access efficiency to put the company's private projects on GitHub. The general practice is to build your own git server, where two kinds of GIT server tools are recommended:

1. Gitolite
2. GitLab

Both tools have a lot of tutorials on the web.

Description: GitHub also has a paid Enterprise edition that has been tried and is also very useful

Local branch and Remote branch

Usually we use GIT branch to see local branches, such as:

1 2	[[email protected] gittest]$ git branch * Master

However, when you need to synchronize your code with a central repository often, especially if you have many branches, you need to look at the references to the remote branches that are currently available locally, rather than switching between different branches. A good practice for git branching can be found in: git flow
To view a reference to a remote branch

1 2 3 4 5

-A * Master Remotes/origin/head-Origin/master Remotes/origin/master

The above results indicate:
There is currently a master branch locally, and there is a reference to the Remotes/origin/master (remote master) branch, as to the Remotes/origin/head branch, which can be understood as a reference to the Origin/master branch.
Where origin is a remote repository reference alias, this name can be modified, or can have multiple, you can refer to the GIT remote command to learn more

Next, create a develop branch locally for the normal development process:

1 2 3 4 5 6 7 8 9 10

[[email protected] gittest]$ git checkout-b Develop ' Develop ' [[email protected] gittest]$ git BR * Develop Master -A * Develop Master Remotes/origin/head-Origin/master Remotes/origin/master

Develop on the develop branch and submit:

1 2 3 4 5 6

[email protected] gittest]$ Touch file1.txt [[email protected] gittest]$ git Add. "Create File File1.txt" 21053D7] Create file File1.txt 0 Deletions (-) 100644 file1.txt

Push the develop branch to the server after development is complete:

1 2 3 4 5 6 7

4, done. 100% (2/2), done. 100% (3/311 bytes, done. 0) to [email protected]:wustrive2008/gittest.git 8a9a114. 21053d7 Develop-develop

The next normal process is for the tester to pull to the remote develop branch, then test the content submitted on the develop branch, merge it into the master branch after the test passes, and finally push it to the deployment server for on-line deployment.

1 2 3 4 5 6 7 8 9 10 11

[[email protected] gittest]$ git checkout Master Switched to Branch ' master ' [[email protected] gittest]$ git merge develop updating 8a9a114. 21053d7 fast-forward 0 Files changed, 0 insertions (+), 0 deletions (-) Create mode 100644 file1.txt [[email protected] gittest]$ git push Origin Master total 0 (Delta 0), reused 0 (Delta 0) to [email protected]:wustrive2008/gittest.git 8a9a114. 21053d7 Master, Master

Pull and Fetch

Pull and FETCH commands are required if you are pulling the code for the remote repository
The difference between these two commands is pull=fetch+merge.

To demonstrate git pull first, other developers have already submitted new content on the develop branch and now need to sync to local

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

[[email protected] gittest]$ git BR * Develop Master [[email protected] gittest]$ gitLog Commit21053d768d7af0c5cf90f63dc105891726094b43 Author:wubaoguo <[email protected]126.com> Date:mon Jan1122:35:502016 +0800 Create File File1.txt Commit8a9a114ecbacfd5555ee417ab1dbe02a20db9a03 Author:wubaoguo <[email protected]> Date:mon Jan1122:08:392016 +0800 Initial Commit [[email protected] gittest]$ Git pull origin Develop Remote:counting objects:2, done. Remote:compressing objects:100% (2/2), done. Remote:total2 (Delta1), reused1 (Delta0), pack-reused0 Unpacking objects:100% (2/2), done. From Github.com:wustrive2008/gittest * Branch Develop-fetch_head Updating21053d7.2296978 Fast-forward 0 files changed,0 insertions (+),0 Deletions (-) Create mode100644 File2.txt [[email protected] gittest]$ gitLog Commit22969782f467cd04410c9ed3cf5c80e3987d212b Author:wubaoguo <[email protected]126.com> Date:mon Jan1122:52:182016 +0800 Create File File2.txt Commit21053d768d7af0c5cf90f63dc105891726094b43 Author:wubaoguo <[email protected]126.com> Date:mon Jan : +0800 Create File File1.txt Commit 8A9A114ECBACFD5555EE417AB1DBE02A20DB9A03 Author:wubaoguo <[email protected]> Date:mon Jan : 0800 Initial Commit

It is clear that the new code has been pulled and merged locally, and can be developed based on the latest code.

If developer B says he pushed a new branch fixbug to the remote repository, you need to continue to modify the bug on this basis, and you can do this.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

[[email protected] gittest]$ git BR-A#可以看到这时本地并没有新的分支与引用 * Develop Master Remotes/origin/head-Origin/master Remotes/origin/develop Remotes/origin/master [[email protected] gittest]$ git fetch#拉取远程所有的变动 Remote:counting objects:3, done. Remote:compressing objects:100% (1/1), done. Remote:total3 (Delta1), reused3 (Delta1), pack-reused0 Unpacking objects:100% (3/3), done. From Github.com:wustrive2008/gittest 21053d7. 2296978 Develop-origin/develop * [New branch] Fixbug-Origin/fixbug #注意这里拉取到一个新分支 [[email protected] gittest]$ git br #这时本地并没有fixbug分支 * Develop Master [[email protected] gittest]$ git checkout fixbug #创建并切换到fixbug分支, referencing Origin/fixbug branch Branch Fixbug set up to track remote Branch Fixbug from Origin. Switched to a new branch ' Fixbug '

Interoperability with remote warehouses basically, there's one thing to note, it's best to pull it off before pushing, because if the remote branch version is newer than the local, the direct push will fail.

Git fully parsed remote repository interaction