GI T D A S A R

BY : ZCHIPAN 2024
PENGENALAN GIT DASAR
• SAAT KITA MENGERJAKAN PERKERJAAN, KITA SERING SEKALI MELALUKAN REVISI, MISAL SAJA KITA
MEMBUAT DOKUMEN PROPSOAL ATAU SKRIPSI

• BIASA NYA KITA AKAN SIMPAN DOKUMEN PERTAMA DENGAN NAMADOCUMENT, SETELAH MENDAPATKAN
REVISI, KITA AKAN SIMPAN DENGAN NAMA_DOCUMENT2, JIKA MASIH ADA REVISI, KITA AKAN SIMPAN
DENGAN NAMA DOCUMENT_3, DAN SETERUS NYA

• KENAPA KITA LAKUKAN HAL TERSEBUT? AGAR KITA BISA MENGETAHUI PERUBAHAN YANG TERJADI
ANTAR REVISI DOCUMENT, DAN JIKA SEWAKTU WAKTU KITA PERLU ... KITA BISA MENGGUNAKAN REVISI
SEBELUM NYA, KITA BISA MENGGUNAKAN NYA DENGAN MUDAH
VERSION CONTROL
• VERSION CONTROL ADALAH SEBUAH SYSTEM YANG MEREKAM PERBUAHAN PADA FILE DARI WAKTU KE WAKTU
SEHINGGA KITA BISA MELIHAT VERSI SEBELUM NYA

• VERSION CONTROL SANGAT POPULAR DI KALANGAN PROGRAMMER, KARENA PROGRAMMER SELALU MEMBUAT
CODE PROGRAM DALAM BENTUK TULISAN, DENGAN VERSION CONTROL INI PROGRAMMER BISA MEREKAM SEMUA
PERUBAHAN YANG TERJADI, SEHINGGA JIKA TERJADI KESALAHAN, PROGRAMMER BISA DENGAN MUDAH KEMBALI KE
VERSI SEBELUM NYA

• TAPI TIDAK HANYA UNTUK FILE DALAM BENTUK TEXT, JIKA MISAL KITA ADALAH SEORANG GRAPIC DESIGNER, KITA
JUGA BISA MEMANFAATKAN VERSION CONTROL UNTUK MEREKAM PERBUAHAN DARI FILE GAMBAR ATAU LAYOUT,
SEHINGGA KITA TIDAK PERLU MEM-BACKUP TIAP PERUBAHAN SECARA MANUAL
JENIS VERSION CONTROL
• SECARA GARIS BESAR, VERSION CONTROL DI • LOCAL VERSION CONTROL
BAGI MENJADI 3 JENIS
• CENTRALIZED VERSION CONTROL
• DESTRIBUTED VERSION CONTROL
LOCAL VERSION CONTROL

• LOCAL VERSION CONTROL MERUKAN VERSION CONTROL YANG BERJALAN HANYA DI LOCAL KOMPUTER
SAJA

• PENDEKATAN INI BISA DI GUNAKAN KARENA SEDERHANA DAN TIDAK BUTUH SERVER, KARENA SEMUA
RIWAYAT PEKERJAAN SI SIMPAN DI LOCAL KOMPUTER

• SETIAP PERUBAHAN VERSI YANG TERJADI PADA FILE HANYA DI SIMPAN DI LOCAL KOMPUTER
GAMBARAN LOCAL VERSION CONTROL

FILE
VERSION_3

VERSION_3

VERSION_3
CENTRALIZED VERSION CONTROL
• MASALAH YANG SERING TERJADI PADA LOCAL VERSION CONTROL ADALAH, JIKA KOMPUTER RUSAK, MAKA SELURUH DATA BISA HILANG

• SELAIN ITU AGAK SULIT UNTUK BERKOLABORASI DENGAN PENGGUNA LAIN JIKA FILE HANYA ADA DI SATU KOMPUTER

• UNTUK MENANGANI MASALAH INI, KITA BISA MENGGUNAKAN CENTRALIZED VERSION CONTROL

• PENGGUNA BISA AKSES DATA KE SERVER UNTUK MELIHAT FILE

• KEKURANGAN NYA ADALAH, JIKA PENGGUNA OFFLINE, MEREKA TIDAK BISA BISA MELIHAT RIWAYAT FILE KARENA SEMUA RIWAYAT FILE
HANYA ADA SI SERVER ( HARUS ONLINE )

• TERUS JIKA SERVER NYA DOWN, MAKA SELURUH PENGGUNA TIDAK BISA MELAKUKAN PERUBAHAN DAN MELIHAT REVISI FILE NYA

• CONTOH CENTRALIZED VERSION CONTROL ADALAH SUBVERSION

GAMBARAN LOCAL VERSION CONTROL
VERSION CONTROL SERVER

COMPUTER 1
VERSION_3
FILE 1

VERSION_3

COMPUTER 2 VERSION_3

FILE 1
DISTRIBUTED VERSION CONTROL
• DISTRIBUTED VERSION CONTROL VERSION ADALAH ALTERNATIF DARI CENTRALIZED VERSION CONTROL
• DALAM DVCS, CLIENT TIDAK HANYA MENGAMBIL FILE VERSI TERAKHIR, NAMUN SELURUH RIWAYAT REVISI
DI COPY SELURUH NYA

