Illustrated Git principles and daily practical guide
January 10, 2024
by Alison McGregor
No Comments
origin
I have learned a lot from reading the teacher’s pamphlet Git Principle Detailed Explanation and Practical Guide, so I want to write something to make a summary, not only to deepen my own impression, but also to give some help to the community partners. If there is something wrong, please give more guidance. As a novice in the front end for half a year, I have gradually understood the principle and difference between the central version control system and distributed version control system (Git) from only knowing that Git is used to manage code at the beginning. From basic add, commit, pull, and push operations to stash, merge, and reset operations, it is very convenient. Thanks to a deep understanding of the principle of Git, we can get to the topic directly. Long warning ahead…
Start by understanding version control
The so-called version control is to keep the modification history in the process of file modification, and can easily undo (just like the undo operation of text editing, but version control will be much more complicated) the previous modification of the file. There are three core elements of a version control system: version control (the most basic functionality), active commit (commit history), and remote repository (collaborative development).
Central Version Control System (VCS)
A working model
The lead engineer frames the project
Create a remote repository on the company server and commit the code
Others pull code and develop in parallel
Each person is independently responsible for a feature and develops and completes the submission code
Someone else is always pulling code and keeping it in sync
Distributed Version Control System (DVCS)
The difference between distributed and central is that in addition to the distributed remote repository, each member of the team has a local repository on his or her own machine. Each member can submit code, view version, switch branches and other operations on his or her own machine without completely relying on the network environment. A working model
The lead engineer builds the project framework and delivers the code to the local repository
Create a remote repository on the company server and push the commit of 1 to the remote repository
Others clone all the contents of the remote repository locally, own their own local repository, and start parallel development
Each person is individually responsible for a feature, and each small change can be committed locally (since local commits do not need to be uploaded to a remote repository immediately, each commit need not be a complete feature, but can be a step or block in a feature)
Once the feature is developed, all commits related to this feature are pushed from the local to the remote repository
Every time someone pushes a new commit to a remote repository, someone else can choose to synchronize the commit to their own machine and merge it with their native code
Advantages and disadvantages of distributed version management systems:
advantages
Most operations are done locally, several times faster, regardless of network or physical location. You can submit code, view history, switch branches, and so on without a network
Distributed submission code, submission is more detailed for review
disadvantages
The first clone takes a long time
Local storage occupancy is higher than central systems
Dig deeper into git principles
Assuming you have git installed and have your code cloned to your local location, start with git Installation and Code copy guide.
Git’s most basic working model
First understand three basic concepts:
Workspace: the directory you see on your computer
Git repository: Your workspace has a hidden directory, git, which is not a workspace, but a local git repository where all your version information is stored
Temporary storage area: Stage, or index. Git /index. This is why the staging area is sometimes called an index.
A working model
The word “stage” in Git means “collect changes centrally for submission”. The staging area is a “staging area where changes to files can be made before they are committed”. Referred to as “Temporary Storage” and “Temporary Storage Area”. Passage Ten: Don’t you need to explain it further?
git log
git status
Basic model of team work
Working model 1. Based on the basic operations above, a colleague commits the code to his local repository and pushes it to remote repository 2. You pull the new commit from the remote repository to your local site using the pull command. This process allows you and your colleagues to collaborate simply: You write code, commit, push to the remote repository, and he pulls to his local site; He writes code, commits, pushes to the remote repository, and then you pull to your local repository. You come and I go, like a team. (But sometimes a push fails)
Why did it fail? A Git push overwrites a remote repository commit with a local repository commit. A push (if successful) will cause the remote commit to be erased if the remote repository contains a commit that does not exist locally. This result, of course, is not feasible, so Git checks for a push, and if this happens, the push will fail
Git pull (a combination of fetch and merge) merges the commit from the local repository with the commit from the remote repository and then pushes
Feature Shoot: The most popular workflow
Any new features or bug fixes will be written as a branch. Git origin -d git origin -d git origin -d git origin -d git origin
The nature of HEAD, branch, references, and push
HEAD: reference to the current commit
This is a reference that always automatically points to the current commit, so you can always use HEAD to manipulate the current commit,
Branch:
HEAD is a unique reference in Git; it is unique. In addition to HEAD, Git also has a reference called branch. In addition to pointing to a commit, a HEAD can also point to a branch. When pointing to a branch, the HEAD refers to the current commit via the branch. The HEAD moves with the branch:
Branch contains all the paths from the initial COMMIT to it, not just one path. And these paths are equal to each other.
Git branch name
The name of the git checkout
Git checkout -b name
Git branch -d name
The nature of citations
A reference is a string of characters. This string can be a commit SHA – 1 yd (example: c08de9a4d8771144cd23986f9f76c4ed729e69b0), can also be a branch (example: ref: refs/heads/feature3).
Git’s HEAD, branch, and other references are stored as text files in the local.git directory, and Git works by looking at the contents of these text files to determine who these so-called “references” refer to.
Push essence: Upload branch to a remote repository
The description in Git is that the commits in the branch path are deleted from clone or pull branches. The description in Git is The HEAD of the remote repository is not consistent with that of the local branch. The HEAD of the remote repository always points to the default branch (master). You can use git br-r to see the HEAD of a remote branch.
Start your Git operation tour
The merge:
A new commit is automatically generated by applying all the contents of the target commit path to the current commit, starting at the bifurcation point of the target commit and the current commit (i.e. the commit pointed to by HEAD).
git merge branch1
git merge --abort
Rebase: Resets the base point for the COMMIT sequence
Some people don’t like merge because after merge, commit history forks, and the structure of forks merging again can be confusing and difficult to manage for some. If you don’t want the commit history to fork, you can use rebase instead of merge.
Why merge rebase from Branch1 and then go back to master instead of rebase on master? As you can see from the figure, each commit after Rebase has the same content as before rebase, but is already a different commit (each commit has a unique flag). If rebase were executed directly from the master, it would look like this:
This causes the last two commits (3 and 4) on the master to be removed. If these two commits already exist in the remote repository, this will result in no push:
Therefore, to avoid conflicts with remote repositories, generally do not perform rebase operations from the master to other branches. Rebase between branches other than master (such as branch1 and branch2).
It is important to note that a merge is different from a merge, where rebase is performed on a COMMIT that needs to be rebase.
Stash: Temporarily stores changes to the working directory
The Stash directive allows you to keep the contents of your working directory in a single place at your local location. It can never be committed or deleted. Once you put it away, you can do your temporary work. Operation steps: Git stash save ‘note information’ : You can switch to other branches to do other things. (3) Git Stash pop pops the first stash (removed from the history stash). Or you can use git Stash apply to achieve the same effect (the stash still exists in the Stash list), and you can use the Git Stash list to view the stash history and return to the stash by adding the specified stash after apply. Note: Files not covered by track will be ignored by Git without stash. If you want to include stash, add the -u parameter.
Reflog: logs that reference records
You can view git reference records. If no parameter is specified, HEAD reference records are displayed by default. If the branch is accidentally dropped, you can use this command to view the reference record, and then use checkout to cut to the record and rebuild the branch.
Key points: Commits that are no longer referred to directly or indirectly are recovered by Git after a certain period of time, so reflog should be used to retrieve deleted branches in a timely manner or they may not be recovered due to commits that were recalled.
See what I changed
Log: Views submitted content
Git log –stat git show specify commit specifies file name. Git show specify commit specifies file name
Diff: View uncommitted content
Git diff — Staged shows the difference between staging areas and the last commit. In other words, git diff will show you the difference between the working directory and the staging area. In other words, git diff HEAD lets you see what you would add to the staging area if you added all the files now. Git diff HEAD shows the difference between the working directory and the last commit, and is the sum of the two. In other words, this command lets you see what you would commit if you now added everything and git commit. (Note, though, that untracked files that haven’t been recorded by Git (that is, files that have never been added, untracked files are not displayed.) Essentially, if you change HEAD to another commit, you can also display the difference between the current working directory and this commit.
What if the code you just submitted is incorrectly written?
Another commit that fixed a bug? You can, but there is a more elegant and simple solution: commit –amend. (1) Modify the problem (2) add the changes to the temporary storage (3) Use Git commit — Amend to commit the changes, and the results are as follows:
The error is not the latest submission but the second-to-last?
Using rebase -I (interactive Rebase) : Interactive rebase means that you can specify whether each commit in the rebase chain needs to be further modified before the rebase operation is performed. This allows you to perform an in-place rebase. Git rebase -i HEAD^^
Git has two offset symbols: ^ and ~. To offset a commit by the amount of ^, add one or more ^ signs after the commit. For example, master^ indicates the commit before the commit to which master points. HEAD^^ indicates the commit to which HEAD points. We can offset the commit back by the number following the ~ sign. For example, HEAD to 5 indicates that the number of commit points to by HEAD is five.
HEAD^ is the commit of HEAD one position back, as we said in the last video, remember?
Undo historical commits with interactive Rebase
The procedure is similar to that of changing the commit history. In the second step, change the commit that needs to be revoked to DROP.
Undo the commit with rebase –onto
Git rebase –onto HEAD^^ HEAD^ branch1 git rebase –onto HEAD^^ HEAD^ branch1 Start with the penultimate commit (the starting point is not included in the rebase sequence), end with Branch1, and rebase to the penultimate commit.
Error code already push?
Sometimes, code pushes to the remote repository only to discover that a COMMIT was written incorrectly. This problem can be dealt with in two cases:
Error content in its own branch
If something goes wrong with a branch you developed independently and it doesn’t affect anyone else, just change or delete the wrong commit using the same method described in the previous sections and then push it back. The remote repository contains absent commits that have been replaced or deleted locally. In this case, git push Origin -f is used to enforce the push.
The problem content has been merged into master
Git revert Commit It is very easy to revert a COMMIT with Git. If you want to undo a commit, add it to the list. Git revert HEAD^ adds a new commit that is the opposite of the penultimate commit and canceles it with the penultimate commit. After the revert is done, push a new COMMIT and the commit is revoked. The main difference from the undo method described above is that this change is only “reversed” and not lost in history. There are two commits in your history: the original commit and the reverse commit.
Reset: more than one submission can be revoked
Git reset –hard specifies commit The contents of your working directory will be reset to the exact same contents as the commit location. In other words, all your uncommitted changes will be erased. Git reset –soft Specifies that commit preserves the contents of the working directory and staging area when resetting the HEAD and branch, and puts the new differences caused by resetting the HEAD into staging. What is the “new difference made by resetting HEAD”? Here it is:
Git reset --mixed (or without arguments) specifies a commit
Checkout: checks out to specify a commit
To checkout a branch, you can specify a commit as an argument and move the HEAD to the specified commit. Reset differs from reset in that only the bound branch is moved; Git checkout — Detach from HEAD and branch and point directly to the current commit.
The last
I hope that my summary can bring you some help, but also hope to learn with you, grow together. Finally, thank you very much for your pamphlet, amway git Principle Detailed Explanation and Practical Guide, and look for the throwing line.
