Komponen aliran GitHub

Selesai

Di unit ini, kami meninjau komponen alur GitHub berikut:

• Cabang
• Penerapan
• Permintaan Pull
• Alur Kerja GitHub
• Metode Git

Komponen Aliran GitHub

Sebelum kita masuk ke alur kerja khusus GitHub, sangat membantu untuk memahami bahwa GitHub Flow dibangun langsung pada konsep dasar Git.

Git menyediakan alat untuk melacak dan mengelola perubahan dalam kode Anda dari waktu ke waktu. GitHub membangun ini dengan mempermudah penggunaan alat-alat tersebut dengan fitur seperti cabang, penerapan, permintaan pull, dan antarmuka visual untuk kolaborasi. Mari kita mulai dengan melihat cara kerja konsep-konsep ini di GitHub.

Apa itu cabang

Di bagian terakhir, kami membuat file baru dan cabang baru di repositori Anda.

Cabang adalah bagian penting dari pengalaman GitHub. Mereka memungkinkan Anda membuat perubahan tanpa memengaruhi cabang default.

Cabang Anda adalah tempat yang aman untuk bereksperimen dengan fitur atau perbaikan baru. Jika Anda membuat kesalahan, Anda dapat mengembalikan perubahan atau mendorong lebih banyak perubahan untuk memperbaiki kesalahan. Perubahan Anda tidak akan diperbarui pada cabang default hingga Anda menggabungkan cabang Anda.

Catatan

Atau, Anda dapat membuat cabang baru dan memeriksanya dengan menggunakan git di terminal. Perintahnya adalah git checkout -b newBranchName

Apa itu komitmen

Pada unit sebelumnya, Anda menambahkan file baru ke dalam repositori dengan mengirimkan commit. Mari kita tinjau secara singkat apa itu commit.

A commit adalah perubahan pada satu atau beberapa file di cabang. Setiap penerapan dilacak oleh ID unik, tanda waktu, dan kontributor, terlepas dari apakah itu dibuat melalui baris perintah atau langsung di antarmuka web GitHub. Commit menyediakan jejak audit yang jelas bagi siapa pun yang meninjau riwayat file atau item tertaut, seperti isu atau pull request.

Anda dapat membuat penerapan menggunakan Git di terminal Anda dengan:

git commit -m "Add a helpful commit message"

Dalam repositori git, file dapat ada di beberapa status yang valid saat melalui proses kontrol versi. Status utama untuk file di repositori Git tidak terlacak dan Dilacak.

Tidak dilacak: Status awal file tersebut saat belum menjadi bagian dari repositori Git. Git tidak menyadari keberadaannya.

Terlacak: File terlacak adalah file yang dipantau git secara aktif. Ini bisa berada di salah satu substatus berikut:

• Tidak dimodifikasi: File dilacak, tetapi belum dimodifikasi sejak penerapan terakhir.
• Diubah: File telah diubah sejak penerapan terakhir, tetapi perubahan ini belum dipentaskan untuk penerapan berikutnya.
• Disiapkan: File telah dimodifikasi, dan perubahan telah ditambahkan ke area penahapan (juga dikenal sebagai indeks). Perubahan ini siap diterapkan.
• Telah dikomitasikan: File berada dalam database repositori. Ini mewakili versi file terbaru yang telah di-commit.

Status ini membantu tim Anda memahami status setiap file dan di mana file berada dalam proses kontrol versi.

Apa itu pull request?

Pull request adalah mekanisme yang digunakan untuk memberi sinyal bahwa komit dari satu cabang siap untuk digabungkan ke cabang lain.

Anggota tim yang mengirimkan permintaan pull meminta satu atau beberapa peninjau untuk memverifikasi kode dan menyetujui penggabungan. Peninjau ini memiliki kesempatan untuk mengomentari perubahan, menambahkannya sendiri, atau menggunakan permintaan pull itu sendiri untuk diskusi lebih lanjut.

GitHub juga mendukung Draf Permintaan Pull, yang memungkinkan Anda membuka permintaan pull yang belum siap untuk ditinjau.

Setelah perubahan disetujui (jika diperlukan), cabang sumber permintaan pull (cabang perbandingan) digabungkan ke cabang dasar.

Sekarang setelah Anda melihat cara kerja cabang, commit, dan pull request, mari kita telusuri bagaimana mereka terintegrasi dalam GitHub Flow.

Alur GitHub

