Tutorial Git: Memulai kontrol versi Git

Artikel ini memperkenalkan Anda pada Git, termasuk cara menginstal perangkat lunak yang diperlukan untuk mengakses server Git di mana proyek perangkat lunak Anda akan disimpan.

Konsep kontrol versi

Untuk memahami Git dan konsep kontrol versi, melihat kontrol versi dari perspektif historis sangat membantu. Sudah ada tiga generasi perangkat lunak kontrol versi.

Generasi pertama

Generasi pertama sangat sederhana. Pengembang bekerja pada sistem fisik yang sama dan "memeriksa" satu file dalam satu waktu.

Generasi perangkat lunak kontrol versi ini menggunakan teknik yang disebut penguncian file . Saat pengembang memeriksa file, file itu terkunci sehingga tidak ada pengembang lain yang dapat mengedit file tersebut. 

Contoh perangkat lunak kontrol versi generasi pertama termasuk Revision Control System (RCS) dan Source Code Control System (SCCS).

Generasi kedua

Masalah dengan generasi pertama termasuk yang berikut:

  • Hanya satu pengembang yang dapat mengerjakan file dalam satu waktu. Ini mengakibatkan kemacetan dalam proses pengembangan.

  • Pengembang harus masuk langsung ke sistem yang berisi perangkat lunak kontrol versi.

Masalah ini dipecahkan dalam perangkat lunak kontrol versi generasi kedua. Pada generasi kedua, file disimpan di server terpusat di repositori. Pengembang dapat memeriksa salinan file yang terpisah. Saat pengembang menyelesaikan pekerjaan pada sebuah file, file tersebut diperiksa ke dalam repositori. 

Jika dua pengembang memeriksa versi file yang sama, maka potensi masalah ada. Ini ditangani oleh proses yang disebut penggabungan .

Apa itu merge? Misalkan dua pengembang, Bob dan Sue, memeriksa versi 5 dari sebuah file bernama abc.txt. Setelah Bob menyelesaikan pekerjaannya, dia memeriksa kembali file tersebut. Biasanya, ini menghasilkan versi baru dari file tersebut, versi 6.

Beberapa saat kemudian, Sue memeriksa arsipnya. File baru ini harus menyertakan perubahannya dan perubahan Bob. Ini dilakukan melalui proses penggabungan.

Bergantung pada perangkat lunak kontrol versi yang Anda gunakan, mungkin ada cara berbeda untuk menangani penggabungan ini. Dalam beberapa kasus, seperti ketika Bob dan Sue telah mengerjakan bagian file yang sama sekali berbeda, proses penggabungannya sangat sederhana. Namun, jika Sue dan Bob mengerjakan baris kode yang sama dalam file, proses penggabungan bisa lebih rumit. Dalam kasus tersebut, Sue harus membuat keputusan, seperti apakah kode Bob atau kodenya akan ada di versi baru file.

Setelah proses penggabungan selesai, proses memasukkan file ke repositori berlangsung. Untuk mengkomit file pada dasarnya berarti membuat versi baru di repositori; dalam hal ini, versi 7 dari file tersebut.

Contoh perangkat lunak kontrol versi generasi kedua termasuk Sistem Versi Bersamaan (CVS) dan Subversion.

Generasi ketiga

Generasi ketiga disebut sebagai sistem kontrol versi terdistribusi (DVCS). Seperti generasi kedua, server repositori pusat berisi semua file untuk proyek tersebut. Namun, pengembang tidak memeriksa file individu dari repositori. Alih-alih, seluruh proyek diperiksa, memungkinkan pengembang untuk mengerjakan set lengkap file, bukan hanya file individual. 

Perbedaan lain (sangat besar) antara perangkat lunak kontrol versi generasi kedua dan ketiga berkaitan dengan cara kerja proses penggabungan dan komit. Seperti yang disebutkan sebelumnya, langkah-langkah di generasi kedua adalah melakukan penggabungan dan kemudian memasukkan versi baru ke repositori.

Dengan perangkat lunak kontrol versi generasi ketiga, file-file diperiksa dan kemudian digabungkan. 

