The last article looked at some of the most commonly used commands, but mostly in the general case, and the next one looks at some of the more unusual ones.
First of all, the remote warehouse is the most direct contact for us locally. As for the remote warehouse of others (the warehouse where we modify files together, hereinafter referred to as the remote warehouse), we mainly conduct Mr Through the remote warehouse.
So how do we ensure that other people’s changes are in our warehouse
pull
You can see that there is a others. TXT file in the remote repository, but the local repository does not have it. To synchronize the local repository with the remote repository, you need to use pull
This corresponds to push, and is usually followed by the address of the remote repository (the previous article briefly explained how to set the addresses of different remote repositories).
When Mr Conficts
You can find that the new file has been added locally. Note that the file we modify is also in the remote repository, so if someone thinks our file is not good enough and changes it.
For example, the helloWorld submitted last time, I thought it was too simple. I only printed it once, and then added a for loop to print it 100 times, and added the serial number after each printing.
At the same time, we felt that the code wasn’t good enough, that we needed to repeat it 1,000 times, and that we wanted to repeat the classic line after output, so we changed the native code.
Then you push the code and Pull the Merge Request, which is also called a Pull Request
There is an alarm that the Pull Request cannot be merged automatically, you should merge it manually. In fact, you and others changed the uniform line in the file at the same time, which conflicts. After that comes conflict resolution, which should vary from platform to platform, but is essentially Git.
So I’m going to have to go back and forth between the programmers, whose argument (b) is going to be, and I’m going to assume that this is going to keep the I + 1 but it’s going to loop 1000 times. So I need to change it to be
In fact, in principle, it doesn’t matter if you delete the code of this file, because Git has told you that this file has conflicts. As for how to choose and what to keep, Git thinks we will deal with it well. When all these are completed, it is consistent with the previous Mr, and can be incorporated after passing the audit
However, it is always a bit troublesome to resolve conflicts during Mr, so the common practice is to pull the latest code after COMMIT
Pull the conflicts
You can see that the remote warehouse is now dripping like this
The file was then modified remotely, simulating other colleagues incorporating the new code
Also without knowing it, we want to add a getStr method and call it inside the main function
After editing, add and commit normally, but don’t push, pull the remote repository code first
There is a message at the end that says let’s resolve the conflict
Auto-merging hello.java
CONFLICT (content): Merge conflict in hello.java
Automatic merge failed; fix conflicts and then commit the result.
Copy the code
How to solve the problem is to edit the conflicting files. Use Vim to see what the conflicting files look like
Just delete <<<<<<<, =======, >>>>>>> and HEAD, which are not what we want, and keep the required code. Finally, add Commit Push Mr As normal.
At this time, there will certainly be some new friends asked, then if the change period other people into the warehouse into the code what to do
I’m kidding, but 99.99% of this happens in theory, not in the real world. If it happens, resolve it.
stash
- We changed several files like ABCDEF… Z These 26 files
- The supervisor came and said that there was a module that was very urgent and needed to close the four files ABCD first
- Someone in the remote warehouse has merged these two files of LX
- Then make it a good habit to commit and pull your remote code base
Summary is that you don’t want to commit all the modified files, and there are conflicts in the modified files
This means that some local files may be overwritten at merge time, and there are two options
- Commit, and then resolve the conflict
- Stash, and then pull down, and then stash pop if there’s a conflict, resolve the conflict
Stash is to place local changes in a Git “stack”. Local vs. remote is the unmodified state and then pull normally
Git stash Save [Save message] with git Stash Save [save message], you can pull it down successfully
If you can save it, you can definitely retrieve it. As mentioned above, if you save the same file as the remote repository modified file, there will be conflicts when pop it out
The solution is also to deal with conflicts, which I won’t go into here
reset
As mentioned in the first article, add and COMMIT can be pulled back according to status, so there must be corresponding operations after push.
You can see that there are at least two files going on in this push, and in order to undo the push, you first have to know what the push is and what the push is
Use git log to view it, but git log has many operations (that is, beautify), the most common ones are the following
-
Add nothing, output all and verbose
-
Git log -p for the first few
-
Git log –oneline
Git log –oneline -2
Git reset (version number) git reset (version number) git reset (version number) git reset (version number) git reset I know online about reset also have a lot of operations, how many times what before the reset, but are not as good as viewing the version number back, have to use the time to check it.
I want to go back to the previous version, just do that
You can see that the two files that were pushed are now ready to commit.
Creation is not easy, if it is helpful to you, welcome to like, collect and share!
Below is an individual public number, have interest can pay attention to, perhaps be your treasure public number!!