Anda di halaman 1dari 9

2.2.

Merekam Perubahan ke Repository
Kita telah semakin akrab dengan Git repository dan sudah mulai melakukan checkout atau bekerja atas copy (salinan) dari berkas-berkas proyek. Pada saat proyek telah mencapai satu titik tertentu, kita harus meng-commit snapshot dari berkas-berkas yang telah mengalami perubahan, ke dalam repository. Untuk diingat, bahwa setiap berkas di dalam working directory dapat berstatus tracked atau untracked. Berkas berstatus tracked adalah berkas yang ada di snapshot terakhir. Bisa unmodified, modified atau staged. Sedangkan berkas yang untracked adalah semua berkas di dalam working directory yang tidak berada di snapshot terakhir atau tidak berada di dalam stage (staged). Karena baru saja dilakukan checkout, maka walaupun kita belum melakukan perubahan apapun, pada saat repository di-clone untuk yang pertamakali, semua berkas akan ditandai sebagai tracked dan modified. Pada saat kita mengedit sebuah berkas, git akan menganggap telah terjadi perubahan (modified), karena kita telah merubahnya terhitung sejak commit yang terakhir. Ini berarti telah terjadi pengulangan siklus karena telah terjadi perubahan dan kemudian semua yang ada di-stage di-commit. Siklus hidup ini diilustrasikan pada Gambar 2-1.,

Gambar 2.1. Status-lifecycle berkas

Mememeriksa Status Berkas
Alat utama yang digunakan untuk menentukan status berkas tentu saja adalah git status command. Jika command diberikan segera setelah kita melakukan cloning, hasilnya akan terlihat seperti terlihat berikut ini.
$ git status # On branch master nothing to commit (working directory clean)

Berarti working directory kita clean. Atau tidak ada berkas yang tracked dan modified. git juga tidak melihat adanya berkas yang untracked. Hasil dari command ini juga akan menampilkan informasi di branch mana kita berada. Sekarang kita di branch master (default). Hal ini akan dibahas di chapter selanjutnya. Sebagai contoh, jika kita meletakkan sebuah berkas (misalnya README), maka berkas ini akan dilaporkan sebagai untracked.

maka kita akan mendapatkan hasil berikut ini..... maka versi berkas pada saat kita melakukan git add dapat disebut dalam historical snapshot.rb .” to update what will be committed) # # modified: bencahmark. Ketika dilakukan git init di saat sebelumnya. Staging Berkas-berkas Modified Mari kita rubah sebuah berkas yang telah tracked.” to include in what will be commited) # # README nothing added to commit but untracked files present (use “git add” to track) Kita bisa melihat bahwa README masih untracked. Komando git add mengambil nama path berkas atau direktori yang bersangkutan (jika yang bersangkutan sebuah direktori)... $ git status # On branch master # Change to be committed: # (use “git reset HEAD <file>. akan terlihat bahwa berkas README sekarang telah tracked dan staged. Jika kita merubah berkas yang sebelumnya telah tracked dan melakukan komando git status lagi. Binary file dan berkas-berkas lain yang memang secara sengaja tidak dimasukkan ke dalam commit-snapshot selalu dalam status ini. Berarti git menganggap bahwa berkas yang bersangkutan belum di-commit alias tidak berada di dalam snapshot. Jika pada titik ini kita melakukan commit. maka git akan mulai melacak berkas tersebut ke dalam working directory. $ git status # On branch master # Changes to be committed: # (use “git reset HEAD <file>.. kemudian git add. git akan membiarkan dalam status tidak berada di dalam commit-snapshot sampai kita memberi komando untuk melakukan hal itu. Untuk nge-track berkas README lakukan komando berikut ini.$ git status # On branch master # Untracked files: (use “git add <file>. lakukan dengan command git add. Tracking berkas baru Untuk mulai melakukan tracking terhadap sebuah berkas. $ git add README Jika diberikan command git status lagi..” to unstage) # # new file: README # Berkas README kita katakan staged karena saat ini ada di status “Change to be committed”. karena berada di bagian “Untracked files”. kemudian akan nge-add semua berkas dalam direktori secara rekursif.” to unstage) # # new file: README # # Changed but not updated: # (use “git add <file>.

