Alur kerja GIT untuk pengembangan web


12

Dulu tim kecil pengembang web tempat saya bekerja mulai menggunakan git untuk pengembangan web. Saat itu kami hanya berkomitmen untuk pementasan atau menguasai secara langsung dan kemudian sering bergabung di antara keduanya. Itu lebih baik daripada tidak sama sekali, tetapi juga berantakan.

Belum lama ini kami mengadopsi alur kerja gitflow. Meskipun tentu saja lebih baik daripada kekacauan yang terjadi sebelumnya tampaknya agak rumit dan terlalu banyak melepaskan / berorientasi tonggak. Rekan-rekan dev saya sering meminta saya untuk mengklarifikasi bagaimana seharusnya bekerja dan apa yang harus digabung dan tidak seharusnya. Secara umum tampaknya tidak cocok untuk pekerjaan pengembangan web di mana kami sering menggunakan kode dan tanpa melacak tonggak tertentu untuk rilis.

Pada saran teman baru-baru ini saya sudah mulai melihat GitHub Flow . Membaca posting Scott Chacon di sini sangat menyakitkan dengan ini:

Jadi, mengapa kita tidak menggunakan git-flow di GitHub? Nah, masalah utamanya adalah bahwa kami menerapkannya sepanjang waktu. Proses git-flow dirancang sebagian besar di sekitar "rilis". Kami tidak benar-benar memiliki "rilis" karena kami menyebar ke produksi setiap hari - sering beberapa kali sehari.

FWIW, saya juga telah melihat alur kerja yang bagus ini di situs Atlassian: https://www.atlassian.com/git/workflows#!workflow-feature-branch

Namun mereka SEMUA terlihat seperti pilihan yang buruk untuk pengembangan web dalam tim kecil dan sekali lagi diarahkan untuk rilis aplikasi besar tidak sering / rilis harian.

Ini adalah pertanyaan pada SE yang meminta untuk membandingkan git-flow dengan github-flow /programming/18188492/what-are-the-pros-and-cons-of-git-flow-vs-github -mengalir

Itu jawaban yang baik secara umum, tetapi seperti yang saya sebutkan di komentar saya di bawah ini meta.programmers.SE tampaknya menunjukkan bahwa pertanyaan tentang praktik alur kerja terbaik umum ada di sini dan saya berharap untuk daftar yang lebih luas dari jawaban yang mungkin daripada hanya git-flow dan github -flow, sementara khusus untuk pengembangan web. Karenanya saya pikir itu menjamin pertanyaan baru di sini.

Dengan itu, apa yang Anda temukan adalah alur kerja berbasis git terbaik / disukai untuk tim pengembangan web kecil yang mengerjakan proyek dengan penyebaran yang cukup berkelanjutan? Apakah alirannya github atau yang lainnya?


BTW, saya mengajukan pertanyaan ini di sini di Programmers.SE berdasarkan ini: meta.programmers.stackexchange.com/posts/6312/revisions
jb510

Berbagi penelitian Anda membantu semua orang . Beri tahu kami apa yang telah Anda coba dan mengapa itu tidak memenuhi kebutuhan Anda. Ini menunjukkan bahwa Anda telah meluangkan waktu untuk mencoba membantu diri sendiri, itu menyelamatkan kami dari mengulangi jawaban yang jelas, dan yang paling utama itu membantu Anda mendapatkan jawaban yang lebih spesifik dan relevan. Lihat juga Cara Meminta
nyamuk

@gnat, saya tidak yakin apa lagi yang bisa saya bagikan dalam hal itu? gitflow menjadi berorientasi pada rilis itu rumit. GitHub-Flow mengaku baik untuk digunakan setiap hari, tetapi memiliki puluhan cabang yang menunggu untuk digabung juga tampak seperti kekacauan. Berharap seseorang akan menjawab dengan "X bagus untuk web dev karena Y". Itu tercakup dengan baik di tautan yang saya berikan, saya kira saya bisa mengutip kutipan darinya?
jb510

1
@gnat - Saya benar-benar menulis ulang pertanyaan untuk menunjukkan lebih banyak penelitian dan sangat spesifik tentang jawaban yang saya cari.
jb510

Jawaban:


7

