Memahami perbedaan cabang antara SVN dan Git

44

Saya adalah pengguna SVN dan sekarang saya belajar Git.

Di SVN saya biasanya checkout repo di komputer lokal saya, yang mencakup semua cabang di proyek saya dan saya biasa memilih folder untuk cabang saya yang saya minati dan bekerja di sana.

Saya melihat perbedaan menggunakan Git.

Saat ini saya sedang mengkloning repo dan mengkloning cabang tertentu menggunakan gitk.

Folder proyek hanya berisi konten untuk cabang itu dan saya tidak bisa melihat semua cabang seperti di SVN, yang sedikit membingungkan bagi saya.

Saya tidak dapat menemukan cara mudah untuk melihat semua cabang di repositori lokal saya menggunakan Git.

  • Saya ingin tahu apakah proses Git yang saya jelaskan adalah "standar" dan beberapa seberapa benar atau saya kehilangan sesuatu.

  • Saya juga ingin tahu bagaimana menangani proses di mana saya perlu bekerja pada dua cabang pada saat yang sama, misalnya, saya perlu membuat perbaikan terbaru pada master tetapi tetap menyimpan konten dari cabang lain juga.

  • Apa yang dimaksud dengan konvensi nama rekomendasi untuk membuat folder yang menyertakan cabang yang diklon dari repo di Git, misalnya myproject-branchname?

git github Radex
sumber
8
Menarik - biasanya dengan SVN Anda hanya akan memeriksa bagasi atau cabang yang sedang Anda kerjakan, tapi saya mengerti maksud Anda.
HorusKol
20
Anda telah merusak alur kerja di SVN, sekarang Anda mencoba untuk mencerminkannya ke Git (sementara bahkan alur kerja SVN yang baik hanya berlaku sebagian untuk Git). Solusi terbaik - lupakan semua kebiasaan-SVN dan mulailah di Git dari awal
Lazy Badger
6
git clonelebih seperti svnadmin hotcopyatau svnrdump+ svnadmin loaddaripada itu svn checkout. Dengan git, Anda tidak meminta sedikit demi sedikit dari repositori; Anda menyalin seluruh repositori dan bekerja dengannya secara lokal, mendorong perubahan kembali ke repositori "sumber" kapan dan jika Anda menginginkannya. Git dan Subversion menggunakan dua model yang sama sekali berbeda untuk kontrol sumber.
chepner
1
mengenai hal perbaikan terbaru, pertimbangkan untuk menggunakangit-flow
Bakuriu
5
@LazyBadger itu tidak rusak alur kerja jika itu memfasilitasi pengembangan dan memberikan nilai. Tidak ada satu cara yang benar untuk menggunakan cabang.
dietbuddha

Jawaban:

67

Saya adalah pengguna SVN dan sekarang saya belajar GIT.

Selamat datang di geng!

Pendidikan Kembali SVN

Di SVN saya biasanya [...]

Tunggu sebentar. Sementara CVS dan SVN dan sistem kontrol versi tradisional (mis. Terpusat) memenuhi (sebagian besar) tujuan yang sama dengan sistem kontrol versi modern (yaitu didistribusikan) seperti mercurial dan Git, Anda akan jauh lebih baik belajar Git dari bawah daripada mencoba mentransfer alur kerja SVN Anda ke Git.

http://hginit.com ( lihat di archive.org ) oleh Joel Spolsky (salah satu pendiri Stack Exchange) adalah tutorial untuk lincah, bukan Git, tetapi bab ke-0, "Pendidikan Ulang Subversion" adalah bermanfaat bagi orang beralih dari SVN untuk setiap sistem kontrol versi didistribusikan, karena memberitahu Anda apa konsep SVN Anda harus (sementara) un -Pelajari (atau untuk stashpergi , karena pengguna Git mungkin mengatakan) dapat membungkus kepala Anda sekitar didistribusikan konsep sistem kontrol versi dan alur kerja idiomatik yang dibuat untuk bekerja dengannya.

Jadi, Anda dapat membaca bab ke-nol dan kebanyakan hanya mengganti kata "lincah" dengan "Git" dan dengan demikian mempersiapkan diri dan pikiran Anda untuk Git.

Cetak halus