Mengapa bisa demikian? Ini menunjukkan bahwa git akan membuat berkas berstatus staged begitu kita menjalankan komando git add.” to unstage) # # new file: README # modified: benchmark.” to unstage) # # new berkas: README # modified: benchmark..rb $ git status # On branch master # Changes to be committed: # (use “git reset HEAD <file>.rb # # Changed but not updated: (use “git add <file>. Pada posisi ini. Untuk membuatnya agar staged. jika sebelum di-commit kita ingin menambahkan sesuatu pada benchmark. menaikkan ke status stages.rb telah staged dan siap untuk di-commit. $ git add benchmark. $ git add benachmark. Sekarang.rb # Apa yang terjadi? Sekarang benchmark. Jika sekarang kita commit.rb # Kedua berkas README dan benchmark. mari kita coba. $ vim benchmark.” to update what will be committed) # # modified: benchmark.rb telah didaftar sebagai staged dan sekaligus unstaged.rb $ git status # On branch master # Changes to be committed: # (use “git reset HEAD <file>.rb # Mengabaikan Berkas ..rb dan lihat hasilnya lewat komando git status..rb $ git status # On branch master # Changes to b$e committed: # (use git reset HEAD <file>. kita harus nge. versi dari benchmark..rb ditampilkan di bawah bagian “Changed but not updated” artinya: berkas yang statusnya tracked tersebut telah modified tetapi belum staged.” to unstage) # # new file: README # modified: benchmark.git add kembali agar versi terakhir berkas yang bersangkutan berstatus staged.rb. Bukan versi yang terlihat di working directory ketika kita meng-commit. Siap untuk dicommit..rb yang akan di-commit adalah versi pada posisi git add terakhir. Digunakan untuk ngetrack berkas baru. Sekarang berikan komando git add atas benchmark. dan hal-hal lain seperti misalnya memberi tanda pada berkas yang statusnya merge-conflicted ke resolved...benchmark.. kita harus memberikan komando git add (komando ini memang multi-purpose. membuat beberapa perubahan dan menyimpannya kembali. Jika kita memodifikasi sebuah berkas setelah git add diberikan. maka cukup dengan membukanya kembali.