Alur GitHub adalah alur kerja sederhana yang membantu Anda membuat dan berbagi perubahan dengan aman. Ini sangat berguna untuk mencoba ide dan berkolaborasi dengan tim Anda menggunakan cabang, permintaan penarikan, dan penggabungan.

Catatan

Alur GitHub adalah salah satu dari beberapa alur kerja populer. Lainnya termasuk Git flow dan trunk-based development.

Sekarang kita tahu dasar-dasar GitHub kita dapat berjalan melalui aliran GitHub dan komponennya.

1. Mulailah dengan membuat cabang sehingga perubahan, fitur, atau perbaikan Anda tidak memengaruhi cabang utama.
2. Selanjutnya, lakukan pembaruan Anda di cabang. Jika alur kerja Anda mendukungnya, Anda dapat menyebarkan perubahan dari cabang ini untuk mengujinya sebelum menggabungkan.
3. Sekarang, buka permintaan pull untuk mengundang umpan balik dan memulai peninjauan.
4. Kemudian, tinjau komentar dan buat pembaruan yang diperlukan berdasarkan umpan balik tim Anda.
5. Terakhir, setelah Anda yakin dengan perubahan Anda, minta persetujuan dan gabungkan pull request ke branch utama.
6. Setelah itu, hapus cabang untuk menjaga repositori Anda tetap bersih dan hindari menggunakan cabang yang sudah usang.

Metode Git

Meskipun GitHub Flow adalah alur kerja ringan yang dirancang untuk pengiriman berkelanjutan, alur Git adalah model percabangan yang lebih terstruktur yang sering digunakan di lingkungan berbasis rilis. Aliran Git telah ada lebih lama dari GitHub Flow, dan Anda mungkin masih melihat istilah master yang digunakan alih-alih main sebagai cabang default.

Gambar oleh Vincent Driessen, dari 'Model percabangan Git yang sukses'

Jenis Cabang alur Git

Git flow menggunakan beberapa cabang yang bertahan lama dan sementara

• master: Selalu mencerminkan kode siap produksi.
• develop: Berisi pekerjaan pengembangan terbaru untuk rilis berikutnya.
• fitur/*: Digunakan untuk membuat fitur baru; bercabang dari develop dan digabungkan kembali ketika selesai.
• release/*: Menyiapkan rilis produksi baru dari develop; memungkinkan pengujian akhir dan perbaikan bug kecil.
• hotfix/*: Digunakan untuk menambal masalah produksi dengan cepat; bercabang dari master.

Cara Kerja Proses alur Git

1. Pengembang membuat cabang fitur dari develop untuk membangun fungsionalitas baru.
2. Saat waktu rilis tiba, cabang rilis dibuat dari develop. Ini mengisolasi pekerjaan persiapan rilis sehingga pengembangan dapat terus tidak terganggu.
3. Perbaikan bug dapat ditambahkan ke cabang rilis, tetapi fitur utama harus menunggu rilis di masa mendatang.
4. Setelah siap, cabang rilis digabungkan ke dalam master dan ditandai dengan nomor versi. GitHub dapat menggunakan tag ini untuk membantu Anda membuat catatan rilis.
5. Cabang rilis yang sama harus digabungkan kembali ke dalam develop agar tetap sinkron.
6. Jika bug produksi penting muncul, cabang perbaikan dibuat dari master. Setelah diperbaiki, itu digabungkan ke dalam master dan develop.

Kapan Menggunakan alur Git

• Paling cocok untuk proyek dengan rilis terjadwal atau versi
• Berguna jika Anda mempertahankan beberapa versi produksi (misalnya, cabang dukungan jangka panjang)
• Ideal untuk siklus pengembangan yang lebih lambat dan lebih terstruktur (misalnya, perusahaan atau lingkungan yang diatur)
• Dianggap lebih "berat" daripada GitHub Flow karena manajemen cabang tambahan

Catatan

Alur Git mengasumsikan penerapan penggabungan untuk mengintegrasikan cabang. Menggunakan rebase atau squash merge dapat mengganggu struktur cabang dan pelacakan riwayatnya.

Untuk banyak tim yang menggunakan GitHub, GitHub Flow lebih sederhana dan lebih cepat. Tetapi jika tim Anda menghargai prediksi dan membutuhkan lebih banyak perencanaan rilis, alur Git mungkin lebih cocok.

Selamat! Anda baru saja menelusuri GitHub Flow lengkap—dan menjelajahi bagaimana alur Git menawarkan alternatif terstruktur untuk proyek berbasis rilis.

Mari kita lanjutkan ke bagian berikutnya di mana kita akan membahas perbedaan antara masalah dan diskusi.