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

This article is about how to use the Git work tree to freely experiment with your code. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

Get the right to try freely and safely have a new, linked clone repository if your experiment goes wrong.

Part of the design of Git is for experiments. If you know that your work will be safely tracked and that there is a safe state in the event of a serious error, you will not be afraid to try new ideas. But part of the price of innovation is that you are likely to make a mess in the process. Files will be renamed, moved, deleted, changed, cut to pieces, new files will be introduced, temporary files you don't plan to track will have a place in your working directory, and so on.

In short, your workspace has become a house of cards, in "almost done!" And "Oh, no, what have I done?" There is a precarious balance. So what do you do when you need to restore the warehouse to a known state in the afternoon in order to get some real work done? I immediately thought of the two classic commands git branch and git stash, but neither command is used to deal with untracked files, and file path changes and other major changes can be confusing, they can only stash work for later use. The answer to this requirement is the Git work tree.

What is the Git working tree

The Git work tree worktree is a linked copy of the Git repository that allows you to check out multiple branches at the same time. The path of the work tree is separate from the main work copy, and it can be in different states and branches. The advantage of creating a new work tree in Git is that you can make changes that are not related to the current task, commit changes, and then merge them later without interfering with the current work environment.

A typical example is found directly in the git-worktree manual: when you are working on an exciting new feature for a project, your project manager tells you that there is an urgent fix. The problem is that your work warehouse (your "work tree") is in a state of chaos because you are developing an important new feature. You don't want to "secretly" fix it in the current sprint, and you don't want to save the changes temporarily to create a new branch for the fix. Instead, you decide to create a new working tree so that you can fix it there:

$git branch | tee* devtrunk$ git worktree add-b hotfix ~ / code/hotfix trunkPreparing.. / hotfix (identifier hotfix) HEAD is now at 62a2daf commit

In your code directory, you now have a new directory called hotfix, which is a Git working tree connected to your main project repository, and its HEAD stops on a branch called trunk. Now you can treat this work tree as your main work area. You can change the directory into it, make an emergency fix, submit, and eventually delete the working tree:

$cd ~ / code/hotfix$ sed-I's message the urgent hotfix 'hello.txt$ git commit-- all-- the urgent hotfix'

Once you have finished your urgent work, you can return to your previous task. You can control when your hot fixes are integrated into the main project. For example, you can push changes directly from its work tree to the project's remote repository:

$git push origin HEAD$ cd ~ / code/myproject

Or you can archive the work tree as a TAR or ZIP file:

$cd ~ / code/myproject$ git archive-format tar-output hotfix.tar master

Or you can get local changes from a separate work tree:

$git worktree list/home/seth/code/myproject 15fca84 [dev] / home/seth/code/hotfix 09e585d [master]

From there, you can merge your changes using any strategy that works best for you and your team.

List the active work tree

You can use the git worktree list command to get a list of work trees and view the branches checked out from each work tree:

$git worktree list/home/seth/code/myproject 15fca84 [dev] / home/seth/code/hotfix 09e585d [master]

You can use this feature in any work tree. Working trees are always connected (unless you move them manually, destroying Git's ability to locate the working tree, thus breaking the connection).

Mobile work tree

Git tracks the location and status of the working tree in the project .git directory:

$cat ~ / code/myproject/.git/worktrees/hotfix/gitdir/home/seth/code/hotfix/.git

If you need to relocate a working tree, you must use git worktree move;. Otherwise, when Git attempts to update the status of the working tree, it will fail:

$mkdir ~ / Temp$ git worktree move hotfix ~ / Temp$ git worktree list/home/seth/code/myproject 15fca84 [dev] / home/seth/Temp/hotfix 09e585d [master] remove the working tree

When you have finished your work, you can delete it with the remove subcommand:

$git worktree remove hotfix$ git worktree list/home/seth/code/myproject 15fca84 [dev]

To make sure your .git directory is clean, use the prune subcommand after deleting the working tree:

$git worktree remove prune Thank you for your reading! This is the end of this article on "how to use the Git work tree to experiment freely on your code". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it for more people to see!

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.