Git
Article directory
- Git
-
- Simple clone of project
- Common operations
-
- Add and submit
- rollback
- branch
- rebase branch
- preferred
- Remote project push
-
- Certification
- Crawl, pull and conflict resolution
- IEDA software connection
I’ve been learning principles so much lately that I’m almost bald, so I’d like to come up with a purely operational version that doesn’t talk about principles, but let me show you a picture.
Simple clone of project
The most important function of git in my daily life is downloading, so I’ll start with downloading.
First, create a file to store the project that will be cloned later, and then click GitBash to perform command line operations.
Then find the project you like on git, as shown in the figure, copy the link
git clone https://github.com/newbee-ltd/newbee-mall.git
You will then see that he is cloning your project to a local folder. Of course, you can also directly download the zip and unzip it:
Common operations
Let’s talk about the general ones later. First configure the user name.
git config --global user.name " " git config --global user.email " "
Then create a local repository
git init
Turn on this option to view hidden folders:
Discover
This directory is a hidden directory, and the current directory is our working directory.
After the creation is successful, we can check the current status and enter:
git status
If it has been successfully configured as a Git local warehouse, you can see this after entering:
Add and Submit
Next, let’s take a look at how to use git to manage the version of our document. We create a text document, write some content, and then check the status:
Untracked files means untracked files. That is to say, if a file is in an untracked state, git will not record its changes and always treat it as a newly created file. Here we add it to the staging area. Then it will automatically become tracked:
git add hello.txt #You can also add . Add all files in the directory at once Check the current status again:
The file name color now changes to green and is under Changes to be committed, so our hello.txt has now been added to the staging area.
Then let’s try to submit it to the local Git repository. Note that you need to enter the description of the submission for subsequent viewing, such as what content you have modified or added this time:
git commit -m 'Hello World'
Then we can view our submission records:
git log git log --graph
We can also view the details of the most recent change:
git show [You can also add the commit ID to view the specified commit record]
Then we can try to modify our text document. Since the current file is already being tracked, git will track its changes. If the file has been modified, then we will check the status again and get the following results:
That is to say, this file is now in a modified state. If we modify it, we can submit our new version to the local warehouse:
git add . git commit -m 'Modify Text'
Next, let’s check the submission records. We can see that there are two submission records in total.
We can create a .gitignore file to determine a file ignore list. If the file in the ignore list exists and is not tracked, git will not perform any checks on it.
Rollback
When we want to roll back to a past version, we can perform a rollback operation. After execution, we can restore the contents of the workspace to the state of the specified submission:
git reset --hard commitID
After execution, it will be directly reset to the state at that time. Looking at the commit log again, we found that all subsequent logs have disappeared.
So what if I want to go back now? We can view all operation records of all branches by:
git reflog
In this way, you can find the previous commitID and reset it again.
Branch
A branch is like a branch on our tree. They may be the same branch at the beginning, but as they grow, they start to diverge. This is a branch. The same is true for our code. We may use a single branch when writing basic functions at the beginning, but one day we hope to make our project into two projects in different directions based on these basic functions, such as building a Web website in one direction. , the other direction is to do the game server.
Therefore, we can divide N branches on a trunk to maintain the code of multiple branches respectively.
Create a branch
We can view the branches that exist in the current warehouse with the following command:
git branch
We found that there is a master branch by default, and we also use the master branch. Generally, the master branch is updated with the official version, while other branches are generally updated frequently during development. We then create a new branch based on the current branch:
git branch test
delete branch
git branch -d test1
Now we modify the file, submit it, and check the submission log:
git commit -a -m 'branch master commit'
By adding -a, you can automatically put modified files that have not been placed in the staging area into the staging area and perform the commit operation. Looking at the logs, we found that our submission now only takes effect on the master branch, and the newly created branch has not been modified.
Switch a branch to another branch:
git checkout test
We will find that the file becomes the state when this branch was created, that is to say, the contents of our files under different branches are isolated from each other.
Now if we submit the change again, we will find that it only takes effect on the yyds branch. We can take a look at the current branch status:
git log --all --graph
merge branches
We can also merge the updated content of the two branches into the same branch. We first switch back to the main branch:
git checkout test1
Then use the branch merge command:
git merge test
You will get the following prompt:
A conflict occurred during the merge process because both branches modified the hello.txt file. Now that they are to be merged together, whose hello file will be retained?
We can check where the conflict occurred:
git diff
Therefore, now we roll back the version of the master branch to before modifying hello.txt or directly modify it to the latest version, so that there will be no conflict, and then perform a merge operation again. Now the two branches are successfully merged into the same a branch.
Rebase branch
In addition to directly merging branches, we can also perform rebasing operations. It is different from merging. Merging is the process of returning branches to the trunk, while rebasing is to directly modify the starting position of the branch. For example, we want to rebase yyds to master. Then yyds will move the branch starting point to the last commit position of master:
git rebase master
After rebasing, the yyds branch is equivalent to synchronizing all the commits of the previous master branch.
Preferred
We can also choose to apply the commits on other branches to the current branch. This operation is called cherrypick:
git cherry-pick <commit id>: Merge a commit separately
Here we create a new file on the master branch, submit the update, and then apply the update to the test branch through cherry-pick.
Remote project push
Certification
First we need a certification
ssh-keygen -t rsa cat ~/.ssh/github.pub #needs to be replaced
Open the directory where you are located, copy all the contents in the .pub file, and then add the ssh key
git commit -a -m 'Modify files' git log --all --oneline --graph git push origin master git log --all --oneline --graph
Push successful
Also saw the homepage
You can also bind branches remotely
git push --set-upstream origin master:master git push origin
Crawling, pulling and conflict resolution
If there are multiple local warehouses corresponding to one remote warehouse, for example, in a team, N people are all using the same remote warehouse, but each of them is only responsible for writing and pushing the code of their own business part, which is what we often call collaboration. work, then at this time, we need to coordinate.
If the progress is different, you need to perform a pull operation to obtain the latest submission in the remote warehouse:
git fetch remote warehouse #Fetch: only fetch but not merge remote branches, we need to manually merge them later to submit git pull remote warehouse #Pull: get + merge
Conflicts may arise later, such as:
To https://github.com/xx/xxx.git ! [rejected] master -> master (fetch first) error: failed to push some refs to 'https://github.com/xx/xxx.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.
Once a local warehouse pushes code, the push from another local warehouse will be rejected because the current file has been modified by other pushes. Our side is equivalent to another version, which is the same as the previous two branches merged. There is a conflict, so we can only solve the conflict problem.
If the submission in the remote warehouse and the submission in the local warehouse do not write the same file, then you can pull it directly:
git pull remote warehouse
After pulling, it will be automatically merged, and we can submit it after the merge is completed.
But if two submissions modify the same file, then you will encounter the same situation as a multi-branch merge. Conflicts will occur during the merge, and we need to resolve the conflicts ourselves.
IEDA software connection
The following uses GoLand as an example, and IDEA is also very similar.
Then log in to the account
You can submit it after that, and the commands are pretty much the same.
The operation ends here. Those who are interested can learn more about the principle.