Tech: Asas GIT

Jumaat lepas adalah giliran aku untuk mengajar asas GIT di OST. Objektifnya adalah:

  1. Pengenalan kepada code versioning
  2. Konsep GIT
  3. Merge v Rebase
  4. Conflict

Pengenalan Code Versioning

Semalam ok je, hari ni terus tak jadi. – Pelajar FYP (saban tahun)

Untuk mengelakkan terjadinya ayat seperti di atas adalah antara sebab untuk menggunakan code versioning. Sebab lain adalah untuk mengelakkan terjadinya satu fail pelbagai versi seperti;

  • index.php
  • index.php.lama
  • index.php.lama.lama
  • index.php.lama.lama.lama-sangat

Terdapat pelbagai jenis code versioning seperti contoh;

  1. GIT
  2. SVN
  3. Mercurial

GIT adalah antara yang popular pada zaman kini. Dan entri ini adalah tentang GIT.

Konsep GIT

Konsep GIT boleh dipecahkan kepada dua bahagian iaitu;

  1. Konsep pokok
  2. Konsep kerja

Konsep Pokok

Di dalam GIT, konsep pokok ini adalah bertindak seperti sebuah pokok yang mempunyai batang utama atau main dan ranting / cabang atau branch.

Main – Batang paling utama di dalam sesebuah git. Selalunya main ini juga dipanggil sebagai cabang master.

Branch – Cabang tambahan yang mungkin dicipta disebabkan beberapa perkara seperti fungsi baharu ataupun proses membetulkan pepijat.

Konsep Kerja

  1. workplace
  2. index
  3. local repository
  4. upstream repository

Workplace

Workplace atau ruang kerja adalah keadaan semasa yang sedang digunakan oleh programmer. Dalam satu-satu ketika hanya boleh ada satu sahaja ruang kerja yang aktif untuk sesebuah projek. Secara lalai, workplace yang aktif adalah di bawah branch master.

git-init-master

Ruang kerja juga adalah tempat di mana sebarang perubahan di dalam fail berlaku. Tetapi dalam peringkat ini GIT masih belum menyimpan sebagai rekod perubahan yang sah. Hanya sebagai ruang kerja individu sahaja. Jika dilihat daripada git status, fail yang dimasukkan di bawah seksyen untracked files tersebut adalah fail yang masih berada di ruang kerja.

git-new-file-workplace

Index

Index adalah ruang dimana GIT merekodkan perubahan fail yang mahu di simpan sebagai rekod tetapi pada peringkat ini rekod tersebut masih boleh ditukar dan belum dijadikan sebagai satu rekod yang sah. Kita boleh memindahkan perubahan yang dibuat pada ruang kerja kedalam index dengan menggunakan arahan git add <nama fail>.

git-add-file-to-index

Nota: Perubahan yang berlaku selepas anda meletakkan fail ke dalam index adalah dianggap sebagai perubahan yang baru dan perlu dimasukkan kedalam index sekali lagi untuk membuat kemaskini perubahan.

Local Repository

Kita boleh menjadikan perubahan yang telah dimasukkan kedalam index sebagai rekod yang sah dengan membuat arahan git commit -m "mesej anda". Atau digelar sebagai local commit.

git-commit-status-log

Dan apabila kita menyemak kembali status GIT, GIT akan menyatakan bahawa tiada perubahan baharu di dalam index kerana perubahan tersebut telah pun di tukar kepada rekod yang sah di dalam local repository.

Kita boleh melihat commit tadi dengan menggunakan arahan git log.

253e9ee2b09af3dafe37bf9048ec6ff4016b78d8 (HEAD -> master)

  • Nombor yang panjang dihadapan tersebut adalah kod unik yang membezakan di antara commit dengan commit yang lain.
  • HEAD adalah puncak tertinggi dalam sesebuah cabang yang sedang dibuka di ruang kerja..
  • master adalah cabang yang sedang dibuka di ruang kerja.

Upstream Repository

Antara konsep yang perlu diambil perhatian kepada pengguna GIT baru adalah konsep decentralize. Di dalam GIT, konsep decentralize ini merujuk kepada kebebasan yang diberikan kepada pengguna untuk mengubah atau menambah cabang, commit baharu di dalam sesebuah local repository (contoh: laptop) tanpa memberikan kesan kepada upstream repository (contoh: server).

Dengan maksud lain, apa yang ada di dalam local repository tidak semestinya ada di dalam upstream repository, vice versa. Berbeza dengan kaedah yang digunakan SVN iaitu centralize. Dengan menggunakan konsep decentralize ini juga membolehkan orang lain mengambil projek daripada upstream repository kita dan menjadikannya sebagai satu “cabang” lain yang boleh dikawal oleh dirinya sendiri yang digelar sebagai fork.

