切換 Git 分支,卻能同時在多個分支上工作,我是怎么做到的?

      網友投稿 945 2025-04-01

      背景

      上一篇文章 保持清潔的Git提交記錄,三招就夠了 ,大家看過后有私下留言說這是非常好用的功能,我突然想到工作中用到的另外一個 Git 功能那也是相當好用,必須全盤托出

      作為程序員的我們應該都有一個感受,一旦進入某個項目,從開發,到發布生產,到 hotfix,到后期維護,那基本都有你的份,正在開發某個 feature,老板突然跳出來說讓你做生產上的 hotfix 更是家常便飯,面對這種情況,使用 Git 的我們通常有兩種解決方案:

      草草提交未完成的 feature,然后切換分支到 hotfix

      git stash | git stash pop 暫存工作內容,然后再切換到 hotfix

      第二種方式較第一種還好很多,可是面對下面這些場景,stash 依舊不是很好的解決方案

      我們面對的場景

      正在 main 分支上跑長時間的測試,切換到 hotfix 或 feature, 測試就會中斷

      項目非常大,頻繁的切換索引,成本非常高

      有幾年前 release 的舊版本,設置和當前不一樣,IDE restructure 適配切換也會帶來很大的開銷

      切換分支,需要重新設置相應的環境變量,比如 dev/qa/prod

      需要切換到同事的代碼,幫助調試代碼復現問題

      不切換 Git 分支,卻能同時在多個分支上工作,我是怎么做到的?

      有的同學想到,git clone 多個 repo 不就可以了嗎?這是解決上述問題的一個方法,但背后同樣隱藏很多問題:

      多個 repo 的狀態是不好同步的,比如沒辦法快速 cherry-pick, 一個 repo checkout 的分支,另外一個 repo 需要重新 checkout

      git history/log 是重復的,當項目歷史非常長,.git 文件夾下的內容是非常占用磁盤空間的

      同一個項目,多個 repo,不易管理

      那如何做才能滿足這些特殊場景,又不出現這些上述這些問題呢?

      git-worktree

      其實,這是 Git 2015 年就開始支持的功能,卻很少有人知道它,git-worktree 的使用非常方便,在終端輸入:

      git?worktree?--help

      就可以快速看到幫助文檔說明:

      用簡單的話來解釋 git-worktree 的作用就是:

      僅需維護一個 repo,又可以同時在多個 branch 上工作,互不影響

      上面紅色框線命令有很多,我們常用的其實只有下面這四個:

      git?worktree?add?[-f]?[--detach]?[--checkout]?[--lock]?[-b?]??[]

      git?worktree?list?[--porcelain]

      git?worktree?remove?[-f]?

      git?worktree?prune?[-n]?[-v]?[--expire?]

      在展開說明之前,需要和大家普及兩個你可能忽視的 Git 知識點:

      默認情況下, git init 或 git clone 初始化的 repo,只有一個 worktree,叫做 main worktree

      在某一個目錄下使用 Git 命令,當前目錄下要么有 .git 文件夾;要么有 .git 文件,如果只有 .git 文件,里面的內容必須是指向 .git 文件夾的

      第二句話感覺挺繞的,下面用例子說明,就很容易明白了

      git worktree add

      當前項目目錄結構是這樣的(amend-crash-demo 是 repo 的 root):

      .

      └──?amend-crash-demo

      1?directory

      cd amend-crash-demo 運行命令 git worktree add ../feature/feature2

      ???amend-crash-demo?git:(main)?git?worktree?add?../feature/feature2

      Preparing?worktree?(new?branch?'feature2')

      HEAD?is?now?at?82b8711?add?main?file

      重新看目錄結構

      .

      ├──?amend-crash-demo

      └──?feature

      └──?feature2

      3?directories

      該命令默認會根據 HEAD 所在的 commit-ish (當然也可以指定 git log 中的任意一個 commit-ish) 創建一個名為 feature2 的分支,分支磁盤位置如上面結構所示

      cd ../feature/feature2/ 會發現,這個分支下并不存在 .git 文件夾,卻存在一個 .git 文件,打開文件,內容如下:

      gitdir: /Users/rgyb/Documents/projects/amend-crash-demo/.git/worktrees/feature2

      到這里,你再理解一下上面的知識點2,是不是就清晰許多了呢?

      接下來,你就可以在 feature2 分支上做一切你想做的內容了(add/commit/pull/push),和 main worktree 互不干擾

      一般情況下,項目組都有一定的分支命名規范,比如 feature/JIRAID-Title, hotfix/JIRAID-Title, 如果僅僅按照上面命令新建 worktree,分支名稱中的 / 會被當成文件目錄來處理

      git?worktree?add?../hotfix/hotfix/JIRA234-fix-naming

      運行完該命令,文件目錄結構是這樣的

      .

      ├──?amend-crash-demo

      ├──?feature

      │???└──?feature2

      └──?hotfix

      └──?hotfix

      └──?JIRA234-fix-naming

      6?directories

      很顯然這不是我們想要的,這時我們就需要 -b 參數的支持了,就像 git checkout -b 一樣

      執行命令:

      git?worktree?add?-b?"hotfix/JIRA234-fix-naming"?../hotfix/JIRA234-fix-naming

      再來看一下目錄結構

      .

      ├──?amend-crash-demo

      ├──?feature

      │???└──?feature2

      └──?hotfix

      ├──?JIRA234-fix-naming

      └──?hotfix

      └──?JIRA234-fix-naming

      7?directories

      進入 JIRA234-fix-naming 目錄,默認是在 hotfix/JIRA234-fix-naming 分支上

      worktree 建立起來很容易,不加管理,項目目錄結構肯定亂糟糟,這是我們不想看到的,所以我們需要清晰的知道某個 repo 都建立了哪些 worktree

      git worktree list

      所有的worktree 都在共用一個 repo,所以在任意一個 worktree 目錄下,都可以執行如下命令來查看 worktree 列表

      git?worktree?list

      執行完命令后,可以查看到我們上面創建的所有 worktree 信息, main worktree 也會顯示在此處

      /Users/rgyb/Documents/projects/amend-crash-demo????????????????????????82b8711?[main]

      /Users/rgyb/Documents/projects/chore/chore???????????????????????????????????8782898?(detached?HEAD)

      /Users/rgyb/Documents/projects/feature/feature2?????????????????????????????82b8711?[feature2]

      /Users/rgyb/Documents/projects/hotfix/hotfix/JIRA234-fix-naming?????82b8711?[JIRA234-fix-naming]

      /Users/rgyb/Documents/projects/hotfix/JIRA234-fix-naming??????????????82b8711?[hotfix/JIRA234-fix-naming]

      worktree 的工作做完了,也是要及時刪除的,否則也會浪費很多磁盤空間

      git worktree remove

      這個命令很簡單了,worktree 的名字叫什么,直接就 remove 什么就好了

      git?worktree?remove?hotfix/hotfix/JIRA234-fix-naming

      此時,分支名弄錯的那個 hotfix 就被刪掉了

      /Users/rgyb/Documents/projects/amend-crash-demo????????????????????????82b8711?[main]

      /Users/rgyb/Documents/projects/chore/chore???????????????????????????????????8782898?(detached?HEAD)

      /Users/rgyb/Documents/projects/feature/feature2?????????????????????????????82b8711?[feature2]

      /Users/rgyb/Documents/projects/hotfix/JIRA234-fix-naming??????????????82b8711?[hotfix/JIRA234-fix-naming]

      假設你創建一個 worktree,并在里面有改動,突然間這個worktree 又不需要了,此刻你按照上述命令是不能刪掉了,此時就需要 -f 參數來幫忙了

      git?worktree?remove?-f?hotfix/JIRA234-fix-naming

      刪除了 worktree,其實在 Git 的文件中,還有很多 administrative 文件是沒有用的,為了保持清潔,我們還需要進一步清理

      git worktree prune

      這個命令就是清潔的兜底操作,可以讓我們的工作始終保持整潔

      總結

      到這里,你應該理解,整個 git-worktree 的使用流程就是下面這四個命令:

      git?worktree?add

      git?worktree?list

      git?worktree?remove

      git?worktree?prune

      你也應該明白 git worktree 和 git clone 多個 repo 的區別了。只維護一個 repo,創建多個 worktree,操作間行云流水

      我的實踐:通常使用 git worktree,我會統一目錄結構,比如 feature 目錄下存放所有 feature 的worktree,hotfix 目錄下存放所有 hotfix 的 worktree,這樣整個磁盤目錄結構不至于因為創建多個 worktree 而變得混亂

      在磁盤管理上我有些強迫癥,理想情況下,某個 repo 的 worktree 最好放在這個 repo 的文件目錄里面,但這就會導致 Git track 新創建的 worktree 下的所有文件,為了避免 Git track worktree 的內容,來來回回修改 gitignore 文件肯定是不合適的,下一節我會介紹一個更好的辦法

      靈魂追問

      可以刪除 main worktree 嗎?為什么

      反復創建和刪除worktree, repo/.git/wortree 目錄的變化你能理解嗎?

      花了倆小時整了張思維導圖,不得不說思維導圖真是好東西

      2021-11-24

      Spring Security動態權限越來越容易了

      2021-11-22

      Spring Boot 2.6正式發布,Spring Boot 2.4停止維護

      2021-11-19

      Git

      版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。

      版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。

      上一篇:Ubuntu安裝CANN相關依賴
      下一篇:零代碼產品,革命性的創造工具還是過度依賴的隱患
      相關文章
      亚洲精品无码av人在线观看| 亚洲精品国产精品乱码不99| 亚洲精品亚洲人成在线观看| www国产亚洲精品久久久| 亚洲jizzjizz在线播放久| 亚洲黄色网址大全| 亚洲AV日韩AV天堂久久| 亚洲国产精品久久久久婷婷软件| 欧洲亚洲国产清在高| 国产亚洲人成网站在线观看| 伊人久久综在合线亚洲91| 亚洲色婷婷六月亚洲婷婷6月| 91麻豆国产自产在线观看亚洲| 丝袜熟女国偷自产中文字幕亚洲| 最新亚洲成av人免费看| 国产亚洲精品无码专区| 亚洲乱码精品久久久久..| 亚洲国产精品一区第二页| 国产亚洲精品资源在线26u| 久久久久亚洲AV片无码| 久久亚洲国产精品| 久久精品国产亚洲av麻豆小说| 亚洲系列国产精品制服丝袜第| 亚洲成A∨人片在线观看无码| 亚洲一区二区三区无码国产| 亚洲一区二区三区在线| 亚洲另类自拍丝袜第五页| WWW国产亚洲精品久久麻豆| 一区二区三区亚洲视频| 亚洲中文字幕无码久久综合网| 亚洲成av人片在线观看无码不卡| 亚洲国产精品久久久久婷婷老年 | 亚洲国产精品高清久久久| 久久久久久亚洲av成人无码国产| 亚洲国产精品无码一线岛国| 亚洲国产精品久久久久网站| 久久久久亚洲AV片无码下载蜜桃| 亚洲另类视频在线观看| 亚洲欧洲无码AV不卡在线| 亚洲国产一区二区视频网站| 亚洲国产精品高清久久久|