Dapatkan pemahaman yang mendalam tentang pelbagai aliran kerja Git

Artikel ini akan memperkenalkan anda kepada Git, memperkenalkan pengetahuan asas git, dan pelbagai aliran kerja berdasarkan git saya harap ia akan membantu anda!

Melalui artikel ini anda boleh belajar:

• Asal usul git
• Pengetahuan asas git
• Kaedah asas proses gitflow
• Berbilang aliran kerja berdasarkan git

Sebelum bercakap tentang Git Flow, mari kita bincangkan perkara lain dahulu

• Apakah versi?
  Edisi merujuk kepada edisi pada masa cetakan, dan edisi ialah buku bercetak ialah istilah yang digunakan untuk menerangkan pelbagai bentuk, keadaan atau kandungan perkara yang sama yang berbeza antara satu sama lain.
  Dalam erti kata lain, selagi apa-apa dibezakan, ia akan melibatkan konsep versi Walau bagaimanapun, versi yang kita bicarakan di sini, termasuk perkara yang akan kita bincangkan nanti, semuanya harus menjadi versi yang bermakna. Xiao Ming 1 Januari Dari 1 Februari hingga 31 Januari, dokumen perancangan telah disemak setiap hari Pada 1 Februari, Parti A Xiao Ming berkata bahawa versi sebelumnya adalah lebih baik pada masa ini, untuk Xiao Ming, apakah versi sebelumnya? Mungkin ia adalah rancangan terakhir yang Xiao Ming hantar ke Parti A, atau mungkin ia adalah rancangan terakhir yang Parti A katakan okey, tetapi Xiao Ming mungkin tidak ingat tarikh tertentu rancangan itu disemak kepada Parti A.

• Apakah kawalan versi biasa?
  Cara menyalin fail dibezakan mengikut nama, fungsi buat asal/majukan editor ini, dan penggunaan alatan profesional seperti svn, git, dll. semuanya tergolong dalam kategori kawalan versi Kawalan versi berbeza mempunyai kegunaan yang berbeza , seperti editor teks Tarik, anda boleh membuat asal pengubahsuaian ini dengan mudah, seperti menyalin fail, yang boleh membenarkan fail baharu dan lama wujud pada masa yang sama untuk perbandingan mudah, tetapi kaedah ini terlalu mudah, dan proses perantaraan adalah perkara sementara , yang tidak mencukupi untuk berfungsi sebagai rujukan sejarah pengubahsuaian atau Anggap ia sebagai versi lengkap Untuk ini, beberapa alat profesional diperlukan, seperti sistem pengurusan versi terpusat SVN, CVS, sistem pengurusan versi teragih BitKeeper, Git, dsb.

• Latar belakang pembangunan Git

  Seperti banyak perkara hebat dalam hidup, Git dilahirkan dalam era perselisihan dan inovasi yang hebat. Projek sumber terbuka kernel Linux mempunyai bilangan peserta yang besar. Sebilangan besar kerja penyelenggaraan kernel Linux dibelanjakan untuk tugas yang membosankan untuk menghantar tampalan dan menyimpan arkib (1991-2002). Menjelang 2002, seluruh pasukan projek mula menggunakan BitKeeper, sistem kawalan versi teragih proprietari, untuk mengurus dan mengekalkan kod.
  Menjelang 2005, perkongsian antara syarikat komersil yang membangunkan BitKeeper dan komuniti sumber terbuka kernel Linux telah berakhir, dan mereka mengambil semula hak komuniti kernel Linux untuk menggunakan BitKeeper secara percuma. Ini memaksa komuniti sumber terbuka Linux (terutamanya pencipta Linux Linus Torvalds) untuk membangunkan sistem versi mereka sendiri berdasarkan pengajaran yang dipelajari daripada menggunakan BitKeeper. Mereka menetapkan beberapa matlamat untuk sistem baharu:

  • Kelajuan
  • Reka bentuk ringkas
  • Sokongan kukuh untuk model pembangunan bukan linear (membenarkan beribu-ribu Cawangan pembangunan selari)
  • Diedarkan sepenuhnya
  • Keupayaan untuk mengurus projek berskala ultra-besar dengan cekap seperti kernel Linux (kelajuan dan volum data) Sejak kelahirannya pada tahun 2005, Git telah matang dan matang, menjadi sangat mesra pengguna sambil mengekalkan matlamat yang ditetapkan pada awalnya. Ia pantas, bagus untuk menguruskan projek besar, dan mempunyai sistem pengurusan cawangan bukan linear yang luar biasa (lihat cawangan Git).