Pertama saya ingin membuat sedikit ringkasan dari alur kerja yang berbeda yang telah Anda lihat dan Anda pikir tidak cocok untuk jenis pengembangan yang sedang Anda kerjakan:

  • Terpusat ( Sumber ): Cukup mirip alur kerja SVN tetapi sekarang pada lingkungan terdistribusi. Setiap pengembang bekerja pada salinan pribadi masterdan mendorong perubahan origin/mastersecara langsung atau melalui permintaan tarik.

  • Cabang fitur ( Sumber ): Ya, itu. Setiap pengembang yang bekerja pada fitur tertentu harus bekerja pada cabang tertentu yang didedikasikan untuk fitur itu saja. Cabang fitur ini harus dibuat dari masteratau dari cabang fitur lain. Akhirnya semuanya digabungkan kembali master.

  • Gitflow ( Sumber ): Dua cabang utama melacak sejarah proyek, developdan master. 3 cabang lainnya dipanggil hotfix, releasedan featuretahan perubahan yang dilakukan langsung masteruntuk memperbaiki bug produksi kritis, ubah nomor versi dan detail lainnya sebelum rilis atau bekerja pada fitur tertentu seperti cabang Fitur , masing-masing.

  • Alur GitHub ( Sumber ): Pengembang membuat featurecabang dari master. Perubahan didorong melalui permintaan tarik. Perubahan diterima agar master bisa segera diterapkan oleh GitHub bot Hubot.

Untuk bagian pengembangan dari pertanyaan Anda, jawabannya tergantung pada latar belakang tim Anda. Apakah mereka berasal dari lingkungan SVN? Maka Anda harus pergi dengan pendekatan terpusat karena itu yang paling mirip dengan SVN. Apakah mereka merasa nyaman bekerja dengan Git? Maka mungkin Anda tidak boleh mencoba menyesuaikan alur kerja tim Anda dengan hal-hal itu, tetapi laksanakan sendiri, yang dibuat sesuai dengan kebutuhan Anda yang jika saya pahami dengan baik adalah fleksibilitas pengembangan dan penyebaran cepat.

Saya juga berpikir Anda harus fokus pada peningkatan yang terakhir. Bagaimana saluran penyebaran Anda terdiri dari? Dalam " Pengiriman Berkelanjutan: Rilis Perangkat Lunak yang Andal melalui Build, Test, dan Automation Deployment " penulis mengidentifikasi kemungkinan penyebab penyebaran yang jarang, beberapa di antaranya adalah:

  • Proses penyebaran tidak otomatis.
  • Pengujian membutuhkan waktu lama.
  • Orang tidak mengerti proses build / test / deploy.
  • Pengembang tidak didisiplinkan tentang menjaga agar aplikasi tetap berfungsi dengan membuat perubahan kecil dan bertahap, sehingga sering merusak fungsi yang ada

Apakah ada yang terdengar seperti sesuatu yang bisa Anda tingkatkan? Mungkin Anda bisa memberi tahu kami sedikit lebih banyak tentang bagaimana Anda dan tim Anda menangani bagian dari proyek ini.


2
+1, kunci untuk cd bukan git atau gitflow Anda tetapi CI dan alur kerja pengiriman.
Wyatt Barnett

Berpikir BANYAK tentang ini. Terima kasih atas wawasannya. FWIW, saya secara khusus menghindari penggunaan istilah CI karena kami tidak menggunakan CI. Mungkin kita harus, tetapi tidak, itu terlalu rumit untuk puluhan proyek yang kita kerjakan dalam minggu tertentu, beberapa jangka pendek, beberapa jangka panjang.
jb510

2
@ jb510 - kami punya setup proyek yang serupa, saya tidak akan bermimpi terbang tanpa CI. Beralih konteks jauh lebih mudah ketika semua bagian bodoh tapi rapuh ditulis.
Wyatt Barnett

1
Terkadang, ketidakmampuan untuk mengimplementasikan CI dengan mudah adalah tanda betapa Anda membutuhkan CI pada suatu proyek. Tidak ada tes unit? Penerapan semua manual? Banyak langkah menyebarkan fiddly? Perlu pemeriksaan.
Kzqai

1
Saya telah mengikuti pertanyaan dan jawaban ini selama bertahun-tahun. Saya berharap orang lain akan menawarkan jawaban juga, tetapi ini sendiri merupakan jawaban yang bagus sehingga akhirnya menandainya diterima (mungkin seharusnya sudah lama sekali)
jb510
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.