• HAL INI MENJADIKAN JIKA TERJADI MASALAH DENGAN SERVER, CLIENT MASIH TETAP BEKERJA,
MEMANIPULASI FILE, SAMPAI MELIHAT RIWAYAT PERUBAHAN

• BAHKAN DALAM DVCS, SERVER BISA LEBIH DARI SATU, KARENA SETIAP SERVER ISINYA SAMA SEMUA MAKA
FULL BACK UP DATA

• CONTOH DISTRIBUTED VERSION CONTROL ADALAH *GIT, MERCURIAL, DAN YANG LAIN NYA
GAMBARAN LOCAL VERSION CONTROL
COMPUTER 1 COMPUTER 3
FILE 1 FILE 1

COMPUTER 2 NOTE : FULL VERSION ADALAH VERSI REVISI

TERAKHIR, ( DI IBARATKAN )
FILE 1
GIT DISTRIBUTION VERSION CONTROL
SEJARAH GIT
• GIT MUNCUL DENGAN LATAR OPEN SOURCE LINUX KERNEL
• TAHUN 1991-2002, LINUX KERNEL DI DEVELOP HANYA MENGGUNAKAN PATCH DAN ARHIVED FILES
• DI TAHUN 2002, LINUX MULAI MENGGUNAKAN DVCS BERNAMA BIT KEEPER
• DI TAHUN 2005, HUBUNGAN ANTAR PERUSAHAAN PEMILIK BIT KEEPER DENGAN KOMUNITAS LINUX KERNEL
KURANG BAIK, SEHINGGA PEMBUAT LINUX, LINUS TORVALDS MULAI MEMBUAT DVCS SENDIRI

• NAH MUNCUL LAH GIT, GIT DI POPULERKAN KAN DI KENAL KAN PADA TAHUN 2005, SEMAKIN KESINI GIT
SEMAKIN POPULER DAN SEKARANG MENJADI DISTRIBUTION VERSION CONTROL PALING TERKENAL DI DUNIA
PENGENALAN GIT
• JADI GIT ADALAH SALAH SATU DVCS YANG ADA

• GIT TIDAK MEMBUTUHKAN SERVER, UNTUK MELAKUKAN PERUBAHAN ATAU MELIHAT REVISI, HAL INI DI KARENA KAN
DALAM GIT, SEMUA RIWAYAT PROJECT AKAN SELALU DI PUBLIKASI KAN, BAIK ITU SERVER ATAU PUN LOCAL COMPUTER

• ARTINYA SEBENERNYA GIT JUGA BISA DI GUNAKAN SEBAGAI LOCAL VERSION CONTROL

• SETIAP PERUBAHAN SELALU ADA TANDA SIGNATURE JIKA ADA PERUBAHAN KARENA DALAM GIT MENGGUNAKAN
ALGORITMA SHA-1, HAL INI MENJADIKAN PERUBAHAN SEKECIL APAPUN PASTI TERDETEKSI OLEH GIT

• SEMUA HAL YANG TERJADI DI GIT SECARA OTOMATIS AKAN DI CATAT, HAL INI MENJADIKAN PERUBAHAN APAPUN DI GIT,
PASTI SELALU BISA DI KEMBALIKAN KE VERSI SEBELUM NYA
MENGINTSTALL GIT

• HTTPS://GIT-SCM.COM/DOWNLOADS
MAKE SURE GIT JIKA SUDAH ADA

• CARI GIT BASH

• KEMUDIAN KETIKAN PERINTAH GIT –VERSION
• JIKA NOT COMMAND BERARTI BELUM ADA
GIT WITH VISUAL STUDIO

• CTRL + SHIFT + P
• KEMUDIAN KETIKAN PERINTAH INSTALL CODE
• JIKA SUDAH ADA TIDAK USAH
GIT CONFIGURATION
ADD NAME DAN EMAIL

• UNTUK MENAMBAHKAN EMAIL DAN NAME KITA BISA MENGGUNAKAN

• GIT CONFIG –GLOBAL USER.NAME “ZCHIPAN”
• GIT CONFIT –GLOBAL USER.EMAIL [email protected]
• INI BERTUJUAN JIKA ADA YANG NGEDIT ATAU PUN YANG MENAMBAHKAN FILE DAN YANG LAIN NYA BISA
TAHU
REPOSITORY

• REPORSITORY ADALAH BISA DI SEBUT FOLDER ATAU PUN PROJECT

• KITA BISA MEMBUAT FOLDER KOSONG ATAU FOLDER YANG BERISIKAN FILE, LALU MEMBUATNYA SEBAGAI
GIT REPOSITORY

• ATAU BISA MELAKUKAN GIT CLONE YANG SUDAH ADA DARI SERVER GIT NYA
MEMBUAT REPOSITORY
• UNTUK MEMBUAT REPOSITORY KITA MENGGUNAKAN PERINTAH SINTAK..
• GIT INIT
• DAN KALO INGIN MELALUKAN NYA, LAKUKAN DI FOLDER YANG INGIN KITA BUAT MENJADI REPO
• UNTUK MENGECEK NYA KITA BISA LIHAT MENGGUNAKAN CMD
• DIR KEMUDIAN LS ATAU –LS
• DAN DI DALAM NYA ADA SEBUAH FILE NAMANYA .GIT
• ATAU BISA DI BUKA SAJA SI .GIT NYA DENGAN CD
MEMBUAT REPOSITORY