• Pada tahun 1991, Linux membangunkan projek sumber terbuka sistem linux Fail sumber dihantar dengan tampalan melalui e-mel untuk penulisan dan pembangunan, dan Linux sendiri bergabung mereka secara manual;

• Pada tahun 2002, BitKeeper mencapai persetujuan dengan komuniti Linux untuk membenarkan komuniti Linux mencuba BitKeeper secara percuma Disebabkan oleh percubaan percuma, kandungan perjanjian itu lebih banyak tentang melindungi BitKeeper itu sendiri.

• Pada tahun 2005, BitKeeper tidak berpuas hati dengan komuniti Linux kerana memusnahkan kandungan perjanjian (secara terang-terangan, ia menyahkompilasi BitKeeper, cuba membuat versi retak atau lain-lain), dan menamatkan kerjasama;

• Sama seperti 2005, Linux menghabiskan 2 minggu untuk membangunkan versi pertama Git, dan menggunakan Git untuk mengurus kod Linux dalam masa sebulan; 🎜>

  Asas-asas Git

Ruang Kerja, Indeks, Repositori

Konsep yang terlibat di atas:

# 创建并进入 testGitFlow 目录
# 此时 testGitFlow 就是我们的工作区(Workspace)，也就是工作目录

$ mkdir testGitFlow && cd testGitFlow

# 初始化 git 仓库
# 此时目录中增加了 .git 目录，.git 目录就是 git 仓库，不属于工作区

$ git init

# 新增两个文件
$ echo 111 > a.txt
$ echo 222 > b.txt

# 添加两个文件到暂存区/索引(Index)
$ git add .

# 把索引中的两个文件添加到版本库(Repository)
$ git commit -m 'init'

Ruang Kerja

: Pemahaman mudah adalah apa yang kami Projek Direktori
Indeks: Pemahaman mudah ialah kawasan untuk menyimpan kandungan yang akan diserahkan
Repositori: Repositori versi
Komit, Pokok, objek Blob

Beberapa konsep yang terlibat dalam perkara di atas:

# 通过 git log 查看版本
$ git log

>
commit 2b304a56998989dbcfd77f370f4b43fcad9e5872 (HEAD -> master)
Author: huihuipan <huihuipan163@163.com>
Date:   Mon Feb 27 17:56:53 2023 +0800

    init


# 通过 git cat-file 查看 commit 信息

# 查看 commit 类型
$ git cat-file -t 2b304a
> commit

# 查看 commit 内容
$ git cat-file -p 10d717

>
tree 4caaa1a9ae0b274fba9e3675f9ef071616e5b209
author huihuipan <huihuipan163@163.com> 1677491813 +0800
committer huihuipan <huihuipan163@163.com> 1677491813 +0800

init

# 可以发现有 tree, author, committer 等信息
# 继续查看 tree 内容
$ git cat-file -t 4caaa1
> tree

$ git cat-file -p 4caaa1
>
100644 blob 58c9bdf9d017fcd178dc8c073cbfcbb7ff240d6c	a.txt
100644 blob c200906efd24ec5e783bee7f23b5d7c941b0c12c	b.txt

# 可以发现有 blob 信息
# 继续查看 blob 内容
$ git cat-file -t 58c9bd 
> blob

$ git cat-file -p 58c9bd 
> 111

# 可以看到里面存储的是 a.txt 的内容

komit

: komit merekodkan versi yang diserahkan
pokok: pokok merekodkan struktur direktori di bawah yang berbeza versi dan nama fail
blob: blob rekod kandungan fail
Pada masa ini struktur projek git kami adalah seperti berikut

Apakah yang berlaku apabila anda mengubah suai fail dan menyerahkan komit?

1. Pertama sekali, kandungan a.txt diubah suai daripada 111 kepada 333. Pada masa ini, repositori git tidak berubah, tetapi kandungan ruang kerja dan indeks tidak konsisten;
2. Laksanakan arahan git add
   1. Gudang git mencipta nod gumpalan baharu berdasarkan kandungan a.txt baharu (333) dan merekodkan a.txt kandungan
   2. Indeks berubah daripada gumpalan lama menunjuk kepada gumpalan baharu
