编程知识 cdmana.com

Git (6) -- remote command

The commands mentioned in the previous article are all used to operate the local warehouse , I believe we can handle most of the development situation , Submitting code to a local repository is no longer a problem , So this time, let's take a look at how to connect with the remote warehouse .

git clone --- Clone remote code to local

When we're developing , This is how the development process is : First, the remote warehouse will be ( The central warehouse ) Code for clone To local , Develop locally , After development, submit the code to the remote repository .

Remote warehouse is not complicated , In fact, they're just copies of your warehouse on another computer , We can communicate with this computer through the network -- That is, adding or obtaining submission records . Let's first order the remote warehouse clone To local

git clone https://github.com/generalthink/git_learn.git

After executing the command git The warehouse is from the far end clone It's local , At this point, the local and remote codes are the same . What changes have taken place in our local area after this order has been carried out ?
Let's see which branches we have now

$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

When we execute git clone When , Git A remote branch is created in the local warehouse for each branch in the remote warehouse ( such as origin/master). And then again Create a local branch that tracks the active branch in the remote warehouse , By default, this local branch will be named master.

You may have noticed that we are in addition to the local master Branch , There's more origin/master The branch of , This type of branch is called a remote branch , It reflects the state of the remote warehouse when you last communicated with it . Remember index The article ?index The working directory is recorded in the file , Temporary storage area , The local version is used to track the status of the repository , So who will maintain the status of the remote warehouse ? That's right origin/master Branch .

Note that remote branches have a special property , When we check out , Automatic entry separation HEAD state ( Submission in this state does not affect origin/master Branch ).git This is because you cannot operate directly on these branches , You have to finish your work elsewhere .
 Separate HEAD

The command specification for remote branches is like this :<remote name>/<branch name>, When we use git clone When a warehouse is ,git We have set the name of the remote warehouse to origin 了 .

You can use the following command to see the corresponding short name of the remote library

$ git remote -v
origin  https://github.com/generalthink/git_learn.git (fetch)
origin  https://github.com/generalthink/git_learn.git (push)

We synchronized the remote warehouse to the local , Remote and local code is consistent ( The latest commit record that both branches in the local repository point to ).

Branch tracking

When we will be local master Branch code push To remote master Branch ( The remote branch is also updated origin/master) When , We just need to execute git push That's all right. , It's like git Knowing that we're connected !

Actually master and origin/master The relationship between the two is a branch of "remote tracking" attribute-determined ,master Is set to track origin/master -- Express master It specifies the destination of push and the target of merge after pull .

You can make any branch trace origin/master, Then the branch will look like master Branches get implied as well push Destination and merge The goal of . This means that you can branch bugFix On the implementation git push, Push work to remote warehouse master On the branch . We can create one in two ways bugFix The branch of , It tracks remote branches origin/master

  • git checkout

    git checkout -b bugFix origin/master
  • git branch

    Need assurance bugFix The branch already exists

    git branch -u origin/master bugFix
    
     If it's right now bugFix On the branch , Commands can be optimized to 
    
    git branch -u origin/master

such bugFix Will track origin/master 了 , When we push code to the far end, we don't have to specify a destination , Direct execution git push It can be bugFix Branch code is pushed to the far end master The branch .

adopt git branch -vv The command can view the corresponding relationship of the remote branch associated with the local branch

$ git branch -vv
* bugFix     215d0ff [origin/master] add bugFix.md
  foo        e2240d6 [origin/master: behind 2] add foo.md
  master     7b7adf6 [origin/master: behind 5] Revert "bugFix"
  newFeature 3136c72 [origin/master: behind 3] add test2.md

When you set the trace relationship through the above command, execute git pull You may have this kind of misinformation when you are in trouble :

fatal: The upstream branch of your current branch does not match
the name of your current branch.  To push to the upstream branch
on the remote, use
    git push origin HEAD:master
To push to the branch of the same name on the remote, use
    git push origin newFeature
To choose either option permanently, see push.default in 'git help config'.

It's all because of git config push.default Set up , The default is simple( from git 2.0 Start ), This means that when the local branch and the remote branch have different names git Will refuse to submit . To allow it to push To the branch it tracks , This parameter needs to be reset

git config --global push.default upstream

--global Just change the current git Warehouse configuration . About push.default What values can pass through git help config Command view .

After setting up , In execution git push Command can directly bugFix The content of the branch is submitted to master Branch up .

$ git push
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 327 bytes | 327.00 KiB/s, done.
Total 2 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To https://github.com/generalthink/git_learn.git
   e2240d6..215d0ff  bugFix -> master

Development process

Above our warehouse has been consistent with the remote end , We can develop , Now we're going to modify a bug, The way is to build a new one locally bugFix( Naming conventions vary from company to company , General coordination bts Tools ) Branch ,
And then modify it on this branch , After the modification is completed, submit the changes to the online server , Then online jekins Will automatically run some scripts , Verify the code you submitted , Or detect conflicts , There is a conflict that requires consolidation . When everything is OK, we can merge master Went to the , Of course, our own development is not so complicated , So we're going to go directly to bugFix Branch code is pushed to the far end master Branch is OK