(Anda mungkin melewatkan ini untuk saat ini.) Sementara lincah dan Git jauh lebih mirip satu sama lain daripada SVN, ada yang beberapa perbedaan konseptual antara mereka, sehingga beberapa pernyataan dan saran dalam "Subversion Re-pendidikan" akan menjadi salah teknis saat mengganti "mercurial" dengan "Git":

  • Sementara mercurial secara internal melacak dan menyimpan perubahan set, Git secara internal melacak dan menyimpan revisi (yaitu keadaan isi pohon direktori), seperti halnya Subversion. Tetapi selain Subversion Git melakukan penggabungan dengan melihat perbedaan antara masing-masing cabang yang terlibat masing-masing dan revisi nenek moyang yang sama (3-point-gabungan), sehingga hasilnya sama seperti untuk lincah: Penggabungan jauh lebih mudah dan lebih sedikit kesalahan -rendah daripada di SVN.
  • Meskipun Anda bisa bercabang di Git dengan mengkloning repositori (seperti kebiasaan dalam lincah), jauh lebih umum untuk membuat cabang baru dalam repositori Git. (Itu karena cabang Git hanyalah (memindahkan) pointer ke revisi, sedangkan cabang mercurial adalah label permanen yang diterapkan untuk setiap revisi. Label permanen ini biasanya tidak diinginkan, sehingga alur kerja mercurial biasanya bekerja dengan mengkloning repositori lengkap untuk pengembangan yang berbeda.)

Di SVN, semuanya adalah direktori (tetapi Anda tidak perlu memperlakukannya seperti itu)

Tapi saya sudah mengganggu Anda. Anda katakan?

Di SVN saya biasanya checkout repo di komputer lokal saya, yang mencakup semua cabang di proyek saya dan saya biasa memilih folder untuk cabang saya yang saya minati dan bekerja di sana.

Jika, dengan itu, Anda berarti Anda telah memeriksa folder root repositori SVN (atau folder lain yang sesuai dengan lebih dari trunkatau ke satu cabang, misalnya dalam tata letak repo SVN konvensional branchesfolder yang berisi semua cabang non-trunk) kemudian Saya berani mengatakan Anda mungkin pernah menggunakan SVN salah (ish), atau setidaknya sedikit menyalahgunakan fakta bahwa trunk, cabang dan tag semua dilipat menjadi satu namespace (meskipun hierarkis) bersama dengan direktori dalam revisi / basis kode.

Meskipun mungkin tergoda untuk mengubah beberapa cabang SVN secara paralel, itu adalah AFAIK bukan bagaimana SVN dimaksudkan untuk digunakan. (Meskipun saya tidak yakin tentang apa kerugian yang bekerja seperti itu.)

Di Git, hanya direktori yang merupakan direktori

Setiap klon dari repositori Git sendiri merupakan repositori Git: Secara default, itu mendapatkan salinan lengkap dari sejarah repositori asal, termasuk semua revisi, cabang, dan tag. Tapi itu akan mempertahankan semua yang kami inginkan: Git menyimpannya dalam basis data berbasis file, yang terletak di .git/subfolder tersembunyi folder root repositori .

Tapi apa file non-tersembunyi yang Anda lihat di folder repositori?

Ketika Anda git clonerepositori, Git melakukan beberapa hal. Kurang lebih:

  1. Itu menciptakan folder target , dan di dalamnya, .git/subfolder dengan "database"
  2. Ini mentransfer referensi (tag, cabang dll) dari database repositori asal dan membuat salinannya dalam database baru, memberi mereka nama yang dimodifikasi sedikit yang menandainya sebagai referensi "jarak jauh".
  3. Ini mentransfer semua revisi (yaitu file tree menyatakan) bahwa referensi ini menunjuk ke, juga semua revisi yang menunjuk revisi langsung atau transitif (orang tua dan leluhur mereka) ke database baru dan menyimpannya, sehingga referensi jarak jauh yang baru sebenarnya arahkan ke sesuatu yang tersedia di repositori baru.
  4. Ini menciptakan cabang lokal yang melacak revisi jarak jauh yang sesuai dengan cabang default repositori asal (biasanya master).
  5. Itu memeriksa cabang lokal itu.

Langkah terakhir itu berarti bahwa Git mencari revisi yang ditunjuk oleh cabang ini, dan membongkar file-tree yang disimpan di sana (database menggunakan beberapa cara kompresi dan de-duplikasi) ke dalam folder root repositori. Folder root dan semua subfoldernya (tidak termasuk .gitsubfolder khusus ) dikenal sebagai "copy pekerjaan" repositori Anda. Di situlah Anda berinteraksi dengan konten revisi / cabang saat ini check-out. Itu hanya folder dan file biasa. Namun, untuk berinteraksi dengan repositori per-se ("database" revisi dan referensi) Anda menggunakan gitperintah.

Melihat cabang Git dan berinteraksi dengan cabang Git

Saat ini saya sedang mengkloning repo dan mengkloning cabang tertentu menggunakan gitk.

Versi yang gitksaya dapat tidak dapat mengkloning repositori. Itu hanya dapat melihat riwayat repo dan membuat cabang dan memeriksa cabang. Juga, tidak ada "kloning" cabang. Anda hanya dapat mengkloning repositori.

Apakah maksud Anda mengkloning repo menggunakan git clone ...dan kemudian, menggunakan gitk, periksa cabang?

Folder proyek hanya berisi konten untuk cabang itu dan saya tidak bisa melihat semua cabang seperti di SVN, yang sedikit membingungkan bagi saya.

[...]

  • Saya ingin tahu apakah proses git yang saya jelaskan adalah "standar" dan bagaimana [...]

Ya, itu cukup standar:

  • Mengkloning repositori menggunakan git clone ...
  • Periksa cabang yang ingin Anda kerjakan git checkout ...atau gunakan alat grafis sepertigikt

Saya tidak dapat menemukan cara mudah untuk melihat semua cabang di repositori lokal saya menggunakan GIT.

  • [...] atau saya hilang smt.

Mungkin:

  • Anda dapat mendaftar cabang lokal dengan git branch
  • Anda dapat membuat daftar cabang jarak jauh dengan git branch -ratau semua cabang dengangit branch -a

  • Anda dapat menggunakan gitkuntuk melihat riwayat lengkap (semua tag cabang dll. yang diketahui oleh repo lokal Anda) dengan menjalankannya

    gitk --all

Cara bekerja dengan banyak cabang secara paralel

  • Saya juga ingin tahu bagaimana menangani proses di mana saya perlu bekerja pada dua cabang pada saat yang sama, misalnya, saya perlu membuat perbaikan terbaru pada master tetapi tetap menyimpan konten dari cabang lain juga.

Ada berbagai skenario di sini:

Perubahan baru (belum dibuat) perlu diterapkan ke beberapa cabang

Gunakan alur kerja ini:

  1. Buat cabang baru cdari revisi yang sudah ada dalam leluhur semua cabang ini (mis. Revisi yang memperkenalkan bug ketika perubahan akan menjadi perbaikan bug) atau dari revisi yang (termasuk semua leluhurnya) dapat diterima untuk diperkenalkan di semua cabang ini.
  2. Buat dan lakukan perubahan pada cabang baru itu c.

  3. Untuk setiap cabang byang membutuhkan perubahan:

    1. Lihat b:

      git checkout b

    2. Gabungkan cmenjadi b:

      git merge c

  4. Hapus cabang c:

    git branch --delete c

Perubahan yang ada diperlukan pada cabang yang berbeda

(... tetapi tanpa perubahan lain yang dibuat di tempat perubahan itu berada)

  1. Lihatlah cabang tempat perubahan diperlukan
  2. Cherry-pilih revisi untuk melakukan perubahan, secara berurutan

Di satu cabang a, Anda ingin mengubah satu atau beberapa file ke keadaan persisnya pada cabang yang berbedab

  1. Periksa a

  2. Dapatkan konten file dari cabang b:

    git checkout b -- path/to/a/file.txt path/to/another/file.cpp or/even/a/complete/directory/ ...

    (Selain git checkouttanpa melewati jalur, ini tidak akan beralih ke cabang b, hanya mendapatkan konten file yang diminta dari sana. File-file ini mungkin atau mungkin belum ada a. Jika ya, mereka ditimpa dengan kontennya b.)

Saat mengerjakan satu cabang, Anda ingin melihat bagaimana keadaan di cabang lain

Lihatlah cabang yang ingin Anda kerjakan.

Kemudian, untuk melihat cabang lainnya,

  • baik menggunakan alat grafis yang memungkinkan Anda untuk melihat konten revisi yang saat ini belum diperiksa (misalnya dalam gitkmencoba untuk beralih tombol radio dari "patch" ke "tree")
  • atau mengkloning repositori ke direktori sementara dan periksa cabang lain di sana
  • atau gunakan git worktreeuntuk membuat direktori kerja terpisah dari repositori yang sama (yaitu juga menggunakan database dalam .git/direktori repositori lokal Anda saat ini) di mana Anda dapat memeriksa cabang lain itu