• JIKA SUDAH KITA BISA MENGGUNAKAN CODE . UNTUK MEMBUKA REPO NYA DI VISUAL STUDIO CODE
FUNGSI GIT STATUS

• FUNGSI GIT STATUS ADALAH MELIHAT REPO JIKA ADA PERUBAHAN ATAU PUN ADA FILE YANG BELUM
COMMIT
WORKFLOW
ALUR KERJA DENGAN GIT
THE TREE STATES
• DI DALAM GIT ADA ISTILAH YANG NAMANYA MODIFED, STAGED, COMMITED
• MODIFED ADALAH ( MENGUBAH, MENGHPAUS ATAU MENGEDIT ) PADA FILE, NAMUNNN BELUM DI SIMPAN
SECARA PERMANENT DI REPOSITORY

• STAGED ARTINYA KITA MENANDAI MODIFED YANG SUDAH DI BUAT YANG NANTI NYA AKAN KE REPOSITORY
DI SIMPAN SECARA PERMANEN

• COMMITED ARTINYA DATA SUDAH DI SIMPAN DI REPOSITORY

3 TAHAP
• BERARTI ADA 3 TAHAP YANG HARUS DI PAHAMI
• PERTAMA ADA TAHAP WORKING ADALAH TAHAPAN YANG KITA MODIFIKASI FILE ( MODIFED )
• KEDUA ADA TAHAP STAGING AREA MERUPAKAN SECTION DIMANA FILE SUDAH DISIAPKAN UNTUK
SECARA PERMANEN, DI STAGING AREA SEMUA INFORMASI MODIFED AKAN DI SIMPAN ( TAHAPAN
PERSIAPAN )

• KE TIGA ADA TAHAP REPO ATAU COMMIT TEMPAT DIMANA SEMUA FILE DAN DATA BASE RIWAYAT DI
SIMPAN
3 TAHAP
PENERAPAN WORKFLOW DI GIT

• JADI SECARA SEDERHANA NYA, SETIAP PERUBAHAN KITA LAKUKAN DI WORKFLOW

• KALO MAU PERSIAPAN SECARA PERMANEN KITA SIMPAN DI STAGING
• DAN KEMUDIAN PENYIMPANAN TERSEBUT SECARA PERMANEN KITA KE REPOSITORY IN
PENERAPAN WORKFLOW DI GIT
TAHAP PERTAMA TAHAP KE DUA
PENERAPAN WORKFLOW DI GIT
TAHAP PERTAMA TAHAP KE DUA

RIWAYAT VERSI SEBELUM NYA

HASH DAN SNAPSHOT
PERUBAHAN YANG TERJADI KETIKA SUDAH DI COMMIT
SNAPSHOT ..

• SEBENERNYA TIDAK ADA VERSI DALAM GIT YANG ADA ADALAH PERUBAHAN
• SEMUA PERUBAHAN YANG TERJADI AKAN DI REKAM, DAN ITU YANG DI SEBUT SNAPSHOT
• SNAPSHOT BERISIKAN SEMUA PERUBAHAN YANG TERJADI DI SEMUA FILE YANG KITA KOMIT
• DAN HASIL NYA AKAN MEMBUAT HASH
HASH
• OKE KITA TAHU KALAU KOMIT AKAN MEMBUAT HASH
• JADI KETIKA SUDAH HASH AKAN TERLIHAT INDENTITAS SNAPSHOT NYA
• GIT MELAKUKAN ALGORITMA SHA-1 UNTUK MENGHITUNG HASH
• HASH DIBUTUHKAN UNTUK MENJAGA DATA INTERGRITY, SEHINGGA TIAP SNAPSHOT YANG SUDAH DI
LAKUKAN TIDAK BISA DI UBAH

• CONTOH HASH GIT SEPERTI NOMOR ACAK : 38297JFGHA872938HJKSADGF

HASH
HASH

• DI ATAS KITA SUDAH TAHU INI ADA AUTHOR DAN MESSAGE

• NAH RETURN DARI SI HASH ITU ADALAH ITU
• TERUS BAGAIMANA KALO MISALKAN HASH KEDUA 1 DI UBAH ? INI AKAN MENIMBULKAN EFEK BERANTAI
KARENA SEMUA HASH AKAN BERUBAH
PERHITUNGAN HASHING

• PERHITUNGAN HASH DI LAKUKAN TIDAK HANYA DARI PERUBAHAN FILE

• NAMUN JUGA DARI PARENT, AUTHOR DAN MESSAGE
• ARTINYA PERUBAHAN YANG TERJADI PADA SNAPSHOT SEBELUMNYA, MAKA AKAN MENGAKIBATKAN DAN
MENIMBULKAN EFEK BERANTAI, KARENA SEMUA HASH SELANJUTNYA AKAN BERUBAH

• OLEH KARENA ITU, HAL TERSEBUT TIDAK BISA DI LAKUKAN OLEH GIT
HEAD

