There is no big difference between local warehouse and remote warehouse in essence, but one is local computer and the other is remote computer
Remote warehouses don’t have to be
githubThat kind of special “central server”, even another computer in LAN, can also act as “central server”, because its original purpose is to facilitate the exchange of submission records!
Therefore, the basic behavior of the local warehouse and the remote warehouse should be consistent. The conventional rule is that the remote warehouse does not directly participate in the daily development work, but mainly acts as the project hosting center
Some automated continuous integration environments may also operate remote warehouses directly, so remote warehouses are no different from local warehouses!
Common commands for personal development
Personal development focuses on efficiency, and taking into account version control is the icing on the cake,
gitThe local warehouse is local backup, while the remote warehouse is network disk backup
git init: initialize local project
Initialize local project
gitProject, the intuitive performance is that there are more under the same level directory of the project
.gitHidden directory, which stores
gitVersion library related information
Since then, the current project has the ability of local management, which can be combined with
git clone: Clone remote project
git initThe same function is to create a local warehouse, but
git initIs to directly use the local project as the local warehouse, and
git cloneIs to clone the remote project to the local and use it as a local repository
thus it can be seen,
git initA new layer of remote warehouse concept
git add: Add File
Add the submission records of the workspace to the staging area. The staging area is the bridge between the workspace and the version library. When the staging area accumulates a certain amount of submitted records, it can be submitted to the version Library in batches. This is a bit like a cache
git commit: submission of documents
The version of the staging area is submitted to the version library to form the basic link of workspace, staging area and version library. The version control process of local workspace is roughly the same
git push: push file
If it is used
git cloneWhen the local project of command clone is working to a certain extent, it may be necessary to push this part of the work results to the remote warehouse
git pushCommand to complete the local version of the push process
If it is used
git initIf a remote warehouse is created later, you naturally want to push the local warehouse to the remote warehouse, so you need to tell the user exactly
gitWhich remote warehouse do you want to push
git remote add origin [email protected]:username/repos.gitCommand to add remote warehouse information, thus establishing the association between local warehouse and remote warehouse
Common commands for team development
Team development focuses not only on individual efficiency, but also on the overall progress of the team. With the increasing complexity of enterprise level development, it is no longer possible for one person to complete it independently. Moreover, time is not allowed to be completed slowly. Most companies adopt the method of replacing human resources with time. Team parallel development shortens the whole project cycle, which is exactly the case under such complex requirements
gitIt’s a good chance to make a big show
The whole project adopts the parallel development mode, which is disassembled into different functional modules. Each person is responsible for their own modules. The modules are relatively independent, but the possibility of intersection is not ruled out. For each individual developer, both version control and team communication are needed. At this time, the role of waiting branches is highlighted
According to the business characteristics of the project, it is decomposed into different functional modules, which represent different branches respectively, and these functional modules constitute a complete project, which is the relationship between the trunk and the branch
At the beginning, the project is a whole, which is disassembled into different functional modules, and finally merged into a whole – “long time division, long time division”
git branch <branch>: create branch
Each independent function module is defined as a separate branch. The process of creating a branch is actually the process of dismantling the project. After the local branch is created, special functions are developed on the branch, and other functional branches are no longer concerned
git checkout <branch>: switch branch
After the module is disassembled and the corresponding branch is created, it needs to switch to the given branch to carry out its own work
git merge <branch>: merge branches
There is no absolute independence. No matter how to split the project, it is also a part of the whole. It must be related to other functional modules. In some cases, the work results of other branches need to be merged into their own local warehouse, so as to complete a small-scale assembly
It can be expected that when this kind of assembly is enough, it will eventually evolve into the ultimate form of the project and form a whole
git fetch: grab remote branch
To merge a target branch, we need to be able to obtain the submission record of the target branch. Since each function module is developed by different project members, it is not on our computer. Therefore, we must download the target branch to our local computer before merging the branch to the local branch
git pull: pull remote branch
“Download the target branches first, and then merge them into local branches, so as to form more complex and powerful functions in a small scale”. Each assembly process requires two steps. Obviously, the operator is not in line with lazy thinking,
git pullIt is the simplified command of these two steps. Download and merge is so simple!
Collision between local and remote warehouses
Whether it’s personal development or team development, we’re almost used to thinking from the perspective of the initiative. Have you ever thought about when the remote warehouse receives our
git pullWhen requested, what changes have been made to the remote repository, and what is the impact of this change on the local repository?
Remote warehouse (the local warehouse on remote computers) is just one of the local warehouses on many distributed computers. It is special and special. It acts as a “central server”, and the rest of us download or push it from here. It is ordinary and ordinary, which is no different from the local warehouse on the local computer, because it can be replaced by the local warehouse on any computer at any time!
After unveiling the mystery of remote warehouse, now we only need to treat it as ordinary local warehouse. However, we already have a local warehouse on our local computer, so we need to make a simple identification of remote warehouse（
origin）This is called a remote branch
Let’s talk about it first
git pushWhat did the order do?
- For the local people,
gitThe specified branch of local warehouse is pushed to the corresponding branch of remote warehouse, and the remote branch of local warehouse is updated
- For the remote,
gitWhen receiving the push request from the local warehouse, the local branches should be merged on the corresponding branches, and the corresponding branches of the remote warehouse should be updated
As long as the local specified branch is successfully pushed to the remote corresponding branch, for the local, whether the specified branch or the remote branch（
origin/master）All should be up to date because they are synchronized with the server
When receiving the push request remotely, you should try to merge the push request, update your corresponding branch, and then notify the local push result after the remote merge is completed. In this way, the three terminals are synchronized and everyone is happy!
Let’s talk about it again
git pullWhat happened to the order?
- For the remote, when receiving a local pull request, no operation is required because there is no new version to be processed
- For local, when the corresponding branch of remote warehouse is downloaded to local, the remote branch status should be updated, and then try to merge to the local branch
git pullCommand, or is it
git fetchCommand is a way of local and remote communication, so
origin/masterWill automatically update!
There is no big difference between a local warehouse and a remote warehouse,
git fetchIt is the communication channel between the local warehouse and the remote warehouse, and the remote branch in the local warehouse（
origin/master）The last communication between them is preserved
This article introduces the essence of local warehouse and remote warehouse of GIT introductory tutorial. For more relevant contents of GIT local and remote warehouse, please search the previous articles of developeppaer or continue to browse the related articles below. I hope you can support developeppaer more in the future!