o atau .gitignore. Berikut ini adalah contoh sebuah berkas . question mark (?) cocok dengan sebuah character. # a comment – this is ignored *. kita berkehendak agar git tidak secara otomatis nge-add. bukan yang ada di sub­direktori build/ # abaikan semua berkas di direktori build doc/*.rb tanpa membuatnya menjadi staged. dsb.[oa] *~ Baris pertama bermakna agar git mengabaikan berkas-berkas yang diakhiri dengan .txt # abaikan semua berkas berakhiran txt di direktori doc Melihat Perubahan Staged dan Unstaged Jika komando git status terlalu samar sementara kita menghendaki kepastian atas perubahan yang ada. yaitu . Kita akan banyak menggunakan git diff untuk menjawab dua buah problem berikut. Aturan pola baku yang dapat digunakan di .Seringkali. Status-nya harus demikian. Meniadakan pattern dengan exclamation point (!) Glob pattern adalah regular expression yang sering digunakan di shell. bracket dengan 2 buah character dengan tanda hyphen/dash di antaranya ( [0­9] ) cocok dengan character di antara 0 s/d 9. kemudian juga mengedit benchmark. Contoh : $ cat .gitignore *. Asterisk (*) untuk zero atau lebih character. dsb. Untuk direktori diakhir dengan / (slash) . Biasa pula disebut dengan wildcard. tmp atau direktori pid.a # sda kecuali lib. Glob standar yang biasa digunakan di lingkungan programming . [abc] cocok dengan salah satu character yang ada di dalam bracket.). Kita nanti akan membahasnya dengan lebih detail.gitignore adalah: . Marilah kita coba untuk mengedit README kembali.a /TODO # hanya mengabaikan TODO list di root. Untuk itu. git diff akan menghasilkan informasi yang tegas atas penambahan dan perubahan yang terjadi. Kita dapat mengabaikan berkas-berkas seperti log.gitignore. Apa yang telah kita modified tetapi belum staged? Dan apa yang telah staged dan siap untuk di commit? Apa yang dihasilkan git status masih sangat umum. Baris kedua bermakna agar git mengabaikan berkas-berkas yang diakhiri dengan tanda tilde (~) yang seringkali dihasilkan oleh banyak text-editor seperti Emacs sebagai berkas temporal. data file.a. Menciptakan dan nge-set . Atau bahkan memperlihatkannya sebagai untracked. . Baris blank atau baris-baris yang diawali dengan # . Seperti misalnya berkas-berkas yang secara otomatis tercipta pada saat run-time (log-file. dokumen-dokumen yang terbentuknya secara otomatis.gitignore sebelum bekerja dengan git adalah sebuah langkah yang cerdas. kita dapat menggunakan komando git diff. kita dapat membuat sebuah berkas yang berisi daftar berkas-berkas tersebut.a # abaikan berkas dengan character akhir a !lib.

. hanya perubahan yang masih unstaged saja.10 @@ def main @commit... Hal ini bisa membingungkan .6 +36. gunakan git diff tanpa argument. Chris Wanstrath + http://github. 15) log. Hasilnya akan memperlihatkan apa yang telah kita rubah tetapi belum staged. (Pada Git version 1.rb @@ ­36.$ git status # On branch master # Changes to be committed: # (use \”git reset HEAD <file>.parents[0]. $ git diff diff –­git a/benchmark.da65585 100644 ­­­ a/benchmark. 'commits 1') do git.1 dan setelahnya.0 +1..5 @@ +grit + by Tom Preston­Werner.rb # Untuk melihat yang telah kita rubah tetapi belum staged.commits. gunakan git diff ­– cached.rb b/benchmark.parents[0] end +  + + + run_code(x.commit('master'.com/mojombo/grit + +Grit is a Ruby library for extracting information from Git repository Penting untuk diingat bahwa git diff tidak menampilkan semua perubahan yang telah dibuat sejak commit kita yang terakhir.size Komando git diff membandingkan apa yang ada di dalam working area dan apa yang ada di staging area.” to update what will be committed) # # modified: benchmark.rb index 3cb7471. dapat juga digunakan git diff ­–staged. Jika kita ingin melihat apa saja yang telah staged dan siap untuk di-commit. 'commit 2') do log = git.” to unstage) # # new file: README # # Changed but not updated: # # (use “git add <file>.. yang lebih gampang diingat).size end run_code(x..rb +++ b/benchmark.03902a1 ­­­ /dev/nul +++ b/README2 @@ ­0.6.parents[0]. Komando berikut ini akan membandingkan apa saja yang telah staged dan yang telah kita commit : $ git diff ­–cached diff –­git a/README b/README new file mode 100644 index 0000000.