• HEAD MERUPAKAN POINTER MENUJU HASH YANG PALING AKHIR

• KARENA KADANG SANGAT MENYULITKAN JIKA HARUS, MENULIS HASH VALUE, JIKA KITA MENUJU HASH
PALING BARU, KITA BISA MENGGUNAKAN HEAD
HEAD
ADD FILE / MENAMBAH FILE

UNTUK MENAMBAH FILE DI REPO

MENAMBAHKAN FILE KE WORKING

• UNTUK MENAMBAHKAN FILE BARU DI REPO, KITA CUKUP TAMBAHKAN FILE NYA SAJA
• SECARA OTOMATIS FILE YANG KITA TAMBAHKAN AWALNYA AKAN BERADA DI WORKING DIRECTORY
• SECARA DEFAULT SAAT MENAMBAHKAN FILE BARU, FILE TERSEBUT TIDAK AKAN DI TRACK PERUBAHAN
NYA

• AGAR DAPAT DI TRACK KITA TAIKIN DULU KE STAGING INDEKS

MENAMBAHKAN FILE KE WORKING

• OHH IYAHH, JANGAN LUPA PAKAI GIT STATUS KALAU SUDAH DI TAMBAHKAN
MENAMBAHKAN FILE KE WORKING
MENAMBAHKAN FILE KE WORKING
MENAMBAHKAN FILE KE STAGING INDEX

• KITA SUDAH MENAMBAHKAN FILE KE WORKING DIRECTORY

• KITA SUDAH TAHU KALO DI WORKING DIRECTORY ITU KITA BELUM MELAKUKAN PENGETEST AN
• JADI KITA NAIKIN KE STAGING DENGAN SINTAKS
• GIT ADD ( NAMA FILE )
• DAN KEMUDIAN GIT STATUS UNTUK MENGECEK SUDAH DI NAIKIN ATAU BELUM NYA
MENAMBAHKAN FILE KE STAGING INDEX
MENAMBAHKAN FILE KE REPO

• TAHAP SELANJUT NYA KALO SUDAH DI CEK SUDAH BENER DAN KITA SIMPAN PERMANEN KITA PINDAHKAN
KE REPO DENGAN SINTAK

• GIT COMMIT –M “MENAMBAHKAN FILE TEXT”

MENAMBAHKAN FILE KE REPO
MENAMBAHKAN FILE KE REPO
EROR MENAMBAHKAN FILE KE REPO
Jika eror un coment yang di modife
MENGUBAH FILE KE REPO
CARA MENGUBAH DARI REPO KEMUDIAN COMMIT
MENGUBAH FILE

• UNTUK MELAKUKAN PERUBAHAN FILE, KITA CUKUP LAKUKAN PERUBAHAN FILE TERHADAP FILE YANG
SUDAH ADA DI REPOSITORY

• SECARA OTOMATIS GIT SUDAH MENDEKTEKSI PERUBAHAN

• SAMA SEPERTI DENGAN MENAMBAHKAN FILE, JIKA PERUBAHAN INGIN KITA SIMPAN SECARA PERMANEN,
KITA BISA PINDAHKAN KE STAGING  LALU KE COMMIT KE REPO
MENGUBAH FILE

• MISALKAN KITA AKAN MENAMBAHKAN FILE BARU TEXT KEMDIAN KITA UBAH KATA BARIS BARU DI
SETIAP FILE NYA

• UDH GTH KITA NAIKIN KE STAGING DAN KEMUDIAN COMMIT KE REPO

MENGUBAH FILE
MENGUBAH FILE
MENGUBAH FILE DAN UP KE STAGING INDEKS

• DI ATAS SUDAH TERDETEKSI BAHWA FILE 1 DAN 2 DI MODIF DAN FILE 3 DI TAMBAHKAN
• JIKA INGIN NAIKIN KE STAGE SATU SATU KITA BISA MENGGUNAKAN PERINTAH GIT ADD NAMA_FILE_1
NAMA_FILE_2 ( CUKUP DENGAN SPASI )

• NAMUN JIKA COMMIT SEMUA NYA KITA BISA MENGGUNAKAN GIT ADD .
MENGUBAH FILE DAN UP KE STAGING INDEKS
MENGUBAH FILE DAN COMMIT KE REPO

• JIKA KALO SUDAH DI MAKE SURE BENAR KITA BISA UP IN KE REPO DENGAN MENGGUNAKAN SINTAK
BIASA GIT COMMIT –M “ PESAN NYA APA “

• JIKA KALO BELUM KITA BISA MENGGUNAKAN GIT RESTORE --STAGED TEST3.TXT
MENGUBAH FILE DAN COMMIT KE REPO
MENGUBAH FILE DAN COMMIT KE REPO
DELET FILE / MENGHAPUS FILE
MENGHAPUS FILE YANG ADA DI REPO
MENHAPUS FILE

• UNTUK MENGHAPUS FILE, SEBENERNYA SIH TINGGAL HAPUS SAJA FILE NYA
• SECARA OTOMATIS GIT AKAN MENDETEK ADA FILE YANG DI HAPUS
• TAPII SAMAAA SEPERTI MENGUBAH KITA HARUS MENHAPUS DULU DARI WORK DIRECTORY KEMUDIAN
DI UP KE STAGING INDEKS DAN KEMUDIAN COMMIT KE HAPUS

