git merge, git rebase, git reset, git revert, git fetch, git pull, git reflog... Do you know what tasks these git commands perform? If you are still confused, don’t miss this article. In this article, Lydia Hallie, a 21-year-old software consultant who is familiar with JavaScript, TypeScript, GraphQL, Serverless, AWS, Docker and Golang, intuitively introduces the working process of these commonly used git commands in the form of animations, ensuring that you will never forget them.
Although Git is a very powerful tool, if I say that Git is a nightmare to use, most people will also Agree with my statement. I find it very helpful when working with Git to visualize it in my head: when I execute a specific command, how will these branches interact and how will it affect the history? Why do my coworkers cry when I perform a hard reboot on master, force push to the original branch, and rimraf our .git folder? I thought creating visual examples of some of the most commonly used and useful Git commands would be a perfect use case! Many of the commands I'll describe below have optional parameters - you can use these parameters to change the behavior of the corresponding command. And my example will only cover the default behavior of the command and won't add (or add too much) optional configuration! ##It is very convenient to have multiple branches This will isolate different new changes from each other and ensure that you don't accidentally push unsanctioned or broken code changes to production code. But once these changes are approved, we need to deploy them to our production branch! One way to incorporate changes from one branch into another is to perform a git merge. Git can perform two types of merges: fast-forward and no-fast-forward. You may not be able to tell the difference now, but let’s take a look at the differences in a moment. at Fast-forward merge can be performed when the current branch has no additional commits compared to the branch we want to merge. Git is lazy and will try the simplest option first: fast-forward! This type of merge does not create new commits, but instead merges the commits on the branch we are merging directly into the current branch. Perfect! Now, all the changes we made on the dev branch are merged into the master branch. So what does no-fast-forward mean? ##It would be nice if your current branch didn't have any commits compared to the branch you want to merge into, but unfortunately that's rarely the case! If we commit changes on the current branch that are not in the branch we want to merge, then git will perform a no-fast-forward merge. When merging using no-fast-forward, Git will create a new merging commit on the currently active branch. The parent commit of this commit points to this active branch and also points to the branch we want to merge! No big deal, perfect merge! Now, all the changes we made on the dev branch are merged into the master branch. Although Git is pretty good at deciding how to merge branches and add changes to files, it doesn't always make decisions entirely on its own. When the two branches we want to merge have different modifications on the same line of code in the same file, or one branch deletes a file and the other branch modifies the file, Git doesn't know what to choose. In this case, Git will ask you which option you want to keep? Assume that in both branches, we edit the first line of README.md. If we want to merge dev into master, a merge conflict will occur: You want the title Is it Hello! or Hey!?
When trying to merge these branches, Git will show you where the conflicts occur. We can manually remove the changes we don't want to keep, save the changes, add the modified file again, and commit the changes. Finish! Although merge conflicts are often annoying, they make sense: Git shouldn't have to guess at which changes we want to keep.
We just watched You can apply changes from one branch to another branch by executing git merge. Another way to incorporate changes from one branch into another is to perform a git rebase. git rebase will copy the commits of the current branch to the specified branch. Perfect, now we have all the changes on the master branch on the dev branch. There is one major difference between rebasing and merging: Git does not try to determine which files to keep or not. The branch we rebase always contains the most recent changes we want to keep! This way we don't run into any merge conflicts and keep a nice, linear Git history. The above example shows rebasing on the master branch. However, in larger projects, you usually don't need to do this. git rebase modifies the project's history when creating new hashes for copied commits. If you are developing a feature branch and the master branch has been updated, rebasing is useful. You can get all updates on your branch, which prevents merge conflicts in the future. ## We can modify them before performing the rebase for the commit! We can use interactive rebasing to accomplish this task. Interactive rebasing is useful when you are on the branch you are currently developing and want to modify certain commits. On the commit we are rebasing, we can perform the following 6 actions:
reword: Modify the submission information;
edit: Modify this submission;
squash: merge the submission into the previous submission;
fixup: merge the submission into the previous submission , do not keep log messages for that commit;
exec: Run the command we want to rebase on each commit;
drop: Remove the commit.
great! This way we have full control over our commits. If you want to remove a commit, just drop it.
#If you want to merge multiple commits Together to get a clear commit history, that's no problem!
Interactive rebasing gives you a lot of control when rebasing, even over the currently active branch.
When we don’t want the previously submitted modifications, we will Use this command. Maybe this is a WIP commit or maybe it's a commit that introduced a bug, in which case you need to perform a git reset.
git reset allows us to no longer use the files on the current desktop, allowing us to control where HEAD should point.
Soft reset
Soft reset will move HEAD to the specified commit (or compared to HEAD index of the commit) without removing changes added after that commit!
Suppose we don't want to keep commit 9e78i, which adds a style.css file, and we don't want to keep commit 035cc, which adds an index.js file. However, we do want to keep the newly added style.css and index.js files! This is a perfect use case for soft reset.
After entering git status, you will see that we can still access all changes made on previous commits. This is great, it means we can fix the contents of these files and resubmit them later!
##Hard reset
Sometimes we don’t want to Preserve changes introduced by a specific commit. Unlike a soft reset, we should never need to access them again. Git should simply reset the overall state directly to the state before a specific commit: this even includes changes you made in the working directory and on staging files.
Git discarded the changes introduced by 9e78i and 035cc and reset the state to the state of ec5be.
Another way to undo changes is to perform git revert. By performing a revert operation on a specific commit, we create a new commit containing the reverted changes.
Suppose ec5be adds an index.js file. But then we discovered that we no longer needed the changes introduced by this commit. Then restore the ec5be submission!
Perfect! Commit 9e78i reverts the changes introduced by commit ec5be . git revert is useful when undoing a specific commit without modifying the branch's history. When a specific branch contains a certain commit that our active branch requires, we perform a cherry-pick on that commit! When cherry-picking a commit, we create a new commit on the active branch that contains the changes introduced by the picked commit. Suppose commit 76d12 on the dev branch adds a change to the index.js file, and we want to integrate it into the master branch. We don't want the entire dev branch, just this commit! ##The master branch now contains the changes introduced in 76d12.
If you have a remote Git branch, such as a branch on GitHub, you can use retrieval when the remote branch contains commits that the current branch does not have. Like when another branch is merged or your colleague pushes a quick fix.
By executing git fetch on this remote branch, we can get these changes locally. This does not affect your local branch in any way: fetch simply downloads the new data.
#Now we can see that since the last All modifications since push are included. The new data is now local and we can decide what to do with it.
Although git fetch can be used to fetch Remote information for a certain branch, but we can also perform git pull. git pull is actually two commands combined into one: git fetch and git merge. When we pull changes from the source, we first retrieve all the data like git fetch, and then the latest changes are automatically merged into the local branch.
Great, we are now perfectly in sync with the remote branch and have all the latest changes!
Everyone makes mistakes, but it’s okay to make mistakes! Sometimes you may feel like you've completely corrupted your git repo, making you want to delete it entirely.
git reflog is a very useful command that can display the log of all actions that have been performed. This includes merges, resets, reverts, basically any changes you make to your branch.
#If you make a mistake, you can easily redo it by resetting HEAD based on the information provided by the reflog!
Suppose we don't actually need to merge the original branch. When we execute the git reflog command, we can see that the status of this repo was at HEAD@{1} before the merge. Then we perform a git reset and redirect HEAD to the location of HEAD@{1}.
#We can see that the latest actions have been is pushed to the reflog. The above is the detailed content of Dozens of animated pictures tell you how Git works. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