commits.86b2f7c 100644 ­­­ a/benchmark. kita dapat meng-commit perubahan-perubahan.4 @@ end  main() ##pp Grit::GitRuby.rb b/benchmark.rb dan kemudian mengeditnya. $ git add benchmark.rb @@ ­36.rb index 3cb747f. git diff tidak akan memberikan hasil apapun.parents[0] end + + + + run_code(x. 'commits 1') do git.e445e28 100644 ­­­ a/benchmark. semua yang masih unstaged.rb +++ b/benchmark.size Committing Perubahan Sekarang staging area telah ter-setup sesuai dengan keinginan kita.cache_client.rb +++ b/benchmark. 'commits 2') do log = git. Jika kita melakukan staging atas benchmark.parents[0]. $ git diff ­–cached dif –­git a/benchmark.rb @@ ­127. 15) log.size end run_code(x..rb index e445e28. Ingat.rb b/benchmark.rb $ echo '# test line' >> benchmark.rb # Untuk melihat yang masih unstaged dapat digunakan git diff. berkas-berkas yang telah dibuat dan dirubah . kita dapat menggunakan git diff untuk melihat perubahan dalam berkas dan perubahan yang unstaged. $ git diff diff –­git a/benchmark..rb # # Changed but not updated: # # modified: benchmark.parents[0].rb $ git status # On branch master # # Changes to be committed: # # modified: bencahmark.commits('master'.5 +36.stats +# test line dan git diff ­–cached untuk melihat yang telah staged.10 @@ def main @commit.3 +127.karena kita telah melakukan staging atas seluruh perubahan. Contoh lain.

Untuk diingat. Dan berapa jumlah berkas yang telah di commit. snapshot dari proyek kita akan direkam.rb ~ ~ ~ “.. git akan memanggil editor yang telah di -set sebelumnya sebagai editor standar git (dalam contoh ini vim). SHA-1 checksumnya adalah 463dc4f. Ketika exit dari editor. Apa saja yang tidak diletakkan di stage akan tetap sebagaimana adanya. Dengan cara ini maka kita telah menempatkan perubahan diff kita ke editor sehingga kita dapat dengan seksama melihat apa yang telah kita kerjakan. Setting-nya telah dibicarakan di chapter 1. and an empty message aborts the commit. 3 insertions (+). dapat diberikan option ­v pada git commit. untuk mengingatkan kepada kita apa yang telah kita rubah. Mereka akan tetap berstatus modified. Setiap kali dilaksanakannya sebuah commit. # Please enter the commit message for your changes. statistik perihal berapa jumlah baris yang ditambahkan dan berapa baris yang dihilangkan.editor. kita telah melakukan commit untuk yang pertama kali. Bisa juga dengan mengetikkan commit message sebaris dengan komando commit dengan menambahkan ­m flag sebagaimana terlihat berikut ini. Agar lebih eksplisit. Kita dapat melakukan commit lagi dan menambahkannya ke dalam history.. Kita juga telah melihat output yang dihasilkan oleh commit yang pada kasus ini diberlakukan untuk branch master. . git config – global core. semua berkas yang berstatus staged akan beralih status sebagai berkas yang telah di commit. Dengan git commit.  Editor yang bersangkutan (dalam hal ini adalah vim) akan menampilkan text sebagai berikut. $ git commit Begitu komando ini diberikan. bahwa rekaman perihal commit dan snapshot terletak di staging area. 0 deletations (­)  create mode 100644 README Sekarang.tetapi belum di git add sejak dirubah.” to unstage) # # (new file: README # modified: benchmark. 283C Terlihat bahwa defaultnya commit message berisi output terakhir dari komando git status yang di bagian atasnya dilengkapi dengan sebuah comment dan sebuah baris kosong. # On branch master # Changes to be committed: # (use “git reset HEAD <file>. Lines starting # with '#' will be ignored. git akan langsung melakukan commit dengan mencantumkan commit message kita serta menelanjangi diff. $ git commit ­m “Story 182: Fix benchmark for speed” [master]: created 463c4f: “Fix benchmark for speed”  2 files changed. tidak akan bisa di-commit. kita akan dapat melakukan revert atau compare terhadap setiap berkas yang ada di dalamnya. Dengan adanya snapshot. Comment tersebut dapat kita ganti dengan commit message kita sendiri atau dibiarkan apa adanya untuk membantu mengingat apa yang telah kita rubah pada saat meng-commit.git/COMMIT_EDITMSG” 10L.

 5 insertions(+). Cara seperti ini diharapkan dapat mencegah hilangnya berkas yang belum dicatat perubahannya di snapshot.. Menghapus Berkas Pada saat sebuah berkas yang berada di staging area dihapus. Berkas yang bersangkutan baru akan hilang dari daftar setelah diberikan komando git rm.gemspec rm 'grit. git tidak akan dapat melakukan recovery jika sampai terjadi hal yang demikian. Walaupun memiliki kegunaannya yang mengagumkan dalam membantu kita untuk melakukan commit dengan seksama. kadang-kadang alur kerja kita yang sederhana malah tidak perlu menggunakan staging area. $ git status # On branch master # # Changed but not updated: # #       modified:   benchmarks.gemspec $ git status # On branch master # # Changed but not updated: #   (use "git add/rm <file>. . berkas yang bersangkutan akan menghilang dan tidak akan lagi di-track.gemspec' $ git status # On branch master # # Changes to be committed: #   (use "git reset HEAD <file>. 0 deletions(­) Dengan cara seperti ini. Jika berkas yang bersangkutan telah dirubah dan sudah berada di dalam daftar. $ rm grit.. jika dilakukan commit.Skipping terhadap Staging Area.gemspec # Pada saat berikutnya." to update what will be committed) # #       deleted:    grit.." to unstage) # #       deleted:    grit. git akan mendeteksinya dan melaporkannya pada saat kita memberikan komando git status sebagai “Changed but not updated”.gemspec # Setelah diberi komando git rm: $ git rm grit. Kita bisa langsung melakukan commit seperti berikut ini.rb # $ git commit ­a ­m 'added new benchmarks' [master 83e38c7] added new benchmarks  1 files changed. Walaupun secara phisik sudah dihapus (dan bahkan telah di-commit sekalipun) berkas yang bersangkutan tetap akan berada di staging area dengan status deleted.. kita tidak perlu lagi melakukan git add. kita harus menghapusnya secara paksa dengan menambahkan opsi ­f.