Untuk meletakkan apa yang telah kita buat di dalam local repository juga terdapat di dalam upstream repository yang boleh dikongsi dengan orang lain, kita boleh menggunakan arahan git push <upstream alias> <upstream branch>. Atau digelar sebagai publish local commit.

git-push-origin-master

Sebagai contoh: git push origin master

Origin – selalunya di dalam GIT, alias kepada upstream repository dipanggil origin tetapi anda boleh menukarkannya kepada apa sahaja nama yang anda mahukan kerana alias adalah tetapan secara individu. Tidak mempengaruhi orang lain. Tetapi untuk memudahkan proses pemahaman, letakkan sahaja sebagai origin.

Master – cabang di dalam upstream repository selalunya adalah sama seperti yang ada di local repository.

 

Merge vs Rebase

git-merge-rebase-original

Tidak dapat tidak, apabila kita bekerja untuk sesebuah projek terlebih sekali apabila terdapat lebih daripada seorang programmer, akan tiba masa kita membuat perubahan kepada fail yang sama. Dan untuk menggabungkan dua perubahan ini terdapat dua kaedah iaitu;

  1. Merge
  2. Rebase

Terdapat perbezaan di antara merge dan rebase.

Merge

git-merge

Merge adalah proses dimana kita menyatukan dua perubahan menjadi satu dengan menggunakan satu titik pertembungan atau merge point. Ini kerana cabang tersebut akan dikekalkan. Proses merge boleh dibuat dengan menggunakan arahan git merge <nama branch>.

Pro: Cabang asal dikekalkan.

Cons: Kalau terlalu banyak cabang, akan lebih serabut untuk melihat dan memahami perubahan yang dibuat.

Rebase

git-rebase

Berbeza dengan kaedah merge, rebase adalah satu kaedah yang dilihat lebih baik pada zaman kini kerana akan menggabungkan dan menjadikan dua cabang sebagai satu cabang utama sahaja. Dan menghasilkan pokok GIT yang lebih “bersih”.

Boleh dijalankan dengan menggunakan arahan git rebase <nama branch>

Pro: Semua cabang akan disatukan menjadi satu cabang utama sahaja.

Cons: Cabang terhapus dan tidak nampak perbezaan diantara cabang utama dan cabang pecahan.

Conflict

Konflik adalah satu perkara yang tidak dapat dielakkan. Apabila anda mahu menggabungkan antara dua perubahan dengan menggunakan kaedah merge ataupun rebase, malangnya terdapat konflik di antara dua jenis perubahan yang memerlukan tindakan anda untuk membuat keputusan perubahan mana yang perlu diambil dan mana yang tidak.

Apabila berlaku sesebuah konflik, GIT akan menandakan setiap perubahan yang perlu diambil keputusan dengan menggunakan >>>>>, ===== dan <<<<<. Sebagai contoh;

git-conflict

Daripada <<<<< HEAD sehingga ===== adalah seksyen di mana kod yang ada untuk branch yang mahu digabung (merge atau rebase). Dan daripada ===== sehingga >>>>> ayam tak suka dimakan tersebut adalah seksyen di mana kod yang kita ubah. ayam tak suka dimakan tersebut adalah mesej untuk commit yang telah dibuat sebagai rujukan.

Saya suka makan.
Hari-hari saya makan.
<<<<<<< HEAD
Kawan saya suka makan ayam.
=======
Kawan saya suka makan.
Ayam tak suka dimakan.
>>>>>>> ayam tak suka dimakan

Maka tugas kita di sini adalah untuk menentukan apakah data yang kita mahu kekalkan atau mahu buang. Terdapat 4 keadaan yang saya boleh fikirkan:

  1. Ambil yang HEAD sahaja
  2. Ambil yang baru sahaja
  3. Ambil kedua-duanya
  4. Ambil secara pilihan (custom)

Ambil yang HEAD sahaja

Saya suka makan.
Hari-hari saya makan.
Kawan saya suka makan ayam.

Ambil yang baru sahaja

Saya suka makan.
Hari-hari saya makan.
Kawan saya suka makan.
Ayam tak suka dimakan.

Ambil kedua-duanya

Saya suka makan.
Hari-hari saya makan.
Kawan saya suka makan ayam.
Kawan saya suka makan.
Ayam tak suka dimakan.

Ambil secara pilihan

Saya suka makan.
Hari-hari saya makan.
Kawan saya suka makan ayam.
Ayam tak suka dimakan.
Tapi saya suka makan ayam.
Ayam sedap.

Yang penting selepas perubahan dan keputusan dibuat, fail tersebut perlu di git add dan diterukan dengan merge ataupun rebase.

Kesimpulan

Ini hanya asas kepada GIT. Masih banyak yang perlu difahami dan pengalaman akan memberikan pengajaran yang baik.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.