This article introduces Git's actual combat. It only talks about dry goods. Everything starts from reality and seeks truth from facts. It doesn't talk about those rarely used in work.
What's more, those who engage in technology must have the spiritual realm of knowing its nature and why, otherwise it can't become a climate.
By default, the git Sakamoto installed by Centos7 using yum is 1.8.x.y, which is too old.
git version # Uninstall legacy yum remove git -y yum install \ https://repo.ius.io/ius-release-el7.rpm \ https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm yum search git |grep -E '^git' # Select the version you want to install yum install git224 -y
Git basic operations
Add files to staging area
git add readme.txt
git commit -m "add readme.txt"
If Changes not staged for commit is encountered, it indicates that there are files under the warehouse that have not been added or that the modifications have not been submitted to the staging area. First execute git add file name, and then execute the submit action or git commit -ma xxx, and directly operate in one.
View submission log
- Concise writing:
git log --pretty=oneline
- Fallback to previous version
- Scenario 1: if there is no commit after add, use:
git reset HEAD readme.txt # discard changes in working directory git checkout readme.txt
Note that git reset HEAD only affects the temporary storage area, not the contents of the workspace. Therefore, you also need to execute the git checkout command.
- Scenario 2: commit ted
git reset HEAD^ # or git reset [commitId] git checkout readme.txt
- One step in place
git reset --hard HEAD^
Note: add the parameter – hard, and directly modify the content of the workspace. Operate with caution.
If you do not execute an error message, reset and other operations, and then restore? Git provides the reflog command to record your historical operations. We only need to find the commit id of the historical operation, and then use git reset --hard [commit id] to go back.
The workspace, as its name implies, is a folder that has been initialized with git init.
It is used to temporarily store the modifications submitted by git add.
The workspace has a hidden directory. Git, which is not the workspace, but the Git version library.
- Scenario 1: delete working directory file
For example: git rm test.txt, and then use git status to see which files have been deleted:
At this time, if you really want to delete, continue:
# Delete the in the version library git rm test.txt
Otherwise, execute git checkout -- test.txt, that is, overwrite the working directory with the version in the version library. In this way, the wrongly deleted file is restored:
In work or study, local projects are usually managed in a remote GIT warehouse. The advantage is that if I have multiple computers or individuals to develop the same project, it is convenient for centralized version management. As long as the modified content on each person or device is submitted to the remote code warehouse, other devices can pull and update to the local library. Common remote warehouses include Github, domestic code cloud Gitee, private server GitLab, etc. Here, take the code cloud as an example to show how to use GIT in our virtual machine_ in_ The action project is hosted to the server.
Add public key
This step is to tell the remote warehouse the identity of the device. If you have multiple devices, you can generate different public keys on multiple devices and upload them to the code cloud. For example, my:
- Generate public key
Only 2 commands are required:
# Replace your mailbox with your mailbox, and press enter all the way when prompted ssh-keygen -t rsa -C "firstname.lastname@example.org" # View generated public key cat ~/.ssh/id_rsa.pub
Warehouses are divided into public and private. Private can only be seen by themselves, and public owners can see and participate in collaboration.
Since we have a git warehouse locally, we need to upload the local content to the remote git warehouse, and operate as follows:
# Configure remote warehouse address git remote add origin https://gitee.com/indexman/git_in_action.git # Push local warehouse content to remote warehouse git push -u origin master
If you don't want to prompt for the password every time you push, you can change the remote warehouse to one without https:
git remote rm origin git remote add origin email@example.com:indexman/git_in_action.git
git clone firstname.lastname@example.org:indexman/git_in_action.git
# Create the dev branch and switch to the dev branch git checkout -b dev # View current branch git branch
Modify the file under the dev branch, and then switch to the master branch after submitting to merge the modifications.
vim readme.txt git commit -am "dev commit" git checkout master cat readme.txt # merge git merge dev cat readme.txt # Delete branch git branch -d dev
Note: you can also use: git switch -c dev to switch branches
- Scenario 1: two branches make different modifications to the contents of the same file
For example, the dev and master branches have made different changes to the last punctuation in the last line of readme.txt. At this time, a conflict message will be prompted when merging:
- commit after conflict resolution