txt $ git add README Walaupun demikian tentu saja lebih nyaman menggunakan satu komando saja daripada menggunakan tiga buah komando.log Komando di atas akan menghapus semua berkas di direktori log yang berekstensi . .gitignore atau tanpa sengaja meng-add sebuah berkas karena terikut pada saat kita nge-add berkas-berkas dalam jumlah besar secara sekaligus. Pada saat kita me-rename sebuah file. $ git rm ­­cached readme. $ git mv file_from file_to Contoh : $ git mv README.. tidak akan mencatat di dalam metadata sehingga git tidak dapat memberitahu kita akan perubahan ini. Memindahkan Berkas Tidak sebagaimana sistem VCS.log (perhatikan character back slash (\)) $ git rm \*~ Komando di atas akan menghilangkan semua berkas yang namanya diakhiri dengan tilde.txt Pada git rm juga dapat dilibatkan file-glob pattern untuk mem-filter. berkas yang bersangkutan secara phisik tetap berada di dalam hard drive tetapi git sudah tidak nge-track-nya lagi.Kita dapat pula menghapus berkas dari staging area tetapi tetap mempertahankannya agar tetap ada.txt ­> README # Bisa juga dengan … $ mv README. Tambahkan opsi –cached untuk kepentingan ini.txt README $ git rm README. # # Changes to be committed: #   (use "git reset HEAD <file>. $ git rm log/\*. Ini akan sangat berguna pada saat kita kelupaan memasukkan sebuah berkas ke daftar . Atau dengan kata lain.txt README $ git status # On branch master # Your branch is ahead of 'origin/master' by 1 commit. git tidak secara eksplisit melakukan track atas perpindahan berkas." to unstage) # #       renamed:    README. git dengan cukup cerdas mengantisipasi hal ini dengan komando mv.. Namun.