3. Laksanakan arahan git commit
   1. Janakan objek pokok berdasarkan status daripada indeks
   2. Berdasarkan objek pokok yang baru dijana dan objek komit A di atas, hasilkan objek komit baharu
   3. Pindahkan penuding cawangan dari objek komit lama ke objek komit baharu

KEPALA, Cawangan, Tag

Cawangan: ialah penunjuk yang menunjuk kepada Komit . Setiap kali komit baharu diserahkan, Cawangan semasa akan menunjukkan komit terkini;

KEPALA: Penunjuk ke Cawangan apabila daftar keluar bukan-. cawangan, ia akan menggesa Dalam keadaan penuding kepala yang terpisah, anda boleh melakukan beberapa tindakan percubaan ;

Teg: Penunjuk kepada Komit, digunakan sebagai label, biasanya digunakan untuk merekod versi tetap, dan juga boleh difahami sebagai alias untuk komit yang ditentukan;

Kita boleh belajar daripada perkara di atas bahawa butiran pengurusan versi git mencapai fail tahap, dan perbezaan boleh diperolehi dengan membandingkan gumpalan Ini juga membawa kepada pemikiran pembangunan Apabila asasnya adalah butiran yang agak kecil, pembangunan dan pengembangan seterusnya akan menjadi lebih fleksibel sangat fleksibel, sangat fleksibel sehingga kemalangan mungkin berlaku jika anda tidak berhati-hati.

Checkout, Cantumkan, Rebase, Fetch, Tarik

checkout : Semak HEAD ke cawangan yang dinyatakan atau commit, Atau semak keluar kandungan fail tertentu dalam versi tertentu Memandangkan pembayaran membawa terlalu banyak fungsi dalam git, semua cawangan bertukar mempunyai arahan eksklusif switch.

gabung :

asas semula :

Rebase akan mengubah suai sejarah versi Walaupun kandungan sebelum rebase konsisten dengan kandungan selepas rebase, versi itu bukan lagi versi yang sama

fetch. : Muat turun objek dan rujukan daripada repositori lain, seperti repositori jauh

tarik: git pull = fetch + merge

Beberapa aliran kerja berdasarkan Git

GitFlow

Pengenalan

daripada Vincent Driessen dalam An artikel ditulis pada tahun 2010
"Model percabangan Git yang berjaya"

Cawangan utama

mempunyai Dua cawangan akan berjalan melalui keseluruhan kitaran hayat versi, iaitu cawangan jangka panjang:

• cawangan induk: digunakan untuk keluaran
• cawangan pembangunan: digunakan untuk pembangunan Hubungan antara cawangan induk dan cawangan yang dibangunkan adalah seperti di atas Garis putus-putus menunjukkan fakta bahawa kedua-dua cawangan tidak berkaitan secara langsung, tetapi berkaitan melalui cawangan keluaran/pembaharuan

cawangan sokongan.

• cabang ciri: digunakan untuk pembangunan keperluan

Apabila membangunkan keperluan, tarik cawangan ciri daripada cawangan bangunkan cawangan dibangunkan (ujian kendiri pembangunan tidak mempunyai masalah), Gabung semula ke cawangan bangunkan, padamkan cawangan selepas bergabung, dan ubah suainya dalam cawangan bangunkan jika pepijat berlaku kemudian.

• melepaskan cawangan: digunakan untuk melepaskan

Apabila cawangan membangun berada dalam keadaan yang agak stabil, ia boleh ditarik dari membangunkan cawangan Cawangan keluaran sedia untuk dikeluarkan Cawangan keluaran tidak menjalankan pembangunan berfungsi, tetapi hanya pembetulan pepijat Apabila tiada masalah, ia digabungkan ke dalam cawangan induk untuk dilepaskan ke dalam cawangan membangunkan dan kemudian cawangan keluaran dipadamkan.

• cawangan hotfix: digunakan untuk menyelesaikan masalah pengeluaran

cawangan hotfix digunakan untuk membetulkan pepijat yang perlu diperbaiki segera dalam persekitaran pengeluaran. Apabila pepijat berlaku dalam persekitaran pengeluaran Pada masa itu, cabut cawangan pembaikan terbaru daripada cawangan induk, gabungkannya semula ke dalam cawangan induk untuk dilepaskan selepas pembaikan, dan gabungkannya ke dalam cawangan pembangunan sebelum memadamkannya.

Akhirnya semak semula aliran git

Tambahan

