Shulou(Shulou.com)06/01 Report--

This article mainly introduces the relevant knowledge of "how to achieve version fallback in Git". The editor shows you the operation process through an actual case. The method of operation is simple and fast, and it is practical. I hope this article "how to achieve version fallback in Git" can help you solve the problem.

In this actual work, we may need to use the version fallback, the so-called version fallback, similar to the undo function, that is, we have been talking about Ctrl + Z Dafa, if we find that there is too much bug in the newly developed version, and we need to roll back a stable version or the previous version, we need to use the version fallback function.

In the history of your Git project, your position is like a segment of a rock album, determined by a tag called HEAD (such as the head of a tape recorder or recording player). To move HEAD back and forth on your Git timeline, use the git checkout command.

Git checkout

Commands can be used in two ways. The most common use is to recover files from a previous submission, or you can rewind the entire tape and switch to another branch.

Fallback timeline

When you realize that a good file has been completely messed up by you. We have all done this: we put the file in one place, add it and submit it, and then we find that it needs to make some final adjustments, and finally the file has been changed beyond recognition, to restore it to its final intact state, using git checkout to recover from the final submission (that is, HEAD):

$git checkout HEAD filename

If you happen to submit the wrong version, you need to find the earlier version, use git log to view your earlier submission, and then retrieve it from the appropriate submission:

$git log-oneline79a4e5f bad takef449007 The second commit55df4c2 My great project, first commit.$ git checkout 55df4c2 filename

Now, the previous files have been restored to your current location. (you can check your current status with the git status command at any time.) because the file has changed, you need to add the file before submitting:

$git add filename$ git commit-m'restoring filename from first commit.'

Use git log to verify what you submitted:

Git log-- onelined512580 restoring filename from first commit79a4e5f bad takef449007 The second commit55df4c2 My great project, first commit.

In essence, you have rewound the tape and fixed the bad place, so you need to re-record the correct one.

Restore a file

Another way to recover files is to roll back the entire Git project. The idea of branching is used here, which is another alternative. If you want to go back to the history submission, you have to fall back to the previous version of Git HEAD. This example goes back to the original submission:

$git log-onelined512580 restoring filename from first commit79a4e5f bad takef449007 The second commit55df4c2 My great project, first commit.$ git checkout 55df4c2

When you rewind the tape in this way, if you press the recording key to start again, you will lose your previous job. Git assumes by default that you don't want to do this, so separating HEAD from the project allows you to work as needed without affecting later work because of occasional records.

If you want to look at the previous version, want to do it again or try a different approach, then the safer way is to create a new branch. Think of this process as trying different versions of the same song, or creating a remix. The original still exists, so close that branch and do the version you want.

Just like recording a blank tape, point your Git HEAD to a new branch:

$git checkout-b remixSwitched to a new branch 'remix'

Now that you have switched to another branch, there is an alternative clean work area in front of you, so get ready to get to work.

You can also do the same thing without changing the timeline. You may want to do this, but switching to a temporary workspace is just to try some crazy ideas. This is completely acceptable at work, please take a look:

$git statusOn branch masternothing to commit, working directory clean$ git checkout-b crazy_ideaSwitched to a new branch 'crazy_idea'

Now you have a clean workspace where you can accomplish some strange ideas. Once you are done, you can keep your changes, or discard them, and switch back to your main branch.

To give up your idea, switch to your main branch and pretend that the new branch doesn't exist:

$git checkout master

To continue using your crazy ideas, you need to pull them back to the main branch, switch to the main branch, and merge the new branch into the main branch:

$git checkout master$ git merge crazy_idea

The branches of git are so powerful that it is common for developers to create a new branch immediately after cloning the repository; in this way, all their work is on their own branch and can be committed and merged into the main branch. Git is flexible, so there is no "right" or "wrong" way (even a main branch can be separated from the remote repository to which it belongs), but branches are easy to separate tasks and commit contributions. Don't get too excited, you can have as many Git branches as you want. Completely free.

Remote collaboration

So far you have maintained a Git warehouse in your comfortable and private home, but how do you work with others?

There are several different ways to set up Git so that multiple people can work on the same project at the same time, so first we have to clone the warehouse, you may have cloned a warehouse from someone's Git server or GitHub home page, or on shared storage on the LAN, the only difference between working under a private warehouse and a shared warehouse is that you need to push your changes to someone else's warehouse. We call the work warehouse a local warehouse and other warehouses as remote warehouses.

When you clone a repository in a read-write manner, the cloned repository inherits from a remote library called origin. You can take a look at the remote warehouse of your clone warehouse:

$git remote-- verboseorigin seth@example.com:~/myproject.Git (fetch) origin seth@example.com:~/myproject.Git (push)

Having an origin remote library is very useful because it has remote backup capabilities and allows others to work on the project. If the clone does not inherit the origin remote library, or if you choose to add it later, you can use the git remote command:

$git remote add seth@example.com:~/myproject.Git

If you modify the files, you want to send them to the origin remote library with read and write access, using git push. The first time you push a change, you must also send branch information. It is a good idea not to work directly on the main branch unless you are asked to do so:

$git checkout-b seth-dev$ git add exciting-new-file.txt$ git commit-m'first push to remote'$ git push-u origin HEAD

It will push your current location (HEAD) and its existing branches to the remote. After one push, the-u option can not be used for each subsequent push:

$git add another-file.txt$ git commit-m 'another push to remote'$ git push origin HEAD merge branches

When you are working in a Git repository, you can merge any test branch into the main branch. When working as a team, you may want to check for their changes before merging them into the main branch:

$git checkout contributor$ git pull$ less blah.txt # check for changed files $git checkout master$ git merge contributor

If you are using GitHub or GitLab or something like that, the process is different. But cloning the project and using it as your own repository are similar. You can work locally and submit changes to your GitHub or GitLab account without anyone else's permission, because these libraries are your own, and if you want your cloned repository to accept your changes, you need to create a pull request that uses the back end of the Web service to send patches to real owners and allows them to review and pull your changes.

Cloning a project is usually done on the Web server, which is similar to using the Git command to manage the project, even the push process. It then returns to the Web service to open a pull request and the work is done.

This is the end of the introduction on "how to implement version fallback in Git". Thank you for reading. If you want to know more about the industry, you can follow the industry information channel. The editor will update different knowledge points for you every day.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.