das-g
sumber
Untuk alur kerja terakhir, stashsangat ideal.
CAD97
@ CAD97 tidak jika Anda ingin terus bekerja di cabang pertama, sambil melihat yang kedua untuk referensi secara paralel . git stashAdalah baik untuk memindahkan pekerjaan yang belum selesai keluar dari jalan, misalnya untuk berganti cabang dan kemudian kembali.
das-g
1
"alur kerja mercurial biasanya bekerja dengan mengkloning repositori lengkap untuk menyimpang pengembangan" - Eh, saya pernah mendengar tentang ini, tetapi kebanyakan orang yang menginginkan cabang Git hanya menggunakan bookmark daripada mengkloning seluruh repo. Jauh lebih mudah.
Kevin
@ Kevin Itu mungkin. Beberapa waktu yang lalu saya terakhir menggunakan lincah, jadi mungkin itu berbeda saat itu. (Atau mungkin itu hanya alur kerja komunitas yang saya gunakan dengan yang seperti ini.)
das-g
Mungkin teks Hg Init "[...] karena Anda benar-benar seharusnya bercabang dengan cara Mercurial, dengan mengkloning repositori [...]" juga harus diperbarui dalam hal itu.
das-g
31

Di SVN saya biasanya checkout repo di komputer lokal saya, yang mencakup semua cabang di proyek saya dan saya biasa memilih folder untuk cabang saya yang saya minati dan bekerja di sana.

Kecuali Anda melihat direktori di atas trunk, di Subversion Anda umumnya tidak memiliki semua cabang yang tersedia secara lokal. Dalam Git, semua konten (komit, pesan, cabang, dll.) Selalu dikloning ke setiap salinan.

Saat ini saya sedang mengkloning repo dan mengkloning cabang tertentu menggunakan gitk.

Tidak mungkin, lihat di atas. Anda bisa git checkout branch-name, tetapi Anda tidak bisa git clone something branch-name. Dalam Subversion, cabang adalah folder. Di Git, cabang adalah pointer ke sebuah commit.

Saya tidak dapat menemukan cara mudah untuk melihat semua cabang di repositori lokal saya menggunakan GIT.

Lari git branch. Secara default ini hanya menampilkan cabang lokal. Gunakan git branch --remoteuntuk melihat cabang jarak jauh.

l0b0
sumber
4
Hm "Secara default ini hanya menunjukkan cabang lokal." Kedengarannya seperti ada jenis cabang lain yang tidak lokal. Tetapi Anda juga mengatakan "Dalam Git, semua konten (komit, pesan, cabang, dll.) Selalu dikloning ke setiap salinan." . Saya menemukan itu agak membingungkan, karena jika semua cabang diklon ke salinan Anda, apa cabang-cabang non-lokal yang misterius? Mungkin terlalu rumit untuk menjawab di kolom komentar.
pipa
2
@pipe Saat Anda mengkomit perubahan, Anda melakukan ini dengan membuat komit lokal, yang mengubah komit yang ditunjuk cabang. Jika Anda ingin orang lain mendapatkan perubahan ini, Anda perlu mendorong perubahan ini ke repositori jarak jauh. Ini menghasilkan cabang jauh yang menunjuk ke komit baru ini. Sekarang semua orang dapat menarik perubahan ini dari sana dan sebagai hasilnya semua orang akhirnya akan mendapatkan salinan lengkap dari repositori
Frozn
9
@pipe Pertama, Anda sebenarnya bisa mengkloning hanya menggunakan cabang --single-branch(bahkan hanya ujung dengan --depth 1). Perbedaan antara cabang lokal dan terpencil yang diketahui git hanyalah semacam label. Cabang jarak jauh diawali dengan nama sumber jarak jauh (sering origin). Cabang lokal tidak memiliki awalan itu. Tetapi pada akhirnya, data tersedia secara lokal (kecuali jika Anda melakukan --single-branchatau sesuatu yang serupa). Ketika Anda menjalankan git checkout $branchnamedengan cabang yang tidak memiliki cabang lokal selain cabang jarak jauh, git secara otomatis membuat cabang lokal "melacak" kendali jarak jauh.
Jonas Schäfer
"Kecuali Anda memeriksa direktori di atas trunk" - Pengalaman saya adalah ini cukup umum, karena itu membuat penggabungan jauh lebih mudah. (Meskipun kami menggunakan satu cabang "langsung" alih-alih tag versi, jadi biasanya hanya berjumlah 2-3 salinan kode)
Izkata
1
@Izkata "membuat penggabungan menjadi lebih mudah", bukan?
HorusKol
3

