Environment part skip
Create a project from 0 to explain git, including creating remote new branches, rolling back and other operations.
There will be questions and questions during every explanation
- Basic part explanation
- Practical advanced part
Basic content
If you already have a warehouse on github, use idea to clone
If it is in the interface below, follow the steps below
Perform clone download
If it is the following interface, pass
Same as above
If you don't have an existing project on github or want to create a new project
Create a new ordinary project through IDEA (whatever, maven is fine)
As shown below
An ordinary maven project of TestGit (a new project is not version controlled)
The first step is to introduce VCS (version control system acronym for VCS), corresponding to the VCS option at the top of the idea. There are windows and Help on the side
Turn on version control as shown below
Choose Git as the demo here
As shown in the figure below: there is an explanation in the screenshot
At this point, it should be noted that the version control here is the local warehouse.
It will be submitted into the local submission and remote submission (login required github account)
Log in to github in idea as shown below
There are two ways to log in:
Account + password to log the highest authority have all the privileges of the account
Token login permissions are created by the account owner, and the corresponding permissions are assigned
Token creation address: https://github.com/settings/tokens
As shown below:
As shown in the example below: you need to select the corresponding permissions assigned and fill in the Note (for the convenience of direct management later, it is mainly to know which Token is this Token)
After creation, you can log in the obtained Token directly with IDEA
Submit locally
First of all, you need to pay attention to which files need to be submitted. Select the file ===》 right click ===》 git ==》add to version control the file
Common mistakes for novices:
Directly select the item for Add (some unnecessary files will also be version controlled)
My advice is:
Just add the src folder and pom.xml file to the Add operation, and the configuration file related to the code, for the following files
.idea folder
xxxxx.iml file
Such files are automatically generated by Idea not to be submitted because these configuration files are environment settings on your computer.
If these files are submitted, it is not good for the team to develop collaboratively.
Because these files will be cloned when the clone is down, so that the other party's idea will use the configuration file under the project instead of loading the configuration on his own computer
The specific jdk version and path (the other party may not find the jdk and need to manually set up the SDK) and the other party's idea usage habits and other settings will be the idea configuration on your own computer. Therefore do not directly select the item to add
Be sure to manually select the corresponding file yourself. Do not add this kind of unnecessary files.
Undo Add can be undone by Ctrl Z, or by selecting the file Git as shown below
Generally speaking, only the Add src folder and pom.xml file are needed
There is a feature of git submission. If no files under the folder are under version control, then when you submit it, you will find that there are no folders such as src in the warehouse, but only a pom.xml file.
In other words, Git only performs version control on files, not folders, which is easy to understand.
Make a local commit
Mainly to generate some data for later demonstration, here I create a new Hello class (package path top.huashengshu) in src and Add it in
The √ symbol on the toolbar of the submit button
Of course, you can also right-click to submit, or you can submit via git in the VCS option bar above. Click the button above to submit directly
Click Commit for local submission
For remote submission, choose:
View log after local submission
Share the project to the remote warehouse on github (create if there is no, submit if there is, and create it directly here)
You need to log in to the github account, and then there will be the following pop-up box, enter the warehouse name, description, and whether it is private
Corresponds to new on github
After success as shown below:
Icon description:
The green branch represents the local branch
The yellow one is the Head pointer, the yellow label will move after the local submission meeting
The above screenshot is wrong, there are 3 branch records, and the Head yellow mark is only used to indicate the current branch position. When submitting, the branch will be delayed according to the yellow mark.
New local branch
New remote branch
Remote branches need to be generated by local branch push
That is to say, the push operation will trigger the creation of a branch. If you have not submitted a remote branch, and plan to push the local branch to the remote to generate a new branch, follow the steps below
Then click Push to create a new branch. As shown below, go to github to check the newly created branch
In addition, you can also push as follows
In addition, you can trigger push through the following
In addition, right-click to trigger the creation of a new remote branch
The above is a more basic branch operation
Advanced part
Including conflict management, branch rollback, commit processing error
Code conflict handling
Generally speaking, a large project will be jointly developed by many people. We often submit and pull down code while using Git for daily operations.
Many people will encounter some problems when modifying the project
For example, programmer A submitted a code at night
The next day, programmer A and programmer B went to work. The first thing is to check whether the code on the server is updated, that is, the following operation:
So the code obtained by programmer B is:
After programmer A went to work, he suddenly thought that there was a bug in the code last night, so programmer A quickly corrected it and submitted the code.
The previous version of git by programmer B is the above version.
After programmer A submits the code, the code in the remote warehouse becomes
Because programmer B does not know that programmer A has submitted the code again, and then after programmer B finishes his own code, the code on programmer B’s computer looks like this
At this time, because the version on the server has been modified, in order to ensure that programmer A's code can be retained, the programmer needs to integrate the code as follows when pushing to the main branch:
Here, because of the different number of code lines, they are directly merged. Because programmer A and programmer B operate the same class, but they do not affect each other and are merged directly.
In the above commit and push, it is suggested that this class code is different, and the background color is your own code, and the remote server is the left window.
Final Results:
If programmer B and program A modify the same line of code, you need to manually confirm whether to use programmer A's code or programmer B's code, or to add both.
Assuming the server version is
Both have carried out an update project. Programmers A and B have modified each other’s code. Programmer A first submits the following:
B also modified the code, and both of them changed the same line of code
Ask programmer A to submit first, and A can submit normally. B will prompt
Programmer B operation:
If you choose Accept Yours, programmer A's code will be overwritten
If you choose Accept Theirs, then programmer B's changes to the line will not take effect and submit it.
If you choose merge, select it manually (this is usually selected in development, because you need to know the code changed by programmer A)
The result of the merge will be rejected because the conflict needs to be resolved first, which means that the merge is performed locally, and then the code is pushed to the remote after the merge
At this time, you cannot use the button to operate, you need to select a branch to merge (merge the remote warehouse with a local branch) and then push the branch up
At this point, you will find that it is successful, and it is easy to understand. The merged code is just more code modified by programmer B himself. For git, it is equivalent to a one-person operation (emphasis) . It is considered safe and natural. You can submit successfully
The final github must also be the local current master branch after programmer B merges. The final result on github is shown in the figure
The explanation is successful, and various situations of modifying the same line of code are solved.
For this kind of conflict, you need to merge into a branch locally, and make sure that no one else submits the code again. For git, only one person can modify the code at a time. If multiple people modify the code, it is still necessary to ensure that it is at one time. Only one person in the paragraph can modify the code, and other people want to submit the code. The conflict must be resolved first, and then submitted.
If programmer A keeps submitting, then programmer B must wait for the final version of A to be submitted. Programmer B merges the code from the remote warehouse into the local warehouse and submits it after resolving the conflict. If programmer A submits the code again during the submission period, then program B will have to merge and then submit (only one person can submit successfully in a period of time)
Code rollback operation
Take programmer A as an example:
The local submission record of programmer A is as follows
First of all, you need to understand that the rollback code has four forms: Soft, Mixed, Hard, Keep
To distinguish the difference between soft, mixed, hard, and keep, you first need to understand how git performs version control and what is the principle of git.
The principle of git:
Git performs version control by judging the status of the file. How does git judge the status of the file? Git will perform a hash value algorithm on the file and obtain a hash value through the hash algorithm. If this hash value and the current Head (I call Head pointer) compare the hash value of the current branch pointed to. If it is different, it means that the current file has been modified (at least when compared with Head)
Then the modified file will definitely require version control. When we submit the code, he will judge the current hash value and compare it with the hash value of the last updated project locally. First, it will judge the comparison between the last hash obtained from the remote warehouse and the hash value performed by the head in the remote warehouse. Whether it is consistent or not, it means that there will be no conflict, because the code is only modified by you. If it is not, it means that the remote warehouse has been modified by someone, causing the head pointer of the remote warehouse to point to the new location, and the hash value is the new hash value.
It is a bit like the CAS algorithm first to determine whether the service warehouse file has been modified.
Our analysis of the submission record of programmer B:
You will find that the yellow label and the green and purple ones all point to the same location
The yellow label is the location of the submission record pointed to by the head pointer, and the green one represents the current submission record (when git performs an upload operation, it is first submitted locally, which is the green mark. After the submission, the yellow mark Head will point to the same position as the green )
When a push is made for a remote commit, it is pushed on a certain branch record
At this time, before submitting the operation, it will be judged whether the server code has been modified by other programmers (by comparing the hash value)
- That is to say, programmer B's computer must save the hash value obtained during the last update when the local warehouse was updated last time.
- Compare the last hash value with the hash value of github at this time. Determine whether the remote warehouse file has been changed. If it has been changed (the hash value in the same file). At this time, the hash value is not the original hash value. If so, you have to merge the github warehouse with the local warehouse before submitting. If there is no change, it means that no one has modified the code on github, then you can submit it directly, because only one person has changed the code)
There are 3 concepts in Git
- Submit record
- Buffer area
- Work area
The workspace is the moment when our idea modifies the code and operations in real time
The cache area is to manually select the files that need to be version controlled through the git Add command and the Rollback command
The submission record is to submit the files in the cache area
Will not be submitted through the workspace, but submitted through the middle layer of the cache
The difference between soft, mixed, hard, keep
The hint in idea is
The above about Files won't change refers to the work area (that is, you modify the file in real time without changing the content in the file)
Both soft and mixed can be rolled back. Re-execute the head pointer to the position you selected as shown in the figure below.
But the difference between the two rollbacks is that the soft operation will not undo the files in the cache, while mixed will make the cache and partition records the same.
Suppose we are talking about adding a file to the buffer area, as shown in the figure below, right click add
Red means files that are not managed by git, add them to the cache
After that, the status of the file changes to green, indicating that the file is managed by git
If we just perform a soft rollback, the state of the cache will not change, and the file will not change either
It is equivalent to soft just saying that the head pointer points to the record position you choose to roll back. The current file status is as follows. We roll back to the second submission position through soft
SOFT and MIXED
In order to demonstrate the effect, we will submit once and see how this branch record first went.
Just submit locally, you will find one more branch, in fact mixed can also achieve this effect, as long as the hash value executed by the head is different from the cache area, the submission can be made
If you want to change the status of a file, such as canceling the version control of some files, we can choose mixed, and it will roll back to the selected moment. For files under version control, if there are some files in the cache area that have not been versioned at this moment, the version control effect will be cancelled as shown below. I just want to mix to the initial moment
If merged, it should be connected to the front
The following is the refresh item, it may not be displayed, so just refresh it
HARD 和 KEEP
Hard is easy to understand, that is, mandatory rollback. This operation will roll back all states to the selected moment, the file will change to the previous submission, and the code will return to the previous one. There is no demonstration of this. Rolling really rolled back. And never return to the previous state. Unlike the previous soft and mixed
And Keep
My understanding is that HARD and KEEP operate on the workspace
And Soft and Mixed operate on the buffer area
Actual case
Programmer A is an old employee
Program B is a new employee. Due to misoperation, the .idea folder was submitted to the github of the remote warehouse. Lead programmer A and other employees need to change the idea environment to their own environment, such as SDK
problem:
Now it is required to delete the .idea folder from the remote warehouse github through IDEA's Git operation, but the code submitted by programmer B will not be deleted
answer:
My approach is to build a cache on employee B’s computer that only contains correctly integrated code, and does not include the .idea folder in the version control cache
Then create a new branch through the cache area to bypass the branch that was incorrectly submitted to the .idea folder. And set the branch as the default branch
That is, through the mixed rollback to not contain the .idea folder into version control, because the mixed method will not modify the code of the workspace, but the head pointer points to the location where you choose to roll back. Of course, you need to update the project. Remotely merge into programmer B's local warehouse, then mix, and then manually add files that need to be version controlled to git version control.
It is best to create a new branch through push
Operate as shown below
Starting state
It can be found on github that the submission is up, and now it is reorganized
At this moment, it is not included in version control and submitted. If the following merge occurs, generally choose your version, because I am a simulation here, in fact, the code must be based on the local workspace.
Then you can push
After success, you will find the created newBranch branch on github
The next step is to set him as the default branch (there should be corresponding operations in IDEA)
If you want to delete the branch as shown below