pada 2020 Vincent DriessenDitambahkan nota refleksi, secara kasarnyaGit FlowModel ini nampaknya rumit di bawah perisian penghantaran berterusan, anda boleh pertimbangkan untuk menggunakan Github Flow bukannya menanduk kasut Git Flow ke dalam projek.

SelepasGit FlowAdam Ruka untuk Git Flow Butiran teknikal Satu Aliran

Github Aliran

dicadangkan relatif kepadaGit Flow, Github Flow hanya mempunyai satu cabang batang dan proses PR ditambah melalui platform github: Apabila membangunkan fungsi tertentu, tarik keluar cawangan ciri daripada cawangan induk, serahkan PR selepas melengkapkan fungsi, dan biarkan kakitangan yang berkaitan menyemaknya. Ciri itu masih boleh diserahkan semasa semakan, dan cawangan ciri boleh digabungkan menjadi induk melalui PR sehingga disahkan tiada masalah untuk keluarkan

GitLab Flow

GitLab Flow Gunakan master sebagai cawangan pembangunan, Berdasarkan cawangan master, lepaskan cawangan pengeluaran
GitLab Flow menambah Takrif cawangan berikut:
Cawangan alam sekitar : Gunakan
lepasan cawangan : Digunakan apabila projek perlu mengeluarkan versi berbeza Selepas mengisytiharkan cawangan keluaran, cawangan ini hanya akan menggabungkan kemas kini pembetulan pepijat yang serius. Keluaran berterusan

gitlab-flow mengesyorkan menggunakan cawangan induk untuk pembangunan, dan membina cawangan pengeluaran berdasarkan cawangan induk untuk keluaran, dan juga mencadangkan konsep cawangan persekitaran , gabungkan lapisan demi lapisan mengikut persekitaran yang berbeza, dan akhirnya meringkaskannya ke dalam cawangan keluaran pengeluaran untuk keluaran

Keluaran versi

Jika projek anda perlu mengeluarkan versi berbeza , mod keluaran versi aliran gitlab mungkin lebih sesuai Dalam mod keluaran berterusan, versi berbeza akan dikeluarkan dalam cawangan keluaran yang berbeza.

Aone Flow

Aone-flow adalah berdasarkan cawangan induk, dan selain daripada cawangan induk ialah cawangan sementara. Cawangan persekitaran ditarik keluar berdasarkan cawangan induk Tiada sambungan antara cawangan persekitaran dan ia dibangunkan secara bebas Cawangan persekitaran tidak dibenarkan untuk diubah suai secara langsung, tetapi digabungkan dengan menggabungkan cawangan ciri yang berbeza. Cawangan ciri tidak akan dipadamkan sehingga ia digabungkan ke dalam cawangan keluaran. Satu kelebihan ialah kebutiran operasi lebih tinggi dan lebih terkawal Kelemahannya ialah walaupun kandungan cawangan persekitaran adalah sama, sejarah versi mungkin tidak konsisten.

Cara memilih kawalan versi

Beberapa aliran diperkenalkan di atas, bermula dengan gitflow, yang membolehkan git dengan tahap kebebasan yang tinggi digunakan secara berpandu

dan github-; flow mencadangkan versi aliran minimalis untuk menangani kerumitan gitflow

gitlab-flow mencadangkan penyelesaian komprominya sendiri untuk menangani pendekatan gitflow dan github-flow yang terlalu rumit atau mudah, dan juga menyediakan penyelesaian untuk dua kaedah penghantaran ( penghantaran berterusan, penghantaran versi);
Akhirnya, AoneFlow juga diperkenalkan, penyelesaian dengan butiran operasi yang lebih bebas.

Sebenarnya, tiada satu penyelesaian yang sesuai untuk semua. Pasukan/projek yang berbeza mempunyai situasi istimewa mereka sendiri Untuk situasi yang berbeza, alirannya juga berubah, dan yang sesuai adalah yang terbaik.

Akhirnya

Untuk membuat kesimpulan, sentiasa ingat bahawa panik tidak wujud. Jangan membenci diri sendiri.

Petikan daripada Vincent Driessen: "Akhirnya, sentiasa ingat bahawa tiada peluru ajaib. Pertimbangkan latar belakang anda sendiri. Jangan benci. Tentukan sendiri"

Lagi Untuk pengetahuan berkaitan pengaturcaraan, sila lawati: Video Pengaturcaraan! !

Atas ialah kandungan terperinci Dapatkan pemahaman yang mendalam tentang pelbagai aliran kerja Git. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!