Pengantar Kontrol Versi dan Git

Familiar dengan Google Documents? Jika ya, aman untuk berasumsi bahwa Anda mengetahui dengan tab 'Riwayat Versi' kecil yang memungkinkan penulis dan orang-orang yang terlibat untuk memeriksa dan melacak semua perubahan yang dibuat dalam dokumen. pada titik waktu tertentu. Alat yang berguna, bukan?

Sekarang bayangkan alih-alih selembar penuh paragraf, ada file yang penuh dengan ratusan baris kode. Dan tidak seperti satu dokumen, ada banyak sekali file berbeda, yang terus diperbarui.

Dalam skenario seperti ini, di mana ada ribuan baris kode yang dimainkan dan hasil akhirnya yaitu Aplikasi Seluler adalah tempat bergantung pada masa depan bisnis, menjadi lebih penting lagi untuk memiliki perangkat lunak yang akan mengawasi semua perubahan dibuat dalam file kode.

Di sinilah Perangkat Lunak Kontrol Versi muncul.

Mengapa Kontrol Versi Penting dalam Pengembangan Perangkat Lunak

Seperti namanya, Perangkat Lunak Kontrol Versi memungkinkan pengembang aplikasi seluler untuk melacak berbagai versi siklus pengembangan perangkat lunak dan membuat perubahan di dalamnya. Kemampuan untuk melacak semua perubahan yang terjadi dalam kode dan kemudian opsi untuk membatalkan perubahan inilah yang membuat Kontrol Versi menjadi bagian penting dari proses perusahaan pengembangan aplikasi seluler yang melibatkan banyak pengembang.

Sekarang ketika datang ke Kontrol Versi, ada sejumlah perangkat lunak yang tersedia di pasar saat ini. Mari kita lihat beberapa di antaranya –

Perangkat Lunak yang Tersedia untuk Kontrol Versi

Meskipun dalam Survei GitLab, pemimpin perangkat lunak terdistribusi menemukan bahwa 98% pengguna menggunakan alat sumber terbuka Git dan lebih dari 92% pengembang menggunakan Git sebagai bahasa kontrol versi dalam proses pengembangan aplikasi, ada sejumlah alasan mengapa pengembang mungkin melihat alternatif Git. Beberapa dari alasan tersebut dapat bervariasi dari – struktur harga GitHub dan fakta bahwa Github diluncurkan di iOS dan Android, keengganan untuk Octocat, atau tingkat kenyamanan sederhana dengan bahasa kontrol versi yang bukan Git.

Apa pun alasan Anda, berikut adalah alternatif Git untuk kontrol versi –

Sekarang bahkan ketika ada sejumlah alternatif yang tersedia untuk Kontrol Versi dan di Appinventiv, kami memiliki pengalaman langsung dalam mengerjakan banyak dari mereka, karena kebutuhan pelanggan yang bervariasi, kami memang parsial terhadap Git. Biarkan saya memberitahu Anda mengapa.

Mengapa Appinventiv Menggunakan Git untuk Kontrol Versi

1. Untuk Kecepatan Petirnya

Dari semua perangkat lunak kontrol versi di pasar, kecepatan kerja elemen log Git dan Komit tidak ada bandingannya dengan yang lain. Dan ketika tim pengembang Anda sedang mengerjakan sebuah platform, menjadi mutlak diperlukan bahwa perangkat lunaknya cepat.

2. Untuk Kemampuan Bekerja Offline

Saat Anda bekerja pada perangkat lunak yang bergantung pada internet, itu bisa berisiko saat Anda sedang bepergian dan Anda kehilangan koneksi dengan repositori pusat. Tapi, tidak demikian halnya dengan Git. Dengan Git, Anda dapat melakukan hampir semua tugas di mesin lokal Anda – melakukan, menelusuri riwayat proyek, membuat cabang, atau menggabungkan.

3. Untuk Bantuan Undo

