Git cheats: Version rollback in Git

Git cheats: Version rollback in Git
GuideIn this article, you will learn how to view the historical version of the project, how to roll back the version, and how to create a Git branch so that you can try it without any problems. Come and try it.

In the history of your Git project, your position is like a clip in the rock album, determined by a HEAD mark (such as the playback HEAD of a tape recorder or recording player ). To move the HEAD before and after your Git time line, you need to use the git checkout command.

git checkout

The command can be used in two ways. The most common purpose is to restore a file from a previous commit. You can also reverse the entire tape to another branch.

Back to 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 a place, add and submit it, and then we find that it still needs to make some final adjustments. Finally, this file is totally out of sight, to restore it to the final state of integrity, use git checkout to restore it from the final commit (I .e. HEAD:

$ git checkout HEAD filename

If you happen to have submitted an incorrect version, you need to retrieve 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 are restored to your current location. (You can use the git status Command to view your current status at any time.) because this file has changed, you need to add this file and submit it again:

$ 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 fixed the tape and fixed the bad part, so you need to record it correctly.

Restore a file

Another way to restore files is to roll back the entire Git project. Here we use the branch idea. This is another alternative. If you want to return to history submission, You need to roll back the Git HEAD to the previous version. This example will return to the initial submission:

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

When you roll back the tape in this way, if you press the recording key to start again, the previous work will be lost. Git assumes that you do not want to do this by default, So separating the HEAD from the project allows you to work as needed without occasional record impact on subsequent work.

If you want to see previous versions and try different methods, you can create a new branch in a safe way. You can imagine this process as trying different versions of the same song or creating a sound mixing. The original version still exists. Close the Branch for 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 workspace in front of you. Prepare for work.

You can also do the same without changing the timeline. You may want to do this, but switch to a temporary workspace just to try some crazy ideas. This is completely acceptable at work. Please refer:

$ 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 complete some strange ideas. Once you finish, you can retain your changes, discard them, and switch back to your main branch.

To give up on your idea, switch to your main branch and pretend that the new branch does not exist:

$ git checkout master

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

$ git checkout master$ git merge crazy_idea

Git Branch functions are very powerful. 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, it can be submitted and merged to the master branch. Git is flexible, so there is no "correct" or "wrong" method (even a master branch can be separated from its remote repository ), however, branches are easy to separate tasks and submit contributions. Don't be too excited. You can have many Git branches as you wish. Completely free.

Remote collaboration

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

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

When you clone a repository in read/write mode, the cloned repository inherits from the remote repository called origin. You can check the remote repository of your clone Repository:

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

An origin remote database is very useful because it has the remote backup function and allows others to work on this project. If cloning does not inherit the origin remote database, alternatively, you can run the git remote command:

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

If you modify files and want to send them to the origin remote database with read and write permissions, use git push. For the first push change, branch information must also be sent. It is a good practice not to work directly on the master branch unless you are required 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, you can choose not to use the-u option for each push:

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

Merge Branch

When you work in a Git repository, You can merge any test branch to the master branch. When a team works together, you may want to check their changes before merging them into the main branch:

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

If you are using GitHub or GitLab and something similar, this process is different. However, cloning a project and using it as your own repository are similar. You can work locally and submit the changes to your GitHub or GitLab account, because these libraries are yours, if you want your cloned repository to accept your changes, you need to create a pull request that uses the Web Service backend to send patches to the real owner, and allow them to review and pull your changes.

Cloning a project is usually completed on the Web server. It is similar to managing the project by using Git commands, and even the push process. Then it returns to the Web service to open a pull request, and the work is complete.

From: https://linux.cn: 443/article-7677-1.html

Address: http://www.linuxprobe.com/git-version.html