• MISALKAN KITA HAPUS FILE TEST 3

MENHAPUS FILE
MENHAPUS FILE
MENHAPUS FILE
 MEMBATALKAN PERBUAHAN

MEMBATALKAN SEMUA JENIS PERUBAHAN MAU ITU HAPUS, MAU ITU MODIF ATAU PUN SUDAH NAIK KE STAGE DAN
SUDAH COMMIT
MEMBATALKAN JIKA SUDAH TAMBAH FILE

• JIKA KITA SUDAH MENAMBAHKAN FILE DI WORKING DIRECTORY, LALU MISALKAN KITA INGIN
MEMBATALKAN PERUBAHAN NYA

• CARANY CUKUP SEDERHANA, KITA HANYA PERLU MENGHAPUS FILE TERSEBUT ATAU MENGGUNAKAN,
PERINTAH BERIKUT :

• GIT CLEAN –F
MEMBATALKAN JIKA SUDAH TAMBAH FILE
MEMBATALKAN JIKA SUDAH EDIT TERTENTU

• SEBELUM NYA KITA MELAKUKAN PERUBAHAN JIKA KITA SUDAH MEMBUAT SEBUAH FILE
• SEKARANG BAGAIMANA MEMBATALKAN JIKA SUDAH DI EDIT TERTENTU ?
• KITA BISA MENGGUNAKAN SINTAK YANG NAMANYA :
• GIT RESTORE NAMAFILE
• MISALKAN SAYA SUDAH MENAMBAHKAN GARIS DBAGIAN TEST, NAMUN SAYA AKAN MEMBATALKAN EDIT
NYA
MEMBATALKAN JIKA SUDAH EDIT TERTENTU
MEMBATALKAN PENGHAPUSAN FILE

• SEBENERNYA SAMA SAJA MENGGUNAKAN SINTAK GIT RESTORE CUMAN ADA PEMBERETIHUAN DELET
MEMBATALKAN PENGHAPUSAN FILE
MEMBATALKAN DARI STAGING INDEX
• KITA SUDAH TAHU BEBERAPA TADI DI ATAS, NAMUN ITU DI WORKING DIRECTORY
• BAGAIMANA CARANYA MEMBATALKAN DI STAGING INDEKS ?
• KITA HARUS MENGEMBALIKAN POSISI TERAKHIR STAGING INDEKS NYA, ARTINYA NIHH KALO KAMU MISALKAN
MEMBATALKAN PADA SUATU FILE KAMU HARUS TURUN KAN DULU KE WORKING DIRECTORY DAN KEMUDIAN UP
IN LAGI KE STAGING

• DENGAN SINTAK NYA

• GIT RESTORE –STAGED NAMAFILE
• MISALKAN KITA AKAN MENGHAPUS FILE YANG ADA SI STAGING KEMUDIAN KITA EDIT
MEMBATALKAN DARI STAGING INDEX
MEMBATALKAN DARI STAGING INDEX
MEMBATALKAN YANG SUDAH DI COMMIT ATAU DI
REPO

• SEBENERNYA TIDAK BISA MEMBATLKAN YANG SUDAH ADA DI REPO ATAU DI COMMIT
• JIKA KALO EMNG MAU DI UBAH BISA MENGGUNAKAN DUA CARA YAITU ROLLBACK COMMIT DAN REVERSE
COMMIT

• MATERI NTAR ADA DI BAWAH

COMMITE LOG

HISTORY PADA LOG COMMIT

COMMITE LOG
• GIT ADALAH DISTRUBUTION CONTROL, ARTINYA SETIAP KITA MENGUBAH REPOSITORY KITA DI LOCAL,
SEMUA RIWAYAT AKAN TERDETEK DI KOMPUTER KITA JUGA

• KURANG NYA JIKA TERADAPAT DI LOCAL ARTINYA DI KOMPUTER KITA BERARTI RIWAYAT AKAN TERUS
TAMBAH DAN AKAN MEMAKAN PENYIMPANAN ( BERTAMBAH BERAT )

• UNTUK MELIHAT COMMITE LOG, KITA BISA MENGGUNAKAN SINTAKS :

• GIT LOG
• JIKA INGIN KELUAR PENCET “ Q “
COMMITE LOG
COMMITE LOG SEDERHANA

• JIKA KALO MEMANG SUDAH BANYAK YANG COMMIT ITU AKAN RIBET TAMPILAN NYA
• KITA BISA MENGGUNAKAN SINTAK :
• GIT LOG –ONELINE
COMMITE LOG SEDERHANA
COMMIT LOG BRANCHING

• SAAT NANTI KITA SUDAH BELAJAR GIT BRANCHING, KADANG KITA INGIN MELIHAT COMMIT LOG “ DENGAN
COMMIT HUBUNGAN YANG LAIN NYA “

• HAL INI BISA LAKUKAN DENGAN SINTAKS :

• GIT LOG –ONELINE –GRAPH
• BTW KARENA BELUM BELAJAR BRANCH MAKANYA TAMPILAN NYA AKAN SEPERTI BISA
COMMIT LOG BRANCHING
COMMIT LOG BRANCHING KOMPLEKS

