I recently changed jobs. In the new company, I used git for the software version control tool, and my previous company used svn.
First impression, I feel that git is much better than svn. Now let me compare the differences between the two tools and briefly introduce the git commands.
1. Difference
1. Git is distributed and svn is centralized.
Both git and svn have a centralized place to store code. The difference between them is that each developer interacts directly with the central repository for each modification. However, in the case of git, developers interact with the local repository (repository) when making changes, and wait until a specific time point or progress point to push (push) to the central repository.
2. git stores data as metadata, but svn stores it as files.
All resource control systems hide the file's meta information in a folder like .svn, .cvs, etc. If you compare the size of the .git directory with the size of the .svn, you will find that there is a big difference.
3. The branch concept of git is better than svn
The branch concept of svn is to copy a new code. This method is very primitive and time-consuming and space-consuming. Git branches are stored as a snapshot, creating branches quickly and without space consumption.
4. The content integrity of GIT is better than that of SVN
GIT's content storage uses the SHA-1 hashing algorithm. This ensures the integrity of the code content and ensures less damage to the repository in the event of disk failures and network problems.
2. Summary of git commands
1. git status View the status of the current warehouse
2. git diff to see the difference
git diff compares the difference between the working directory tree and the staging area
git diff --cached Compare the difference between the staging area and the repository
git diff HEAD compares the working directory tree (including staging and unstaged) with the repository
git diff HEAD -- filename.txt View the difference between the file filename.txt
3. git add commits changes from the working directory tree to the staging area
4. git commit -m "message..." Commit the changes from the staging area to the repository
5. git log shows the commit log from near to far
git log -n displays the number of output, n represents the number
git log --name-status displays the commit log from near to far, and the log shows the files modified by each commit
git log --stat only displays brief statistics on the number of lines added and changed
git log --pretty=[oneline | format | short | full | fuller]
6、git reset
git reset -- hard HEAD^ go back to the previous version
git reset --hard [commit] Any changes in working directory since commit will be discarded
git reset --soft [commit] All changes since commit will be shown in changes to be committed in git status
7. git checkout
git checkout -- file undo changes ( that is, to return the file to the most recent state )git commitgit add
git checkout -b branch1 master creates a new branch and checks out to the new branch
git checkout dev switches to the dev branch
8. git push push to remote
git push origin HEAD:refs/for/master This is a push method of my company. Before pushing the changes to the remote, there must be a review process
9. git clone clones one to the local library
10. git branch dev creates a branch dev
git branch -d dev delete branch dev
git branch -m dev development renames the dev branch to development
11. git merge merges the dev branch into the current branch
git merge directly merge [straight merge], merge one branch directly into another branch
git merge --squash branch1 Squash merge [squashed commits], compress all commits on a branch into one commit
12. Half of the git stash work is done, I want to switch to another branch to deal with the problem and save the environment of this workspace
git stash list to view the saved workspace environment
git stash apply restores the working environment
git stash drop deletes the contents of stash
git stash pop =git stash apply+git stash drop
13. git rebase rebase, redefine the repository state of the branch
git rebase test
1. First checkout the code of the test branch as the working directory
2. Then apply all the changed patches created by the master branch from the test branch in turn. If there is no problem with the patching process, resolve the conflict
3. If there is a conflict when patching, resolve the conflict, you can run git rebase -continue later
4. If you don't want to deal with conflicts, either abandon the rebase process (git rebase -abort), or replace the current branch with the test branch (git rebase -skip)
14. git cherry-pick <commit-id> Merge a commit on the local test branch to the local master branch, and the command can be executed on the master branch.
15. git tag <tag-name> <node> tag
16、git blame
git blame test.file line git blame; when commanded, the file will be displayed line by line, and the commit number , the committer, and the earliest commit date will be displayed at the beginning of each line.
Reference blog: http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000