Git hadir dengan perintah 'undo' yang memungkinkan Anda mengoreksi dan mengembalikan seluruh komit. Bahkan, itu bahkan memberi Anda opsi untuk memulihkan komit yang 'dihapus' melalui opsi Reflog-nya.

4. Untuk Cadangan

Saat tim bekerja di Git, setiap klon yang dimiliki tim di mesin mereka dilengkapi dengan cadangan yang dapat digunakan. Selain itu, hampir setiap tindakan Git hanya menambahkan data dan tidak menghapusnya.

5. Untuk Membuat Komitmen yang Bermanfaat

Saat tim pengembang kami melakukan serangkaian perubahan yang tidak terkait – mengambil beberapa fitur dari A, membuat perbaikan bug di fitur lain – akan sangat sulit bagi anggota tim lain untuk memahami apa yang terjadi dan mungkin sulit bagi mereka untuk mundur Fitur A jika menyebabkan masalah.

Git memecahkan kekacauan ini dengan membuat komit granular. Melalui konsep 'staging area', seseorang dapat dengan mudah mengetahui perubahan apa yang akan dimasukkan dalam komit berikutnya, bahkan ketika Anda hanya melihat satu baris.

Jadi ini adalah lima alasan utama mengapa kami menggunakan Git di sini di Appinventiv. Sekarang kita telah melihat alasannya, sekarang saatnya untuk melihat Bagaimana. Bagaimana kami memasukkan Git ke dalam Proses Kontrol Versi kami.

Mari kita lakukan sekarang.

Proses Kontrol Versi Saat Menggunakan Git

Pembuatan Repositori

Tujuan Git adalah untuk mengelola satu set file, alias Project. Untuk melakukan itu, Git menyimpan semua informasi dalam struktur data yang dikenal sebagai Repositori. Repositori terdiri dari kode sumber aplikasi, sumber daya, dan kumpulan data. Pada dasarnya, ia memiliki semua yang mendefinisikan proyek aplikasi.

Sekarang, ada dua cara untuk mendapatkan repositori di Git. Anda dapat menggunakan direktori lokal dan mengubahnya menjadi repositori Git menggunakan baris perintah atau Anda dapat menyalin repositori Git yang sudah diunggah ke milik Anda.

Saat Anda membuat repositori, Anda biasanya mendapatkan dua opsi – Publik dan Pribadi. Repositori publik adalah repositori yang dapat dilihat oleh pengembang lain menggunakan Git dan Repositori Pribadi, di sisi lain, adalah repositori yang hanya dapat dilihat oleh beberapa orang.

Percabangan

Di sebelah Penciptaan Repositori adalah Percabangan. Di perusahaan seperti Appinventiv, di mana pada titik waktu tertentu lebih dari 15 – 20 pengembang mengerjakan satu proyek, tidak jarang pengembang berbagi kode sumber yang sama dan mengerjakannya. Apa yang terjadi adalah karena beberapa pengembang sibuk memperbaiki masalah, yang lain mungkin menerapkan beberapa fitur.

Dalam situasi seperti ini, kita membutuhkan sistem yang memudahkan untuk menangani versi kode yang berbeda dalam basis kode yang sama.

Di sinilah Gitflow berperan. Gitflow adalah kerangka kerja yang digunakan untuk percabangan secara sistematis dan efisien.

Sebelum kita melanjutkan cara kerja proses Branching di Gitflow, izinkan saya menjelaskan konsepnya dengan sebuah contoh.

Misalkan ada 5 pengembang di tim Anda dan mereka sedang mengerjakan pengembangan aplikasi seperti Instagram. Sekarang fitur aplikasi individual seperti misalkan Umpan dan Pemberitahuan dilambangkan sebagai Modul 1, Modul 2 dan seterusnya dan seterusnya. Sekarang modul yang berbeda ini adalah cabang pengembangan, yang setelah dikerjakan digabungkan dengan cabang induk atau Master.

Saat pengembang menambahkan cabang, mereka membuat jalur pengembangan independen, yang mengisolasi pekerjaan mereka dari anggota tim mereka. Cabang-cabang yang berbeda kemudian digabungkan menjadi cabang induk.