• SAAT NANTI KITA SUDAH BELAJAR GIT BRANCHING, KADANG KITA INGIN MELIHAT COMMIT LOG “ DENGAN
COMMIT HUBUNGAN YANG LAIN NYA “

• HAL INI BISA LAKUKAN DENGAN SINTAKS :

• GIT LOG –ONELINE –GRAPH
• BTW INI CONTOH YANG KOMPLEKS
COMMIT LOG BRANCHING KOMPLEKS
DETAIL COMMIT LOG

• CARA AGAR INGIN MELIHAT PERUBAHAN DETAIL YANG TERJADI PADA COMMIT
• UNTUK MELAKUKAN NYA, KITA BISA MENGGUNAKAN DENGAN CARA GIT SHOW HASH
• SEBELUM NYA SETIAP COMMIT MEMPUNYAI HASH NYA KAN
DETAIL COMMIT LOG
 GIT COMPARE

MENGECEK DAN MELAKUKAN COMPARE DARI HEADING ( PERUBAHAN TERAKHIR DENGAN PERUBAHAN SEBELUM NYA )
GIT COMPARE COMMIT
• GIT MEMLIKI FITUR UNTUK MEMBANDINGKAN ANTAR COMMIT DENGAN COMMIT YANG LAINNYA
• NAMUN JANGAN SAMPAI SALAH PERNGERTIAN, MEMBANDINGKAN DISINI ADALAH MEMBANDINGKAN
SNAPSHOT HASIL COMMIT, BUKAN PERUBAHAN YANG TERJADI ANTAR COMMIT

• MISALKAN PADA COMMIT SEBELUMNYA KITA MENAMBAHKAN FILE TEST3, NAMUN JIKA KITA
BANDINGKAN DENGAN ANTARA COMMIT PERTAMA DENGAN COMMIT TERAKHIR ( HEAD ), HASILNYA YA
PERBANDINGAN FILE 1 DAN DAN FILE TIDAK ADA FILE 3
GIT COMPARE COMMIT
GIT COMPARE COMMIT

• JADI BUKAN MEMBANDINGKAN TAPI LEBIH TEPAT NYA MEMBANDINGKAN COMIT ATAU SNAPSHOT
KESELURUHAN DARI COMIT TERSEBUT

• OKE SAYA AKAN GIT COMPARE ( AKHIR DARI COMIT PERTAMA DAN TERAKHIR YAITU HEAD )
• MENGGUNAKAN GIT –DIF ( KOMIT PERTAMA ) HEAD
GIT COMPARE COMMIT
GIT COMPARE COMMIT

• OKE KITA BISA MELAKUKAN COMMIT PERTAMA DAN AKHIR,

• NAMUN BAGAIMANA MEMBANDINGKAN COMMIT AKHIR DAN SEBELUM NYA ?
• KITA AMBIL DULU HASH COMIT SAMEMEH AKHIR DAN DENGAN HEAD
GIT COMPARE COMMIT
GIT COMPARE COMMIT DENGAN DIFTOOL

• SEBELUM NYA KITA SUDAH MELAKUKAN PENGATURAN MENGGUNAKAN VISUAL STUDIO CODE KAN YA, DI
DALAM PENGATURAN ITU KITA MELAKUKAN DIFFTOOL

• JIKA KITA INGIN MELAKUKAN PERBEDAAN MENGGUNAKAN COMMIT DIFTOOL

• KITA BISA MELAKUKAN DENGAN SINTAK :
• GIF DIFTOOL HASH1 HASH2
GIT COMPARE COMMIT DENGAN DIFTOOL

• SEBENERNYA FUNGSI DARI COMMIT DIFTOOL INI MEMPERMUDAH TEMAN TEMAN YANG NANTI NYA MAU
COMPARE LEWAT VISUAL STUDIO JIKA SUDAH DI SETTING
GIT COMPARE COMMIT DENGAN DIFTOOL
 RENAME FILE

KETIKA KITA MENGUBAH NAMA FILE OTOMATIS GIT AKAN MENDETEKSI BAHWA RENAME FILE TERSEBUT DI HAPUS
TERLEBIH DAHULU
RENAME FILE
• HAL YANG MENARIK PADA GIT ADALAH GIT BISA MENDETEKSI RENAME FILE
• SECARA SEDERHANA NYA ADALAH RENAME FILE ADALAH OPERASI GABUNGAN ANTAR HAPUS FILE LALU
KEMUDIAN DI TAMBAHKAN

• NAMUN GIT BISA OTOMATIS MENDETEKSI JIKA ADA PERUBAHAN FILE, KARENA ISI SEBAGIAN BESAR
MASIH SAMA

• MISALKAN SAYA MAU UBAH NAMA TEST3 MENJADI TEST_3

RENAME FILE
RENAME FILE
 RESET COMMIT

TERKADANG KITA INGIN ME RESET ATAU MENGEMBALIKAN VERSI YANG SEBELUMNYA DARI REPO, MAU ITU KEMBALI
KAN KE STAGING, MAU ITU KEMABALIKAN KE WORKING, DAN MAU ITU KEMBALI KAN KE DUA DUA NYA
RESET COMMIT