Submit code to remote warehouse

git push The command is responsible for uploading our changes to the designated remote repository , Now push our code directly to the remote branch

$ git push origin bugFix:master
To https://github.com/generalthink/git_learn.git
! [rejected]        bugFix -> master (fetch first)
error: failed to push some refs to 'https://github.com/generalthink/git_learn.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Execute the command and find the error , Why is this so ? It's because you're developing , Your colleagues are also developing , And the code he developed has been merged into the trunk , At this time, your local code is not up to date , At this point, if you go far away push Code , that git It will give you this error prompt .

here , This is the case with remote and local branches .
 Remote versus local branches

You can see the far end master Node and local origin/master It doesn't point to the same commit object, And we did git push Commands obviously don't intelligently help us merge . At this point, we should first synchronize the remote changes to the local , Merge these changes , And then in push To the trunk .

git fetch -- Sync code to local

The following command is used to communicate with the remote end , Synchronize the remote code to the local first

git fetch origin master

get fetch

git fetch Completed the only but particularly important two steps

**1.  Download the missing submission records from the remote warehouse **
**2.  Update remote branch pointer ( Such as  origin/master)**

Now the remote branch of the local warehouse is updated with the latest status of the corresponding branch of the remote warehouse . It's usually through the Internet (http:// perhaps git:// agreement ) Communicate with remote warehouse .
It should be noted that git fetch Does not change the state of your local warehouse . It won't update you master Branch , And it won't change the files on your disk .

Merge code

Now we've got remote data , Just update these changes to our working directory , We just need to merge remote branches like merging local branches * * , We can do this in three ways

1. git cherry-pick origin/master
2. git rebase origin/master
3. git merge origin/master

actually , Because it is very common to grab updates first and then merge them into local branches , therefore Git A special command is provided to complete these two operations . It's our git pull.

git pull ===== git fetch;  git merge origin/master

git pull --rebase == git fetch;git rebase origin/master

Now the code of local remote branch and remote warehouse is consistent , We can finally use the server git push origin bugFix:master We have submitted our code .

It's good to watch , Now we can use it happily git work , But it's important to remember git push Before that, make sure that the local remote pointer must be consistent with the remote pointer , Or you'll have to wait for the error to be reported .

Remote command syntax

As we can see above, the commands that interact with the remote warehouse are mainly git fetch/pull/push These three , The only thing people often use is get pull,git push In this way , Maybe for the first time git push orgin bugFix:master Such orders are amazing , So here is a brief introduction to the syntax of these commands , If you have learned about it, you don't have to read the following article .

git push grammar

git push <remote> <localPlace:remotePlace>

Example :

git push origin master:master

Indicates switching to local master Branch , Get all submissions , Then to the remote warehouse "origin" Find "master" Branch ( If not, a new one will be created ), Add the submission records that are not in the remote repository .
adopt "localPlace" Parameters to tell git The submission record is from master, Push to remote warehouse master, The latter two parameters are actually the locations of the two warehouses to be synchronized .
When only specify localPlace When remotePlace The default value of is the branch name we are tracking ( We need to pay attention to push.default The value of the parameter ), If the current branch is the branch you want to commit , So you can write it directly git push

there localPlace and remotePlace According to the official instructions, it's a refspec,“refspec” It's a self-made word , intend git A recognizable position ( Branches such as bugFix perhaps HEAD~1).

git fetch

git fetch and git push And its parameters and their analogies , They are the same concepts , Just in the opposite direction ( Because you are downloading now , Instead of uploading )

git fetch <remote> <remotePlace:localPlace>

for instance

git fetch origin master

git It's going to the remote warehouse master On the branch , Then get all submissions that don't exist locally , Put it in the local origin/master On , Be careful fetch Does not update local non remote branches , Instead, download the submission record .

If you want to update local directly master Branches are not not not not allowed , Just run the following command

git fetch origin master:master

Theoretically, it can , But it's highly recommended not to do that .

When we only execute git fetch Without any parameters , It will download all the submission records to each remote branch .

git pull

Learned to git fetch, that git pull It's easy ,git pull The only concern is where the submission will eventually merge . I said before

git pull == git fetch;git merge

that

git pull origin bugFix ====  git fetch orign master; git merge origin/bugFix

get pull

As you can see in the figure above, the current branch is bugFix, perform pull After the command origin/master The direction of has changed ,bugFix The content of the branch and the remote end master The contents of the branches are merged , Break down the order into 2 I believe it is easier to understand .

summary

git The series is now over , It's written in total 6 An article , Three theories , Three practical applications . Theory is the basis of practical warfare , It's easier to understand the theory ,git It's not going to be hard anymore , Of course, I can't explain every command in detail ,
however 2-8 The theory is git The same applies to , If you want to have a more detailed command , I believe official documents are the best .

版权声明
本文为[think123]所创,转载请带上原文链接,感谢

Scroll to Top