Karena ini ditandai dengan git, saya harap kurangnya pengetahuan SVN saya bisa diabaikan.

Saat ini saya sedang mengkloning repo dan mengkloning cabang tertentu menggunakan gitk.

Anda mengkloning seluruh repositori jarak jauh tidak hanya cabang tertentu.

Repositori paling baik dibayangkan sebagai basis data, jadi Anda membuat tiruan dari kondisi saat ini dari basis data jauh. Tetapi setelah itu, Anda bekerja pada salinan database Anda sendiri; jika Anda berkomitmen, Anda mengubah database lokal Anda.

The fetchPerintah ini digunakan untuk menjaga database lokal sinkron dengan satu remote.

Biasanya dari database lokal itu, Anda checkout cabang untuk bekerja. Ini tidak lain dari penanda internal untuk git, di mana pekerjaan Anda saat ini dimulai.

Katakanlah, Anda sedang mengerjakan repositori sederhana, di mana tidak ada cabang selain itu master, Anda bisa melihat ke dalam .gitfolder untuk mengungkap "sihir":

Asumsikan komit terakhir Anda (aktif master) adalah 182e8220b404437b9e43eb78149d31af79040c66, Anda akan menemukan persisnya di bawah cat .git/refs/heads/master.

Dari yang Anda cabut dari cabang baru git checkout -b mybranch, Anda akan menemukan pointer yang sama persis di file cat .git/refs/heads/mybranch.

Cabang tidak lebih dari "pointer". Marker "berfungsi" disebut a HEAD.

Jika Anda ingin tahu di mana Anda HEADberada:

cat .git/HEADyang mengatakan misalnya ref: refs/heads/mybranch, yang pada gilirannya menunjuk ( cat .git/refs/heads/mybranch) ke hash komit78a8a6eb6f82eae21b156b68d553dd143c6d3e6f

Komit aktual disimpan di bawah objectsfolder (caranya adalah topiknya sendiri).

Folder proyek hanya berisi konten untuk cabang itu dan saya tidak bisa melihat semua cabang seperti di SVN, yang sedikit membingungkan bagi saya.

Jangan bingung working directorydengan "git-database" secara keseluruhan. Seperti yang saya katakan di atas, direktori kerja Anda hanya snapshot dari (mungkin) subset.

Katakanlah Anda memiliki cabang yang berbeda, direktori kerja Anda didedikasikan untuk mengerjakan cabang itu saja (meskipun Anda bisa meletakkan pekerjaan dari sana di tempat lain).

Biasanya, jika Anda ingin melihat, cabang apa yang ditentukan untuk proyek, Anda memiliki kemungkinan

  • git branch untuk cabang lokal
  • git branch --remote untuk cabang terpencil
  • git branch -a untuk keduanya

(atau git branch -v)

Karena git adalah sistem kontrol versi terdistribusi, git tidak hanya memungkinkan, tetapi dianjurkan, untuk membuat cabang-cabang yang berbeda secara lokal / jauh.

Alur kerja khas saya adalah:

  • cabang fitur cabang off
  • cabang cabang WIP (sedang dalam proses) dari itu
  • bekerja seperti apa pun yang Anda inginkan - bahkan jika Anda melakukan setelah satu baris; itu tidak masalah

Ketika fitur selesai:

  • squash / ulang WIPcabang (dengan rebasing interaktif) = buat satu komit dari itu
  • menggabungkan WIPcabang ke cabang fitur dan menawarkan itu (jika Anda bekerja dengan github tawaran itu akan disebut "permintaan tarik") untuk diintegrasikan ke dalam cabang (master) yang stabil.

Saya juga ingin tahu cara menangani proses di mana saya perlu wprl pada dua cabang pada saat yang sama, misalnya, saya perlu membuat perbaikan terbaru pada master tetapi tetap menyimpan konten dari cabang lain juga.

Itu tergantung pada bagaimana proyek Anda disusun:

Katakanlah Anda memiliki master yang stabil. Dan fitur hanya dikembangkan dari cabang stabil itu - jadi biasanya di belakang cabang fitur. Maka Anda akan memiliki komit terakhir pada master yang akan menjadi root dari cabang fitur.

Maka Anda akan membuat komit pada cabang master dan dapat memutuskan, apakah akan menggabungkan kedua cabang bersama-sama atau untuk rebase (yang merupakan semacam penggabungan untuk pengguna dengan kebutuhan canggih, katakanlah).

Atau Anda selalu dapat membuat perubahan pada cabang (mis. master) Dan memilihnya ke cabang lain.

Apa yang dimaksud dengan konvensi nama rekomendasi untuk membuat folder yang menyertakan cabang yang diklon dari repo di GIT, misalnya myproject-branchname

Ini terserah kamu.

Biasanya, Anda berakhir dengan nama repositori.

Tetapi ada beberapa kesempatan, ketika ini tidak diinginkan:

mis. Anda mengkloning oh-my-zsh dengan git clone git://github.com/robbyrussell/oh-my-zsh.git ~/.oh-my-zsh Here .oh-my-zshsecara eksplisit disebut sebagai target.

Thomas Junk
sumber
2

Git clone sebenarnya mengkloning seluruh repositori, tetapi menetapkan direktori kerja Anda ke default (biasanya master).

Anda dapat melihat cabang lain menggunakan git branchuntuk melihat cabang lokal atau git branch -runtuk melihat cabang jarak jauh dan kemudian git checkoutuntuk beralih ke cabang yang ada atau membuat yang baru berdasarkan cabang saat ini.

Anda harus membaca dokumentasi git untuk lebih jelasnya, dan Atlassian juga memiliki beberapa artikel bagus.

HorusKol
sumber
0

Cabang di git dan svn pada dasarnya berbeda.

Dalam svn cabang (atau tag) adalah direktori dalam repo.

Di git, cabang (atau tag) adalah pointer ke komit.

Dengan svn Anda bisa jika Anda ingin checkout akar repo. Ini berarti Anda telah memeriksa setiap cabang dan tag sekaligus. Afaict ini bukan cara normal untuk menggunakan svn.

Cabang git bukan direktori, jadi tidak ada kata lain untuk "memeriksa akar repo". Ada beberapa dukungan untuk beberapa pohon yang bekerja, jadi saya kira Anda bisa membuat skrip untuk checkout setiap cabang pada saat yang sama jika Anda benar-benar menginginkannya tetapi itu akan menjadi pemikiran yang agak tidak biasa.

Selanjutnya dengan SVN ada satu repo. Dengan git, setiap pengembang memiliki repo sendiri. Ini berarti pengembang dapat bekerja offline tetapi juga berarti pengembang yang berbeda mungkin memiliki gagasan berbeda tentang apa yang ada di setiap cabang.

Berdasarkan menjadi direktori dan berdasarkan model sejarah linear sederhana svn cabang svn memiliki sejarah yang kuat. Jika Anda ingin tahu apa yang ada di cabang x pada tanggal y Anda dapat dengan mudah mengajukan pertanyaan itu.

Cabang Git di sisi lain tidak benar-benar memiliki sejarah. Ada "reflog" tetapi dimaksudkan lebih sebagai mekanisme pemulihan bencana daripada sejarah jangka panjang. Secara khusus reflog tidak dapat dibaca dari jarak jauh dan dinonaktifkan secara default untuk repo kosong.

Komit tentu saja memiliki sejarah tetapi sejarah tersebut tidak cukup untuk menjawab pertanyaan "apa yang ada di cabang x dari laporan pada tanggal z".

Saya tidak dapat menemukan cara mudah untuk melihat semua cabang di repositori lokal saya menggunakan Git.

Anda dapat mendaftar semua cabang lokal dengan mengetikkan "cabang git".

Anda dapat mendaftar semua cabang baik lokal maupun jarak jauh dengan menggunakan "git branch -a"

Saya juga ingin tahu bagaimana menangani proses di mana saya perlu bekerja pada dua cabang pada saat yang sama, misalnya, saya perlu membuat perbaikan terbaru pada master tetapi tetap menyimpan konten dari cabang lain juga.

Beberapa pilihan.

Anda dapat melakukan perubahan pada "cabang lain", beralih ke master lakukan pekerjaan Anda di sana, lalu beralih kembali.

Anda juga dapat membuat pohon kerja tambahan. Google "git-worktree" untuk rincian tentang sintaks.

Apa yang dimaksud dengan konvensi nama rekomendasi untuk membuat folder yang menyertakan cabang yang diklon dari repo di Git, misalnya myproject-branchname?

Saya tidak berpikir ada konvensi yang mapan. Memeriksa beberapa pohon yang bekerja sekaligus adalah pengecualian, bukan aturannya.

Peter Green
sumber
2
jawaban ini terlihat tidak lengkap, mengapa?
nyamuk