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 .
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 ).
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 -b bugFix origin/master
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 .
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
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 .
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
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 .
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>
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
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 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>
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 .
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
git pull origin bugFix ==== git fetch orign master; git merge origin/bugFix
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 .
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 .