Ajar anda cara bekerja pada berbilang cawangan pada masa yang sama tanpa menukar cawangan Git (contoh terperinci)

Artikel ini membawakan anda pengetahuan yang berkaitan tentang Git cawangan terutamanya memperkenalkan isu berkaitan tentang cara bekerja pada berbilang cawangan tanpa menukar cawangan.

Apabila anda sedang membangunkan ciri tertentu, bos tiba-tiba melompat keluar dan meminta anda melakukan perbaikan terbaru untuk pengeluaran Ia adalah perkara biasa , kami yang menggunakan Git Biasanya terdapat dua penyelesaian:

1. Serahkan ciri yang belum selesai dengan tergesa-gesa, dan kemudian tukar cawangan kepada hotfix

2. git stash | git stash pop untuk mementaskan kandungan kerja , dan kemudian beralih kepada perbaikan terbaru

Kaedah kedua jauh lebih baik daripada yang pertama, tetapi dalam menghadapi senario berikut, simpanan masih bukan penyelesaian yang baik

Senario yang kami hadapi

1. Ujian jangka panjang sedang dijalankan pada cawangan utama Jika anda beralih kepada perbaikan terbaru atau ciri, ujian akan terganggu

2. Projek ini sangat besar, dan penukaran indeks yang kerap sangat mahal

3. Versi lama yang dikeluarkan beberapa tahun lalu, tetapan adalah berbeza daripada yang semasa, pensuisan penyesuaian penstrukturan semula IDE Ia juga akan membawa banyak overhed

4. Penukaran cawangan memerlukan penetapan semula pembolehubah persekitaran yang sepadan, seperti dev/qa/prod

5. diperlukan Tukar kepada kod rakan sekerja untuk membantu nyahpepijat masalah berulang kod

Sesetengah pelajar berpendapat bahawa tidak cukup untuk mengklonkan berbilang repo ? Ini adalah cara untuk menyelesaikan masalah di atas, tetapi terdapat juga banyak masalah yang tersembunyi di sebaliknya:

1. Status beberapa repo tidak mudah untuk disegerakkan, contohnya, tidak ada cara untuk memilih cepat, cawangan daftar keluar repo, repo lain perlu diperiksa semula

2. sejarah/log git diulangi Apabila sejarah projek sangat panjang, kandungan di bawah .git folder mengambil banyak ruang cakera

3. Projek yang sama, berbilang repo, sukar diurus

Jadi bagaimana kita boleh memenuhi senario istimewa ini tanpa masalah di atas?

git-worktree

Sebenarnya, ini ialah ciri yang telah disokong oleh Git sejak 2015, tetapi hanya sedikit orang yang mengetahui tentangnya. Input terminal:

git worktree --help

dan anda boleh melihat penerangan dokumen bantuan dengan cepat:

Untuk menerangkan fungsi git-worktree dalam perkataan mudah:

Anda hanya perlu mengekalkan satu repo dan anda boleh bekerja pada berbilang cawangan pada masa yang sama tanpa menjejaskan satu sama lain

Terdapat banyak arahan yang digariskan dalam warna merah di atas, tetapi satu-satunya yang biasa kami gunakan ialah yang berikut Empat:

git worktree add [-f] [--detach] [--checkout] [--lock] [-b <new-branch>] <path> [<commit-ish>]
 git worktree list [--porcelain]
 git worktree remove [-f] <worktree>
 git worktree prune [-n] [-v] [--expire <expire>]

Sebelum memulakan penjelasan, kami perlu mempopularkan dua mata pengetahuan Git yang mungkin anda terlepas pandang:

1. Secara lalai, git init Atau git clone repo yang dimulakan, hanya terdapat satu worktree, dipanggil main worktree

2. Gunakan arahan Git dalam direktori tertentu, atau ada folder .git dalam direktori semasa; Sama ada terdapat fail .git Jika hanya terdapat fail .git, kandungannya mestilah .git

menunjuk ke <🎜. > folder. Ayat kedua terasa agak mengelirukan Mari kita gunakan satu contoh Mudah untuk memahami penjelasan

Jika anda sedang belajar Spring Cloud, saya cadangkan tutorial percuma yang telah bersiri selama bertahun-tahun. terus dikemas kini: https://blog.didispace.com/spring-cloud-learning /

git worktree add

Struktur direktori projek semasa adalah seperti ini (

ialah akar repo): amend-crash-demo

.
└── 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

Semak struktur direktori

.
├── amend-crash-demo
└── feature
    └── feature2

3 directories

Arahan ini secara lalai akan mencipta cawangan bernama feature2 berdasarkan commit-ish di mana HEAD terletak (sudah tentu anda juga boleh menentukan sebarang commit-ish dalam log git), cakera cawangan Lokasi adalah seperti yang ditunjukkan dalam struktur di atas

Anda akan mendapati bahawa cd ../feature/feature2/ folder tidak wujud di bawah cawangan ini, tetapi terdapat fail .git Buka fail dan kandungannya adalah seperti berikut: .git

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

Pada ketika ini, jika anda memahami perkara 2 pengetahuan di atas. sekali lagi, adakah ia akan menjadi lebih jelas?

Seterusnya, anda boleh melakukan apa sahaja yang anda mahu pada cawangan feature2 (tambah/komit/tarik/tolak) tanpa mengganggu pokok kerja utama

一般情况下，项目组都有一定的分支命名规范，比如 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 的工作做完了，也是要及时删除的，否则也会浪费很多磁盘空间

另外，如果您正在学习Spring Cloud，推荐一个连载多年还在继续更新的免费教程：https://blog.didispace.com/spring-cloud-learning/

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 文件肯定是不合适的！

那么如何解决呢？点击下方卡片，关注“日拱一兵”，正在连载Git的高级技巧！

灵魂追问

1. 可以删除 main worktree 吗？为什么

2. 反复创建和删除worktree， repo/.git/wortree 目录的变化你能理解吗？

推荐学习：《Git教程》

Atas ialah kandungan terperinci Ajar anda cara bekerja pada berbilang cawangan pada masa yang sama tanpa menukar cawangan Git (contoh terperinci). Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!