• RESET COMMIT ADALAH MENGGERSERKAN POINTER HEADER KE POSISI COMMIT YANG KITA MAU
• BAYANGKAN JIKA HEADER ADA BEBERAPA COMMIT
• KITA TAHU JUGA KAREKTIRSTIK DARI POINTER HEADER ITU PASTI DI PALING AKHIR
RESET COMMIT
RESET COMMIT SOFT
• --SOFT, MEMINDAHKAN POINTER, NAMUN TIDAK MELAKUKAN PERUBAHAN APAPUN DI STAGING INDEKS, JADI
MENGEMBALIKAN DARI REPO DOANG

• ARTINYA DI STAGING ITU TIDAK TERHAPUS PERBUHAN NYA

• SAYA MAU KEMBALI KAN REPO KE VERSI SEBELUMNYA, ARTINYA POINTER HEADER DI KEMABALIKAN KE COMMIT YANG MANA,
TERUS STAGING NYA ENGGA

• MISALKAN KITA TADI MENGUBAH SI FILE TEST3 NAHH DI DALAM STAGING NYA TIDAK MENGUBAH APAPUN, TAPI YA DI DALAM
SI REPO NYA MUNDUR

• SINTAK NYA SEPERTI INI :

• GIT RESET –SOFT HASHCODE

RESET COMMIT SOFT

• TAPI GMNA CARA NGEMBALIIN NYA LAGI ? YA UDH SAMA SAJA HASH CODE NYA APA, TERUS JANGAN
SAMPAI LUPA HASH CODE NYA APA
RESET COMMIT SOFT
RESET COMMIT SOFT
RESET COMMIT MIXED
• MIXED ATAU DEFAULT NYA HEADER POINTER, MENGUBAH STAGING MENJADI SAMA DENGAN REPOSITORY,
NAMUN TIDAK MENGUBAH APAPAPUN DI WORKING DIRECTORY NYA

• KALO DI ATAS ATAU MENGGUNAKAN SOFT KITA BISA LIHAT BAHWA PERUBAHAN NYA TIDAK SAMPAI
DENGAN COMMIT BARU DI UP DI STAGING STATUS NYA

• KALO INI IBARATNYA BARU MAU UP KE STAGING

• SINTAK NYA :
• GIT RESET –MIXED HASHCODE
RESET COMMIT MIXED
RESET COMMIT HARD

• NAH KALAU GIT RESET COMMIT HARD ITU MERESET SEMUA DARI MAU UP IN KE STAGING KE MAU DI UP
IN KE REPO KE MAU DI WORKING JUGA KE POKOK NYA DI RESET SEBELUM NYA

• SINTAK NYA
• GIT RESET –HARD HASHCODE
RESET COMMIT HARD
RESET COMMIT HARD
Si file nya kereset juga yang tadi nya underscore sekarang engga
RESET COMMIT

• INTINYA SOFT ADA DI STAGING INDEKS BELUM NAIK KE REPO

• INTINYA MIXED ADA DI WORKING DIRECTORY BELUM NAIK KE STAGING
• INTINYA HARD HAPUS SEMUA NYA
AMEND COMMIT

MENGEMBALIKAN SESUATU
AMEND COMMIT

• KADANG KETIKA KITA COMMIT ADA YANG LUPA

• OTOMATIS KITA KEMBALIKAN DENGAN RESET COMMIT SOFT, KEMUDIAN KITA LAKUKAN COMMIT ULANG
• NAH KALO INI AKAN MEMAKAN WAKTU JADINYA KITA BISA MEMAKAI DAN MENGGUNAKAN AMEND
COMMIT, SECARA OTOMATIS SNAPSHOT AKAN DI GANTI YANG TERAKHIR HASH NYA PUN AKAN BERUBAH

• DARI PADA KITA BIKIN HASH LAGI

AMEND COMMIT
• MISALKAN KITA AKAN MENAMBAH FILE BARU TERUS MASUKAN KE STAGING DAN KEMUDIAN MASUKAN
KE REPO

• EPEK TEH ADA YANG LUPA MISALKAN ADA YANG INGIN DI UBAH
• TAPI KITA BIKIN COMMIT NYA COMMIT YANG TERAKHIR SAJA GA MAU COMMIT YANG BARU LAGI
• YA UDH TINGGAL MENGGUNAKAN SINTAK :
• GIT COMMIT –AMEND –M “BLA BLA BLA”
AMEND COMMIT
AMEND COMMIT
AMEND COMMIT

• YANG TADI DI ATAS ARTINYA DI MERGE DAN SNAPSHOT NYA AKAN BERUBAH OTOMATIS HASHING NYA
JUGA BERUBAH
 VERSI SEBELUM NYA

KADANG KITA MENGALAMI MASALAH DENGAN FILE YANG SUDAH ADA DI REPO
VERSI SEBELUM NYA
• TERKADANG KITA MEMBUTUHKAN VERSI VERSI SEBELUMNYA
• KALO HEAD OTOMOTIS DI PALING AKHIR KAN
• TAPI KADAN KITA MEMBUTUHKAN WAKTU DI COMMIT SEKIAN ITU PERUBAHAN NYA APA SAJA SIH
• SAAT KITA AMBIL VERSI SEBELUMNYA, FILE COMMIT TERSEBUT ADA DI STAGING INDEKS
• KITA BISA MENGGUNAKAN SINTAK :
• GIT CHECKOUT HASH –NAMAFILE
VERSI SEBELUM NYA