Misalnya, dua pengembang memeriksa file yang didasarkan pada versi ketiga. Jika satu pengembang memeriksa file itu, menghasilkan versi file 4, pengembang kedua harus terlebih dahulu menggabungkan perubahan dari salinan check-out-nya dengan perubahan versi 4 (dan, kemungkinan besar, versi lain). Setelah penggabungan selesai, versi baru dapat dimasukkan ke repositori sebagai versi 5.

Jika Anda fokus pada apa yang ada di repositori (bagian tengah dari setiap fase), Anda melihat bahwa ada garis pengembangan yang sangat lurus (ver1, ver2, ver3, ver4, ver5, dan seterusnya). Pendekatan sederhana untuk pengembangan perangkat lunak ini menimbulkan beberapa masalah potensial:

  • Mewajibkan pengembang untuk menggabungkan sebelum melakukan sering kali mengakibatkan pengembang tidak ingin melakukan perubahan mereka secara teratur. Proses penggabungan bisa sangat merepotkan dan pengembang mungkin memutuskan untuk menunggu sampai nanti dan melakukan satu penggabungan daripada sekumpulan penggabungan biasa. Ini berdampak negatif pada pengembangan perangkat lunak karena tiba-tiba potongan besar kode ditambahkan ke file. Selain itu, Anda ingin mendorong pengembang untuk melakukan perubahan ke repositori, seperti Anda ingin mendorong seseorang yang menulis dokumen untuk menyimpan secara teratur.
  • Sangat penting: Versi 5 dalam contoh ini belum tentu merupakan pekerjaan yang awalnya diselesaikan oleh pengembang. Selama proses penggabungan, pengembang mungkin membuang beberapa karyanya untuk menyelesaikan proses penggabungan. Ini tidak ideal karena mengakibatkan hilangnya kode yang berpotensi bagus.

Teknik yang lebih baik, meskipun bisa dibilang lebih kompleks, dapat digunakan. Ini disebut grafik asiklik terarah (DAG) .

Bayangkan skenario yang sama seperti di atas, di mana dua pengembang memeriksa versi 3 dari sebuah file. Di sini, jika salah satu pengembang memeriksa file itu, itu masih menghasilkan file versi 4. Namun, proses check-in kedua menghasilkan file versi 5 yang tidak didasarkan pada versi 4, melainkan independen dari versi 4. Pada tahap proses selanjutnya, versi 4 dan 5 file digabungkan untuk membuat versi 6.

Meskipun proses ini lebih kompleks (dan, berpotensi, jauh lebih kompleks jika Anda memiliki banyak pengembang), ini memberikan beberapa keuntungan dibandingkan dengan satu jalur pengembangan:

  • Pengembang dapat melakukan perubahan mereka secara teratur dan tidak perlu khawatir tentang penggabungan sampai nanti.
  • Proses penggabungan dapat didelegasikan ke pengembang tertentu yang memiliki gagasan yang lebih baik tentang keseluruhan proyek atau kode daripada yang dimiliki pengembang lain.
  • Setiap saat, manajer proyek dapat kembali dan melihat dengan tepat pekerjaan apa yang dibuat oleh masing-masing pengembang.

Tentu ada argumen untuk kedua metode tersebut. Namun, perlu diingat bahwa artikel ini berfokus pada Git, yang menggunakan metode grafik asiklik terarah dari sistem kontrol versi generasi ketiga.

Menginstal Git

Anda mungkin sudah memiliki Git di sistem Anda karena terkadang Git diinstal secara default (atau administrator lain mungkin telah menginstalnya). Jika Anda memiliki akses ke sistem sebagai pengguna biasa, Anda dapat menjalankan perintah berikut untuk menentukan apakah Anda telah menginstal Git:

ocs @ ubuntu: ~ $ yang git / usr / bin / git

If Git is installed, then the path to the git command is provided, as shown in the preceding command. If it isn’t installed, then you either get no output or an error like the following:

[[email protected] ~]# which git /usr/bin/which: no git in (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/ bin:/usr/sbin:/bin:/sbin:/root/bin)

As an administrator on a Debian-based system, you can use the dpkg command to determine whether the Git package has been installed:

[email protected]:~# dpkg -l git Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/ ➥Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-========-=============-=============-======================================== ii git 1:1.9.1-1ubun amd64 fast, scalable, distributed ➥revision con

As an administrator on a Red Hat–based system, you could use the rpm command to determine whether the git package has been installed:

[[email protected] ~]# rpm -q git git-1.8.3.1-6.el7_2.1.x86_64

If Git isn’t installed on your system, you must either log in as the root user or use sudo or su to install the software. If you are logged in as the root user on a Debian-based system, you can use the following command to install Git:

apt-get install git

If you are logged in as the root user on a Red Hat–based system, you can use the following command to install Git:

yum install git

Get more than Git

Consider installing the software package git-all. This package includes some additional dependency packages that add more power to Git. Although you might not use these features in the beginning, having them available when you are ready to perform more advanced Git functions will be good.

Git concepts and features

One of the challenges to using Git is just understanding the concepts behind it. If you don’t understand the concepts, then all the commands just seem like some sort of black magic. This section focuses on the critical Git concepts as well as introduces you to some of the basic commands.

Git stages

It is very important to remember that you check out an entire project and that most of the work you do will be local to the system that you are working on. The files that you check out will be placed in a directory under your home directory.

To get a copy of a project from a Git repository, you use a process called cloning. Cloning doesn’t just create a copy of all the files from the repository; it actually performs three primary functions:

  • Creates a local repository of the project under the project_name/.git directory in your home directory. The files of the project in this location are considered to be checked out from the central repository.
  • Creates a directory where you can directly see the files. This is called the working area. Changes made in the working area are not immediately version controlled.
  • Creates a staging area. The staging area is designed to store changes to files before you commit them to the local repository.

This means that if you were to clone a project called Jacumba, the entire project would be stored in the Jacumba/.git directory under your home directory. You should not try to modify these directly. Instead, look directly in the ~/Jacumba directory tol see the files from the project. These are the files that you should change.

Suppose you made a change to a file, but you have to work on some other files before you were ready to commit changes to the local repository. In that case, you would stage the file that you have finished working on. This would prepare it to be committed to the local repository.

After you make all changes and stage all files, then you commit them to the local repository. 

Realize that committing the staged files only sends them to the local repository. This means that only you have access to the changes that have been made. The process of checking in the new versions to the central repository is called a push.

Choosing your Git repository host

First, the good news: Many organizations provide Git hosting—at the time of this writing, there are more than two dozen choices. This means you have many options to choose from. That’s the good news … and the bad news.

It is only bad news because it means you really need to spend some time researching the pros and cons of the hosting organizations. For example, most don’t charge for basic hosting but do charge for large-scale projects. Some only provide public repositories (anyone can see your repository) whereas others let you create private repositories. There are many other features to consider.

One feature that might be high on your list is a web interface. Although you can do just about all repository operations locally on your system, being able to perform some operations via a web interface can be very useful. Explore the interface that is provided before making your choice.

At the very least, I recommend considering the following:

  • //bitbucket.org
  • //www.cloudforge.com
  • //www.codebasehq.com
  • //github.com
  • //gitlab.com

Note that I chose Gitlab.com for the examples below. Any of the hosts in the preceding list would have worked just as well; I chose Gitlab.com simply because it happened to be the one I used on my last Git project.

Configuring Git

Now that you have gotten through all the theory, it is time to actually do something with Git. This next section assumes the following:

  • You have installed the git or git-all software package on your system.
  • You have created an account on a Git hosting service.

The first thing you want to do is perform some basic setup. Whenever you perform a commit operation, your name and email address will be included in the metadata. To set this information, execute the following commands:

ocs @ ubuntu: ~ $ git config --global user.name "Bo Rothwell" ocs @ ubuntu: ~ $ git config --global user.email "[email protected]"

Tentunya Anda akan mengganti "Bo Rothwell"dengan nama Anda dan "[email protected]"dengan alamat email Anda. Langkah selanjutnya adalah mengkloning proyek Anda dari layanan hosting Git. Perhatikan bahwa sebelum menggandakan, hanya satu file yang ada di direktori home pengguna:

ocs @ ubuntu: ~ $ ls first.sh

Berikut ini adalah kloning proyek bernama ocs: