Pertanyaan Praktik terbaik untuk repositori git pada proyek sumber terbuka


Saya berkontribusi pada proyek open source yang cukup kecil yang di-host di Github. Agar orang lain dapat memanfaatkan pekerjaan saya, saya telah membuat garpu saya sendiri di Github. Terlepas dari pilihan terminologi Github, saya tidak ingin benar-benar menyimpang dari proyek utama. Namun, saya tidak berharap atau berharap bahwa semua karya saya diterima ke dalam repositori utama. Namun beberapa di antaranya, telah digabungkan ke dalam repositori utama dan saya berharap ini akan berlanjut. Masalah yang saya hadapi adalah cara terbaik untuk menjaga dua pohon kami dalam keadaan di mana kode dapat dibagikan di antara mereka dengan mudah.

Beberapa situasi yang saya miliki atau akan temui meliputi:

  • Saya melakukan kode yang kemudian diterima ke dalam repositori utama. Ketika saya menarik dari repositori ini di masa depan, komit saya diduplikasi di saya gudang.
  • Saya melakukan kode yang tidak pernah diterima ke dalam repositori utama. Ketika saya menarik dari repositori ini di masa depan, kedua pohon telah menyimpang dan memperbaikinya sulit.
  • Orang lain datang dan mendasarkan pekerjaan mereka pada repositori saya. Dengan demikian, saya seharusnya seandainya mungkin menghindari perubahan commit yang saya telah mendorong, misalnya dengan menggunakan git rebase.
  • Saya ingin mengirimkan kode ke repositori master. Idealnya, perubahan saya harus dengan mudah dapat diubah menjadi tambalan (idealnya menggunakan git format-patch) yang secara langsung dan bersih dapat diterapkan ke repositori master.

Sejauh yang saya tahu ada dua, atau mungkin tiga cara untuk menangani ini, tidak ada yang bekerja dengan sangat baik:

  • Sering jalankan git rebase untuk menjaga perubahan saya berdasarkan kepala repositori hulu. Dengan cara ini saya dapat menghilangkan komitmen ganda tetapi sering harus menulis ulang sejarah, menyebabkan masalah bagi orang yang ingin mendapatkan pekerjaan mereka dari saya.
  • Sering menggabungkan perubahan repositori hulu ke tambang. Ini berfungsi ok pada akhir saya tetapi tampaknya tidak memudahkan untuk mengirimkan kode saya ke repositori hulu.
  • Gunakan beberapa kombinasi ini dan mungkin git cherry-pick untuk menjaga semuanya teratur.

Apa yang telah dilakukan orang lain dalam situasi ini? Saya tahu situasi saya analog dengan hubungan antara berbagai kontributor kernel dan repositori utama Linus, jadi semoga ada cara yang bagus untuk menangani ini. Saya cukup baru untuk git, jadi belum menguasai semua nuansa itu. Akhirnya, terutama karena Github, terminologi saya mungkin tidak sepenuhnya konsisten atau benar. Jangan ragu untuk mengoreksi saya.


32
2017-09-05 03:22


asal


Jawaban:


Beberapa tips yang saya pelajari dari situasi yang sama:

  • Memiliki cabang pelacakan jarak jauh untuk karya penulis hulu.
  • Tarik perubahan dari cabang pelacakan ini ke cabang utama Anda sesering mungkin.
  • Buat cabang baru untuk setiap topik yang sedang Anda kerjakan. Cabang-cabang ini seharusnya hanya bersifat lokal saja. Ketika Anda mendapatkan perubahan dari hulu menjadi master, rebase cabang topik Anda untuk mencerminkan perubahan ini.
  • Setelah selesai dengan beberapa pekerjaan topik, gabungkan menjadi master. Dengan cara ini, orang-orang yang berasal dari pekerjaan Anda, tidak akan melihat terlalu banyak sejarah yang ditulis ulang, karena rebasing terjadi di cabang-cabang topik lokal Anda.
  • Mengirimkan perubahan: Cabang utama Anda pada dasarnya akan menjadi serangkaian komitmen, beberapa di antaranya sama dengan hulu, sisanya milik Anda. Yang terakhir dapat dikirim sebagai patch jika Anda mau.

Tentu saja, pilihan nama cabang dan remote Anda adalah milik Anda sendiri. Saya tidak yakin ini lengkap untuk skenario, tetapi mereka menutupi sebagian besar rintangan saya.


17
2017-09-05 03:53