• MISALKAN KITA MAU KE COMMIT PERUBAHAN FILE TEST 1

• KITA PINGIN TAHU APA SAJA SIH PERUBAHAN NYA
VERSI SEBELUM NYA
SNAPSHOOT SEBELUM NYA

MESIN WAKTU DIMANA KITA BISA KEMBALI KE SNAPSHOT SEBELUM NYA

SNAPSHOOT SEBELUM NYA

• GIT MEMILIKI FITUR SEPERTI MESIN WAKTU, DIMANA KITA BISA KEMBALI KE SNAPSHOOT SEBELUM NYA
• KITA BISA MENENTUKAN KEMANA TUJUAN SNAPSHOT YANG INGIN KITA KEMBALI
• BEDA SAMA RESET KAN, TOTAL BERAPA DI HAPUS FILE DAN YANG LAIN NYA
• KETIKA INGIN KEMBALI MENGGUNAKAN SNAPSHOOT INI KITA BISA MELAKUKAN GIT CHECKOUT MASTER
• MASTER ADALAH NAMA HEAD YANG TERAKHIR
SNAPSHOOT SEBELUM NYA
SNAPSHOOT SEBELUM NYA

• KITA AKAN KEMBALI KE 1EE5FF3 HAPUS FILE TEST 3

• DENGAN MENGGUNAKAN SINTAK
• GIT CHECKOUT HASH
SNAPSHOOT SEBELUM NYA
SNAPSHOOT SEBELUM NYA
Jika ingin kembali
REVERT COMMIT
• GIT MEMILIKI FITUR REVERT COMMIT, YAITU FITUR UNTUK MEMBATALKAN COMMIT YANG SUDAH KITA
LAKUKAN DENGAN CARA MEMBUAT COMMIT BARU YANG MEMBATALKAN COMMIT SEBELUM NYA

• MISALKAN KITA SUDAH MELAKUKAN COMMIT DATA PERUBAHAN FILE DARI TEST3 MENJADI TEST_3, JIKA
KITA REVERT, SECARA OTOMATIS AKAN MEMBUAT COMMIT BARU

• DAN KEMUDIAN REVERT

• SINTAK NYA ADALAH :
• GIT REVERT HASH
REVERT COMMIT
REVERT COMMIT
REVERT COMMIT
 GIT IGNORE

GIT MELAKUKAN ATAU TIDAK AKAN ATAU MEM BODO AMAT KAN FILE
GIT IGNORE
• KADANG SAAT MEMBUAT APLIKASI, TIDAK SEMUA FILE INGIN DI TRACK DI GIT, CONTOH NYA SEPERTI
HASIL LOG, HASIL KOMPILASI, KADANG ITU TIDAK DI PERLUKAN

• GIT MEMILIKI FITUR IGNORE, DIMANA KITA BISA MEMINTA GIT SECARA OTOMATIS TIDAK MENG TRACK
DI GIT

• CARANYA KITA BISA TAMBAHKAN FILE .GITIGNORE DI REPOSITORY

• LALU KITA BISA TAMBAHKAN TIAP BARIS DI DALAM .GITIGNORE BERISIKAN FILE ATAU FOLDER YANG
TIDAK INGIN TRACK
GIT IGNORE
GIT IGNORE
GIT IGNORE
Sesudah menambahkan nya, kita harus up ke staging dan commit ke repo
GIT IGNORE
Sesudah menambahkan nya, kita harus up ke staging dan commit ke repo
 BLAME

FITUR UNTUK MENGETAHUI APA SAJA ORANG YANG MENAMBAHKAN DI REPO, APA SAJA COMMIT NYA
GIT BLAME

• FUNGSI DARI GIT BLAME ADALAH INGIN MEGETAHUI SIAPA ORANG YANG MENGEDIT DI FILE TERTENTU
• MISALKAN KITA PINGIN TAHU SIAPA ORANG YANG MENGEDIT FILE NYA DAN KENAPA ITU DI TAMBAHKAN
• CARANYA :
• GIT BLAME NAMAFILE
GIT BLAME
GIT ALIAS

• FITUR GIT ALIAS ADALAH FITUR DIMANA KITA BISA MENGGANTI SINTAK DARI GIT
• MISALKAN KITA INGGIN MENGGANTI SINTAK COMMIT
• MISALKAN KITA INGIN MENGGANTI SINTAK GIT LOG –ONLINE
• SEBENERNYA JANGAN DI GANTI GANTI
• SOAL NYA INI KEBIASAN NANTI NTAR
GIT ALIAS

• KALO INGIN GANTI BISA DI COBA GIT CONFIG –GLOBAL ALISA KO. COMMIT  INI MENGGUBAH COMMIT
• CARA PENGGUNAAN NYA GIT KO –M
• ATAU ENGGA GIT CONFIG –GLOBAL ALIAS.LOGONE “ LOG –ONELINE”
• CARA PENGGUNAAN NYA YAHH GIT LOGONE