Percabangan adalah metode yang memungkinkan anggota tim untuk mengidentifikasi semua perubahan yang harus mereka harapkan dan apa yang membuat pelacakan mundur menjadi mudah.

Dalam proyek kami, kami biasanya menyimpan cabang-cabang ini –

• Cabang Utama
• Cabang Pengembangan
• Cabang Fitur
• Cabang Rilis
• Perbaikan Panas dan Perbaikan Bug

Melakukan

Perubahan yang dibuat pengembang dalam file individual dikenal sebagai Komit. Perubahan atau komit ditambahkan di repositori lokal dan bukan ke server. Selanjutnya, pengembang kami mengikuti kebiasaan menulis pesan komit, di mana deskripsi komit (perubahan yang dibuat dalam file) diposting, sehingga pengembang lain juga mengetahui detail perubahan yang dibuat dalam file.

Dorongan

Saat Anda melakukan commit di repositori Git lokal, yang terjadi selanjutnya adalah perubahan tersebut kemudian dikirim ke server, yang dikenal sebagai Push .

Cukup mudah untuk mendorong riwayat komit ke server ketika Anda adalah satu-satunya yang mengerjakan file, tetapi jika ada pengembang lain yang terlibat dalam proses juga, Anda harus menarik perubahan sebelum Anda dapat mendorong set berkomitmen untuk Git.

Selanjutnya, kita akan melihat apa yang dilakukan pada langkah Pull Change.

Tarik Permintaan

Ketika lebih dari satu pengembang bekerja pada file yang sama, yang terjadi adalah beberapa komit mungkin didorong di server oleh pengembang lain sebelum Anda mendorongnya. Dan ketika itu terjadi, konflik terjadi (lebih lanjut tentang itu nanti).

Untuk menghindari mengunggah basis kode yang sama dua kali di server, pengembang pertama-tama menarik perubahan dari repositori dan memastikan bahwa kodenya berbeda. Sekarang, secara umum, ketika dua atau lebih pengembang bekerja pada file yang sama dan mendorong komit mereka di server, opsi untuk 'Gabung' muncul.

Mari kita bicara tentang Gabung berikutnya.

Menggabungkan

Merge adalah langkah di mana pengembang menggabungkan semua cabang terlebih dahulu satu sama lain dan kemudian dengan cabang master atau induk.

Setiap kali pengiriman memasukkan perintah Push, mereka mendapatkan opsi Gabung, yang kemudian menanyakan cabang yang ingin mereka gabungkan komitnya.

Sekarang pada tahap Merge, terjadinya Konflik sangat umum terjadi. Konflik biasanya terjadi ketika dua cabang yang Anda rencanakan untuk digabungkan diubah di bagian yang sama dalam file yang sama. Apa yang terjadi di sini adalah Git tidak dapat mengetahui versi mana yang harus digunakan.

Ketika masalah Konflik ini muncul, Git menawarkan dua resolusi – Otomatis dan Manual.

Seperti namanya, Git menemukan masalahnya sendiri dan yang terakhir, pengembang harus melakukannya secara manual. Di Appinventiv, kami fokus pada penyelesaian Konflik secara manual karena menghilangkan kemungkinan kecil terjadinya bug.

Saat kami menggunakan Git untuk melakukan kontrol versi dari proses pengembangan aplikasi kami, yang terjadi secara bersamaan adalah Pelacakan Masalah.

Karena, kami adalah pengikut besar Agile dan mempercayai Agile untuk proses pengembangan aplikasi seluler kami , kami memahami pentingnya menangani beberapa proses pengembangan secara bersamaan. Dan dengan fitur pelacakan masalah, menjadi jauh lebih mudah bagi penguji untuk terus melihat kode yang ditulis dan didorong di server Git secara real time.

Kami menggunakan papan ZenHub untuk memantau alur kerja di setiap repositori. Papan memungkinkan kami untuk melacak prioritas perubahan yang disarankan dan juga membantu pengembang memperbarui komentar mereka di papan secara real time.