Apa itu Kolaborasi

Kolaborasi adalah proses dua orang atau lebih, entitas atau organisasi yang bekerja sama untuk menyelesaikan tugas atau mencapai suatu
tujuan. Sebagian besar kolaborasi membutuhkan kepemimpinan, meskipun bentuk kepemimpinan dapat bersifat sosial dalam kelompok
yang terdesentralisasi dan egaliter (sederajat).

Kita sudah beberapa kali menyebut GitHub adalah cara yang sangat efektif untuk berkolaborasi dalam proyek pengembangan. Ia
menyediakan tempat bagi siapa pun dengan koneksi internet untuk berbagi kode dengan dunia secara gratis. GitHub juga telah diadopsi
oleh banyak proyek open-source besar sebagai tempat mereka berkolaborasi dan berkontribusi.

Lalu, bagaimanakah cara bergabung dan berkontribusi pada suatu proyek? Sebelum menjawab ini, Anda perlu tahu terlebih dahulu bentuk
kolaborasi yang bisa dilakukan di dalam GitHub.

Bentuk kolaborasi yang dilakukan sangat tergantung dengan apakah repository-nya publik atau privat. Bisa dikatakan repository publik
adalah repository open source, karena siapa pun bisa melihat isi dari source code-nya. Sedangkan repository privat adalah repository yang
tidak untuk publik/umum dan hanya terbatas untuk tim dengan anggota tertentu saja.

Ketika suatu repository bersifat privat, hanya orang yang sudah ditambahkan sebagai collaborator-lah yang dapat mengakses repository
tersebut. Perhatikan gambar di bawah ini untuk skenario private repository.

Pada gambar di atas, terlihat jelas bahwa Ayu dan Gilang adalah collaborator dari repository yang dimiliki oleh Budi. Untuk menjadi
seorang collaborator, seorang owner perlu menambahkannya terlebih dahulu ke repository terkait.

Perlu diketahui, seorang collaborator belum tentu adalah seorang contributor (orang yang berkontribusi) ke repository tersebut.
Contributor adalah orang yang sudah pernah menambahkan commit di repository tersebut. Pada private repository, seorang collaborator
memang mendapatkan hak akses untuk melihat repository tersebut. Namun, bisa saja ia hanya perlu melihat source code tanpa
menambahkan commit satu pun.

Lalu, bagaimana dengan repository yang sifatnya publik atau biasa disebut repository open source?

Pada repository publik, semua orang dapat melihat isi dari repository. Owner-nya pun tetap dapat menambahkan collaborator pada
repository tersebut. Menariknya lagi, kita sebagai pihak luar pun tetap dapat berkontribusi ke repository tanpa harus menjadi collaborator
terlebih dahulu.

Contohnya, ada Dimas dan Fikri sebagai kontributor sebagai pihak luar yang ingin berkolaborasi pada sebuah repository publik buatan
Budi. Dimas dan Fikri dapat menggunakan fitur fork untuk menyalin repository tersebut ke dalam repository pribadi mereka. Setelah itu,
mereka dapat mengubah data/kode di dalam salinan repository tersebut. Dengan menggunakan fitur pull-request, mereka dapat meminta
persetujuan collaborator (pengelola repository Budi, Ayu, atau Gilang) untuk mengimplementasikan perubahan yang dilakukan ke dalam
original repository (repository asli). Untuk melihat detail dari skenario tersebut, lihatlah gambar di bawah ini :

Pada gambar di atas, Ayu dan Gilang tetap menjadi collaborator dan memiliki hak akses ke repository tersebut. Kemudian ada pihak luar
yaitu Dimas dan Fikri. Untuk dapat berkontribusi, mereka perlu melakukan fork terlebih dahulu sebelum melakukan pull request. Materi
tentang fork akan dijelaskan lebih dalam di materi selanjutnya.

Catatan: Perlu diketahui bahwa collaborator pun tetap bisa melakukan pull request ataupun commit secara langsung. Pada gambar di atas
sengaja dihilangkan informasi itu untuk penyederhanaan.

Sudah cukup jelas kan bentuk kolaborasi berdasarkan jenis repository-nya. Private repository memang untuk kolaborasi sebatas tim
internal saja. Sedangkan public repository berarti repository itu dapat dilihat oleh siapa pun, dan pihak luar pun dapat berkontribusi
dengan fork.

Kesempatan untuk berkontribusi di public repository sangatlah terbuka lebar bagi siapa pun, nah kesempatan bagi Anda juga untuk
memulai berkontribusi di repository open source terutama untuk mendukung komunitas tertentu.

Ada beberapa saran yang bisa Anda lakukan sebelum memulai berkontribusi di repository open source.
Mulai Dari yang Sederhana
Salah satu hal terpenting untuk dipahami ketika memulai kontribusi pada proyek adalah mengenali peran Anda. Di awal, tidak perlu
memulai dari memperbaiki masalah utama pada proyek yang besar dan kompleks. Terlalu susah di awal malah membuat kita takut dan
ujung-ujungnya tidak jadi berkontribusi. Oleh karena itu, mulailah dari hal-hal sederhana seperti memperbaiki dokumen dari sisi tata
bahasanya atau menambahkan dokumentasi pada proyek tersebut.

Dengan mulai berkontribusi pada hal-hal yang simpel, Anda akan memiliki pengalaman dalam berkontribusi. Sehingga, lambat laun
mampu memperbaiki masalah-masalah yang lebih besar di kemudian hari.

Pelajari Ekosistem Proyek

Pada beberapa repository, biasanya terdapat sejumlah kesepakatan yang mungkin telah ditetapkan sebelumnya. Kesepakatan ini termasuk
pada satu set kosakata, cara kontribusi, menuliskan pesan commit, atau bahkan standar sintaksis. Sebelum Anda mencoba terlibat dengan
proyek, baca semua dokumen yang terkait dengan hal-hal ini. Contohnya GitHub yang telah membuat standar melalui
file CONTRIBUTING.md (lihat panduan untuk terlibat dengan jQuery untuk contoh yang teliti).

Cara lain untuk memahami ekosistem proyek adalah dengan melihat kode yang ada dan sejarah perubahan kode dengan perintah git log.
Dengan membaca commit message dan style code, Anda dapat mengetahui berbagai informasi yang ada dalam proyek repository.

Latihan Berkolaborasi dengan Tim

Tujuan
Latihan Berkolaborasi dengan Tim bertujuan untuk mengajarkan Anda cara termudah dalam berkolaborasi dengan orang lain. Caranya
yaitu dengan menambahkan akun kolaborator ke dalam project repository yang dibuat.

Beberapa bagian dari latihan ini akan menjawab sejumlah pertanyaan mengenai kolaborasi melalui GitHub, seperti:

• Apa itu kolaborator?

• Bagaimana berkolaborasi menggunakan GitHub dengan orang lain?
• Apa yang perlu disiapkan sebelum berkolaborasi dengan orang lain?
• Bagaimana cara menambahkan akun GitHub orang lain ke dalam project repository?

Tahapan Proses
Berikut tahapan proses yang akan kita lakukan dalam Latihan Berkolaborasi dengan Tim:

• Membuka project repository yang dibuat.

• Membuka bagian settings project repository.
• Masuk ke bagian Manage Access/Mengelola Akses Project Repository.
• Menambahkan akun GitHub orang lain.
• Menerima email invitation menjadi kolaborator repository.
• Melakukan perubahan dalam repository yang dilakukan oleh kontributor (kolaborator yang memiliki akses untuk mengubah
repository).
• Melakukan Pull Request oleh kontributor.
• Mengelola Pull Request yang diterima.
• Melihat perbedaannya.

Latihan Berkolaborasi dengan Tim

Latihan kali ini kita akan menambahkan anggota tim ke dalam repository yang dikelola sehingga mereka dapat bergabung dan
mengerjakan proyek bersama. Untuk memulai menambahkan anggota tim, pastikan Anda adalah pemilik repository atau seorang
kolaborator dengan status admin. Tugas collaborator adalah mengelola repository, baik milik pribadi atau organisasi. Hanya pemilik
repository dan anggota organisasi dengan hak istimewa (admin) yang dapat menambahkan orang lain sebagai kolaborator baru ke
repository. Untuk informasi selengkapnya, lihat "Menyetel izin untuk menambahkan kolaborator luar".

Berikut adalah tahapan yang dapat dicoba untuk menambahkan akun GitHub orang lain agar dapat berkolaborasi di dalam repository:
1. Tentukan repository mana yang akan digunakan untuk berkolaborasi. Terlihat repository ini menggunakan jenis repository
private, yaitu repository yang hanya dapat dilihat oleh pembuat dan kolaborator yang telah ditambahkan ke dalam repository.

2. Setelah memilih repository mana yang akan digunakan, pilih menu Settings pada tab repository. Pada
halaman Settings terdapat berbagai pengaturan mengenai repository yang bisa Anda atur. Karena kita bertujuan untuk
menambahkan akun GitHub orang lain, pilihlah menu Manage access.

3. Setelah Anda memilih menu Manage access akan tampil halaman konfirmasi. Anda akan diminta untuk
memasukkan password dari akun GitHub yang digunakan. Proses ini bertujuan untuk menyakinkan GitHub bahwa Anda
memang pemilik akun tersebut.

4. Setelah proses konfirmasi, Anda diperkenankan untuk mengakses menu Manage access. Pada halaman tersebut terdapat
informasi bahwa repository hanya dapat dilihat oleh kolaborator yang memiliki akses. Selain itu, dapat Anda lihat saat ini
repository masih terdapat 0 kolaborator. Artinya, hanya pemilik akun lah yang dapat melihat dan mengelola repository. Pada
halaman ini juga terdapat tombol Invite collaborator untuk menambahkan kolaborator baru ke dalam repository.

5. Mari kita tambahkan kolaborator baru dengan cara mengeklik tombol Invite collaborator, lalu akan tampil popup dialog untuk
mencari akun dari akun kolaborator yang akan ditambahkan. Pada popup tersebut Anda dapat melakukan pencarian
berdasarkan username, full name, atau email dari akun GitHub calon kolaborator.

6. Katakanlah Anda memasukkan akun bernama “rifan”. Setelah memasukkan akun kolaborator, akan terdapat dropdown-
select yang dapat Anda pilih berdasarkan hasil pencarian tersebut.

7. Setelah memilih salah satu dari hasil pencarian, klik Add “Nama akun GitHub” to this repository.

8. Proses menambahkan akun kolaborator ke dalam project repository telah selesai, tetapi ia belum dapat melihat repository
karena statusnya masih dalam kondisi tertunda (Pending Invitation). Oleh karena itu, pemilik akun calon kolaborator harus
melakukan konfirmasi melalui email invitation yang dikirim oleh GitHub.

9. Sebagai calon kolaborator, mereka akan mendapatkan email invitation yang digunakan untuk mengonfirmasi ajakan kolaborasi.
Perlu diingat bahwa email invitation ini ada masa kadaluarsa, yakni 7 hari sejak undangan tersebut diterima. Jika lebih dari itu,
email konfirmasi tersebut tidak dapat digunakan.

10. Setelah mengonfirmasi undangan kolaborasi, calon kolaborator akan diarahkan ke halaman invitation. Untuk menerima
undangan kolaborasi, klik Accept Invitation. Namun jika ingin menolaknya, silakan klik Decline.
 Catatan : Sebelum mengakses tautan yang didapatkan dari email invitation, Anda harus mengakses halaman tersebut, mereka
harus login terlebih dahulu menggunakan akun GitHub.

11. Setelah menerima undangan kolaborasi, kolaborator yang sudah ditambahkan akan bisa melihat repository dan melakukan
kontribusi di dalamnya.

12. Menambahkan akun GitHub lain sebagai kolaborator dalam repository dapat dilakukan lebih dari satu kali. Alurnya sama
dengan alur yang sudah dilakukan sebelumnya. Untuk menghapus akun kolaborator yang telah ditambahkan, Anda dapat
menggunakan tombol hapus (ikon tempat sampah) yang berada pada bagian Manage access. Perlu Anda tahu juga bahwa
untuk akun kolaborator yang sudah ditambahkan tidak dapat ditambahkan kembali karena telah masuk ke daftar kolaborasi.

Saat menambahkan akun kolaborator ke dalam repository, secara default dapat melakukan read & write. Artinya, mereka dapat
melihat isi dari repository, serta melakukan perubahan di dalam repository.

13. Kolaborator dapat sekaligus merangkap menjadi kontributor dalam repository yang sudah dibuat. Mari kita simulasikan
bagaimana berkolaborasi antar tim dalam private repository.

14. Pada repository sebelumnya, siapkan terlebih dahulu dua branch, yakni branch main (cabang utama) dan branch development
(cabang untuk tim melakukan perubahan terhadap file dalam repository).

Catatan: Untuk melihat bagaimana cara membuat branch, silakan lihat kembali modul git branch.

15. Sebagai kolaborator, Anda bisa berpindah branch dari main ke development atau sebaliknya.

16. Kemudian buka salah satu berkas untuk melakukan perubahan.

17. Terdapat informasi mengenai kapan terakhir berkas tersebut diperbarui, serta kontributor yang terlibat dalam melakukan
perubahan pada file tersebut. Oke, mari kita lakukan perubahan dengan cara menekan ikon pensil.
18. Lakukan perubahan file kemudian Commit changes untuk menyimpan perubahan.

19. Pilih tab Pull request kemudian klik New pull request.

20. Pilih development untuk compare dan main untuk base. Pada skema ini kita akan melakukan compare atau membandingkan
antara branch development dan main.

Terlihat terdapat informasi perubahan pada file repository hello.txt. Jika Anda merasa perubahan yang dilakukan sudah sesuai,
mari buat pull request dengan cara menekan Create pull request.

21. Silakan masukkan commit message beserta commit description. Kemudian klik Create pull request.

22. Setelah selesai melakukan Pull-Request dari akun kolaborator, anggota lain dalam tim dapat melihat antrian permintaan pada
tab Pull request. Mereka dapat memilih dan melihat detail dari antrian tersebut.

23. Pada posisi ini, perubahan belum digabungkan ke branch main, tetapi masih masuk ke dalam antrian untuk melakukan merge.
Sehingga, Anda harus menunggu perubahan yang Anda lakukan direviu oleh anggota tim. Namun, jika tidak memerlukan
proses reviu, Anda bisa langsung menggabungkan perubahan ke branch utama dengan cara menekan Merge pull request.
 24. Sebelum menekan "Merge pull request", perhatikanlah dropdown di bagian kanan tombol tersebut. Perlu Anda tahu,
sebenarnya ada beberapa macam cara untuk menggabungkan perubahan ke branch/repository utama.

Ketiga item tersebut sama-sama berfungsi untuk menggabungkan commit ke dalam branch utama. Namun, terdapat
perbedaan hasil dari masing-masing opsi tersebut. Berikut untuk detailnya:
1. Create a merge commit: Commit yang dilakukan akan dicatat dan dimasukkan ke dalam history commit branch
tujuan. Selain itu, ada satu commit baru yang menginformasikan bahwa telah terjadi proses penggabungan.
2. Squash and merge: Commit yang dilakukan akan digabungkan dan dicatat menjadi satu commit dalam history
commit branch tujuan.
3. Rebase and merge: Commit yang dilakukan akan dipindahkan ke dalam history commit tujuan. Namun tidak akan
membuat commit baru untuk menginformasikan proses pencatatan.

25. Kali ini kita akan menggunakan Create a merge commit ya, lalu klik Confirm merge untuk melanjutkan.

Jika Anda ingin mengubah commit message dan commit description, tidak mengapa.

26. Dengan begitu, proses Pull request berhasil dilakukan dan penggabungan antara branch development ke branch main sukses.

Lihatlah perbedaan antara branch main dengan branch development. Keduanya saat ini memiliki data yang sama setelah
dilakukan pull request.

Dengan adanya fitur menambahkan kolaborator baru ke dalam project repository, Anda dapat membuat tim dengan orang lain. Selain itu,
ada juga fitur pull-request yang membuat Anda menjadi lebih fokus pada pekerjaan yang dilakukan, tanpa harus menunggu dan
mengganggu pekerjaan orang lain. Mengapa demikian? Sebab, pull-request memungkinkan Anda menggabungkan dua cabang
pekerjaan menjadi satu. Sehingga Anda dan rekan tim Anda dapat bekerja dengan lebih efisien dalam membangun produk aplikasi atau
sejenisnya.

Apa Itu Fork

Seperti yang sudah dibahas sebelumnya, kita bisa menggunakan fitur fork untuk menyalin public repository orang/organisasi lain ke
dalam repository pribadi. Mari kita bahas secara detail di sini.

Fork adalah proses menyalin proyek repository orang lain ke repository pribadi. Fork bertindak sebagai jembatan antara repositori asli
(original repository) dan repositori salinan (fork repository). Anda dapat menawarkan untuk menggabungkan perubahan yang telah Anda
lakukan pada repositori salinan ke repositori asal untuk membantu membuat proyek orang lain lebih baik dengan melakukan pull request.

Pada praktiknya, ketika Anda tidak memiliki akses pada sebuah public repository, Anda dapat melakukan beberapa tahap berikut agar
dapat berkontribusi pada repository tersebut:
 • Melakukan fork atau menyalin suatu repository.
• Melakukan perbaikan atau menambahkan perubahan.
• Melakukan pull request agar perubahan dapat disetujui untuk digabungkan ke dalam repository asli.

Untuk mengintegrasikan fitur yang telah diubah oleh kontributor ke dalam repository utama, pengelola repository akan memeriksa dan
mereviu untuk memastikan setiap perubahan yang ada dalam pull request tidak akan merusak proyek repository asli (original repository).
Setelah merasa aman dengan perubahan tersebut, pengelola dapat menerima pull request yang dilakukan oleh kontributor. Sehingga,
kontribusi yang telah dilakukan sekarang menjadi bagian dari proyek repository asli. Oleh karena itu, ketika ada developer lain yang ingin
berkontribusi atau melakukan perubahan (pull-request), mereka harus melakukan menarik (fetch stream) perubahan dari repository asli
untuk menyinkronkan repository mereka.

Forking vs Cloning
Lalu, apa bedanya fork dengan cloning? Keduanya memang sama-sama menyalin repository. Namun, perbedaannya terletak pada lokasi
tujuan dari hasil salinan. Ketika melakukan cloning dalam remote (contohnya GitHub), artinya Anda menyalin repository tersebut ke
dalam local (Laptop/PC Anda). Sedangkan ketika melakukan fork pada sebuah repository di GitHub, repository tersebut akan disalin ke
dalam akun GitHub Anda.

Ketika Anda melakukan perubahan pada hasil salinan repositori, baik via clone maupun via fork, perubahan tersebut tidak akan
memberikan efek kepada repositori asli (original repository). Lalu bagaimana cara mengimplementasikan perubahan yang dilakukan, baik
menggunakan fork maupun clone?

Jika menggunakan Fork, Anda perlu melakukan pull request antara fork repository dengan original repository. Sedangkan Clone, Anda
perlu melakukan push agar perubahan dapat disimpan ke dalam remote repository (contohnya dalam GitHub). Namun, untuk clone, Anda
tidak bisa melakukan push ke remote repository jika tidak memiliki akses.

Ketika tidak mempunyai hak akses pada public repository, Anda perlu melakukan forking terlebih dahulu pada repository tersebut. Setelah
mendapatkan fork repository (salinan original repository), Anda dapat melakukan cloning pada repository tersebut. Setelah itu, Anda
dapat mulai melakukan perubahan pada local repository. Untuk mengimplementasikan perubahan pada local repository ke fork repository,
Anda dapat menggunakan git push. Nah, karena saat ini kode/data dalam fork repository berbeda dengan original repository, Anda dapat
mengimplementasikan perubahan ke original repository dengan pull request. Bagaimana alurnya? Seperti inilah bentuk hubungan antara
fork dan clone.

Fork Repository
Sebelum melakukan perubahan pada public repository, semua kontributor yang tidak memiliki akses perlu melakukan fork pada repository
tersebut.

Perlu Anda tahu bahwa fork sejatinya seperti standar operasi git clone. Mengapa demikian? Sebab ketika Anda ingin melakukan fork pada
GitHub, sebenarnya GitHub akan menyalin repository yang ada menggunakan alamat HTTPS atau URL SSH. Kemudian GitHub akan
menempatkan hasil salinan dari original repository tersebut ke dalam akun GitHub yang Anda gunakan. Dengan begitu, Anda dapat
berkontribusi pada repository tersebut.

Forking dapat membantu pengelola repository untuk mengembangkan produk terbaik dengan cara berkolaborasi dengan developer lain.
Pengelola repository tidak perlu mengundang/invite developer untuk menjadi kolaborator, sebab mereka dapat melakukan usulan
perubahan dengan menggunakan fork dan pull request. Oleh karena itu, fork repository merupakan hal yang paling sering digunakan
dalam public repository atau open source.

Latihan Berkolaborasi pada Public Repository

Tujuan
Latihan Berkolaborasi pada Public Repository bertujuan untuk mengetahui cara berkolaborasi dengan orang/organisasi lain ketika tidak
memiliki akses (kolaborator). Beberapa bagian dari latihan ini akan menjawab sejumlah pertanyaan mengenai cara berkolaborasi dengan
orang/organisasi lain menggunakan GitHub, seperti:

• Bagaimana cara melakukan perubahan pada public repository yang tidak memiliki akses (kolaborator)?
• Apa bedanya melakukan perubahan pada public repository ketika memiliki akses (kolaborator) maupun tidak (sekadar
kontributor)?
• Bagaimana menyalin repository public repository ke dalam repository pribadi?
• Bagaimana seorang admin atau pemilik repository mengelola PR yang masuk?

Tahapan Proses
Berikut tahapan proses yang akan kita lakukan dalam latihan melakukan latihan berkolaborasi pada public repository:

• Menyalin repository oleh kontributor.

• Melakukan perubahan oleh kontributor.
• Melakukan pull request ke repositori asal (original repository) oleh kontributor.
• Mengelola pull request yang masuk oleh admin atau pemilik akun.
• Melihat perbedaan sebelum dan sesudah pull request dilakukan.

Latihan Berkolaborasi pada Public Repository

Untuk menambah pengetahuan tentang berkolaborasi pada public repository, silakan ikuti beberapa langkah dalam latihan berkolaborasi
pada public repository berikut:

1. Ketika ingin berkolaborasi pada public repository (open source), hal yang perlu Anda lakukan adalah menjalankan git fork atau
menyalin repository tersebut. Menyalin sebuah repository milik organisasi atau orang lain (fork repository) sangatlah mudah.

Mari kita tentukan terlebih dahulu repository manakah yang akan disalin. Jika sudah menentukannya, bukalah repository
tersebut.

2. Kemudian klik Fork untuk menyalin repository tersebut ke repository pribadi.

Setelah itu, Anda dapat melihat hasilnya bahwa nama dari pemilik repository sudah berganti sesuai username GitHub yang
digunakan. Selain itu, Anda juga dapat melihat bahwa repository itu adalah hasil fork dari sebuah repository.

3. Setelah berhasil melakukan fork, Anda dapat melakukan perubahan terhadap repository tersebut secara leluasa.
Jumlah Watch, Star, Fork, dan Pull Request otomatis direset setelah Anda melakukan fork, hanya jumlah fork saja yang tidak
ter-reset.

Catatan: Perlu diingat, ketika Anda mengubah repository tersebut tidak akan mengubah repository asal (original repository).
4. Sebelumnya, Anda telah melakukan Pull request secara langsung pada repository asal. Hal itu bisa dilakukan karena Anda
memiliki akses atau diundang menjadi salah satu kolaborator dalam repository tersebut. Karena saat ini kita tidak memiliki
akses, Anda perlu melakukan pull request melalui fork.

Masih dalam akun kontributor (orang yang akan berkontribusi pada repository), bukalah repository dari hasil fork yang telah
dilakukan sebelumnya.

5. Kemudian lakukan perubahan pada file di dalam repository pada branch main.

6. Setelah itu buat commit pada perubahan tersebut, dan lanjutkan membuat permintaan New pull request.

7. Anda akan diarahkan menuju halaman form pull request dari repository asal (original repository). Di sini kita akan membuat
pull request untuk melakukan permintaan penggabungan antara fork repository menuju original repository (repositori asal).

Pilih compare main pada sebelah kanan (fork repository) dan pilih base main pada sebelah kiri (original repository). Pada
bagian ini, Anda akan melihat berbagai perubahan yang dilakukan antara branch compare main (fork repository) dengan base
main (original repository). Lanjutkan dengan klik Create pull request.

8. Masukkanlah commit message dan commit description pada form pull-request. Kemudian klik Create pull request.

9. Jika perubahan pull request ingin direviu kodenya terlebih dahulu, klik bagian sebelah kanan, kemudian pilih siapa yang akan
melakukan reviu terhadap pull request sebelum dilakukan merge.

10. Kita tidak dapat melakukan merge pull request karena pada repository asal (original repository) menerapkan reviu terlebih
dahulu sebelum penggabungan dilakukan. Setelah pengelola repository (baik pemilik maupun anggota tim yang memiliki hak
akses) melakukan reviu, mereka dapat menjalankan perintah merge untuk menggabungkan perubahan tersebut.
 11. Lalu, bagaimana cara mengelola pull request dari sisi pemilik repository atau kolaborator yang memiliki hak akses?

Katakanlah Anda saat ini menjadi pemilik/pengelola dari repositori asli (Original repository). Kemudian masuk ke
halaman Pull requests dengan akun tersebut. Saat ini, terlihat ada satu permintaan perubahan/pull request yang dilakukan oleh
kontributor.

12. Biasanya seorang pengelola akan melakukan reviu pada pull request sebelum menjalankan merge ke branch utama. Setelah
melakukan review, Anda bisa menekan Merge pull request untuk memulai penggabungan.

13. Setelah melakukan review, masukkanlah commit description dalam Pull Request (PR) tersebut. Sebelum melakukan pull
request, klik Use your administrator privileges to merge this pull request,. Fitur ini merupakan hak prerogatif yang dimiliki
pengelola atau hak administrator untuk menggabungkan sebuah pull request. Jika sudah, klik Confirm merge untuk
melanjutkan merge.

14. Tada! Penggabungan berhasil tanpa ada kendala.

15. Pastikan merge berhasil dilakukan dengan cara cek branch main di repository asal (original repository). Seperti inilah
perbandingan antara repositori asal (original repository) dengan repositori salinan (fork repository) setelah
perintah merge berhasil dijalankan melalui Pull requests.

Selamat. Anda telah memahami cara menyalin repository dengan fork dan melakukan perubahan dalam repositori salinan (fork
repository) menggunakan pull request.

Latihan Melakukan Revert

Tujuan
Latihan Melakukan Revert bertujuan untuk mengetahui cara mengembalikan kode/data dalam repository pada commit tertentu. Biasanya
revert digunakan ketika Anda melakukan perubahan (commit), tetapi justru menimbulkan masalah/bug pada project repository. Beberapa
bagian dari latihan ini akan menjawab sejumlah pertanyaan mengenai cara mengembalikan kode/data pada commit tertentu, seperti:

• Apa itu revert?

• Bagaimana cara menanggulangi commit yang salah atau menimbulkan bug?
• Apa yang harus dilakukan ketika melakukan git revert?
• Apa dampak setelah melakukan git revert?

Tahapan Proses
Berikut tahapan proses yang akan kita lakukan dalam latihan melakukan revert:

• Membuka repository.
• Membuka halaman riwayat commit.
• Membuka salah satu detail commit.
• Melakukan revert.
• Menghapus branch yang terbentuk dari revert.

Latihan Berkolaborasi pada Public Repository (Open Source)

Git revert dapat dianggap sebagai perintah ‘undo’. Mengapa demikian? Sebab, Git revert adalah cara terbaik untuk mengembalikan
perubahan (commit) yang telah dilakukan, kemudian membuat commit baru dengan riwayat perubahan commit yang telah dipilih. Hal ini
bertujuan agar kita tidak kehilangan riwayat perubahan pada proyek selama berkolaborasi. Berikut adalah perbedaan antara Reset dengan
Revert.

Penting untuk dipahami bahwa git revert akan membatalkan beberapa commit, bukan "mengembalikan" status proyek pada commit
tertentu dan menghapus semua commit setelahnya. Jika Anda ingin menghapus beberapa commit yang dilakukan, maka dapat
menggunakan git reset.

Revert memiliki dua keuntungan dibandingkan ketika menggunakan reset. Pertama, revert tidak akan mengubah riwayat proyek.
Sehingga, operasi yang dilakukan tergolong "aman" untuk commit yang telah dipublikasikan ke remote repository. Kedua, git revert
mampu menargetkan commit individu pada titik yang diinginkan dalam riwayat.

Sedangkan git reset hanya dapat bekerja mundur dari commit saat ini. Misalnya, jika ingin membatalkan commit yang telah dilakukan
dengan git reset, Anda harus menghapus semua commit yang terjadi setelah commit target, kemudian menghapusnya, dan melakukan
commit kembali.

Oke, mari kita praktikkan bagaimana melakukan revert pada perubahan file dalam repository. Ikutilah beberapa langkah berikut ya:

1. Buka salah satu repository yang sudah Anda praktikkan. Pilih tab Pull request dan lanjutkan dengan menekan tombol closed.

2. Dalam daftar "Pull request", klik salah satu pull requests yang ingin dikembalikan.

3. Pada bagian bawah pull request, tekan Revert.

4. Kemudian masukkan deskripsi pada kolom Write, lalu klik Create pull request.

5. Selanjutnya klik Confirm merge untuk melanjutkan.

6. Proses revert telah berhasil dilakukan sehingga data/kode pada riwayat sebelumnya telah dikembalikan. Selain itu, Anda juga
telah membuat satu commit baru yang berisi data/kode hasil revert.

7. Setelah melakukan revert, akan ada branch baru. Branch ini merupakan riwayat yang telah Anda buat sebelumnya. Anda dapat
menghapus branch ini jika dirasa tidak memerlukannya.

8. Untuk menghapus branch, klik Closed untuk melihat daftar pull request. Kemudian klik pull request yang terkait dengan
cabang yang ingin Anda hapus.

9. Pada bagian bawah pull request, klik Delete branch. Tombol ini tidak tampil jika saat ini ada antrian pull request pada branch.

10. Untuk mengembalikan branch yang telah terhapus, Anda dapat menekan Restore branch.

Seperti itulah revert dalam git. Setiap riwayat perubahan (history commit) pada repository dapat dilakukan pengembalian (revert).
Sehingga, anggota tim tidak perlu merasa khawatir ketika mengalami masalah atau bug.
Apa Itu Squashing Changes

Squash adalah opsi Git untuk menggabungkan atau merekap semua commit tambahan dalam pull request menjadi satu commit.

Squash bertujuan untuk membuat riwayat commit yang lebih ramping dalam repository. Pada dasarnya setiap commit akan membantu
untuk melihat setiap perubahan yang telah dilakukan, tetapi tak semua commit selalu menjadi hal yang penting untuk disimpan dalam
riwayat Git. Contohnya ketika melakukan beberapa perubahan pada formating (perubahan spasi, titik, koma).

Jika Anda menggabungkan beberapa commit ini menjadi satu commit, perubahan yang dilakukan menjadi terlihat lebih jelas terlihat, serta
menjadi lebih fokus pada tujuan dari commit tersebut.

Untuk mendapatkan gambaran yang lebih jelas mengenai squash di dalam GitHub, perhatikan gambar berikut:

Bisa dilihat bahwa ada beberapa commit yang sudah dilakukan di repository tersebut. Ketika kita lakukan squash, akan menjadi seperti
berikut:

Bisa dilihat bahwa yang awalnya terdapat beberapa commit bisa Anda reduksi menjadi 1 commit saja.

Untuk melakukan squash dalam GitHub, Anda harus memiliki izin untuk menulis (write) di repository, serta repositori harus mengizinkan
penggabungan squash tersebut.

Penggabungan Pesan ketika Squashing

Saat Anda menggabungkan beberapa commit menjadi satu, GitHub menghasilkan pesan commit yang dapat Anda ubah jika diinginkan.
Default pesan tersebut tergantung pada jumlah commit yang ada dalam pull request. Berikut perbedaan ketika hanya terdapat satu commit
dan beberapa commit dalam pull request:.

Jumlah Commit Pesan Commit Deskripsi Commit

Satu commit Berisi pesan commit terakhir, diikuti oleh nomor pull request. Berisi deskripsi commit terakhir.
Lebih dari satu commit Berisi nama pull request, diikuti dengan nomor pull request. Berisi daftar pesan commit dari semua commit dalam sa

Squashing and Merge pada Branch yang Sudah Berjalan Lama

Jika Anda berencana untuk melanjutkan pekerjaan dalam head branch (branch lain yang telah diubah dan digabungkan ke base
branch sewaktu pull request) setelah melakukan squashing and merge dalam pull request (squashing), Git tidak menyarankan untuk
melakukan squash and merge kembali melalui pull request.

Contohnya dalam gambar di atas, Anda telah melakukan squashing and merge dari branch feature (head branch) ke branch master (base
branch). Kemudian Anda melanjutkan pekerjaan pada branch feature (commit G dan H) dan melakukan squashing and merge melalui
pull request kembali. Inilah yang tidak disarankan oleh Git. Mengapa demikian?

Sebab, ketika Anda membuat pull request, Git akan mengidentifikasi semua commit terbaru dalam di head branch (feature) dan base
branch (master). Sehingga ketika Anda melakukan squashing and merge melalui pull request, Git akan membuat commit di base branch
yang berisi semua perubahan yang dibuat dalam head branch.
Jika Anda tetap melanjutkan pekerjaan di dalam head branch dan melakukan pull request ke base branch, pull request yang dilakukan akan
menyertakan semua commit yang telah dilakukan termasuk commit sebelum penggabungan ( (termasuk commit D dan E yang sudah
dilakukan squashing and merge) sebelumnya.

Hal inilah yang dapat menimbulkan konflik atau masalah. Jika Anda terus melanjutkan pekerjaan di head branch, Anda perlu
menyelesaikan conflict yang muncul sebelum menggabungkannya ke dalam base branch. Oleh karena itu, setelah melakukan squashing
and merge, alangkah baiknya Anda hapus branch sebelumnya dan buat branch baru untuk melanjutkan pekerjaan. Hal ini dapat
meminimalisir bug yang muncul sewaktu pull request ke base branch (cabang utama).

Squashing Pada GitHub

Penggunaan Squashing dapat dilakukan sewaktu melakukan pull request. Seperti yang dijelaskan sebelumnya bahwa squashing bertujuan
untuk merekap beberapa commit menjadi satu commit yang utuh. Proses ini hampir sama ketika Anda melakukan merge dalam pull
request, tetapi squashing akan menyebabkan perbedaan pada history commit.

Untuk melihat hasil penerapan dari squashing, buka Network graph yang berada pada fitur Insights. Fitur ini gratis jika menggunakan
repository dengan jenis public. Lalu bagaimana jika ingin menggunakan dalam private repository? Anda bisa menggunakannya, tetapi
harus berbayar.

Dalam Network graph, semua commit yang dilakukan akan terlihat dalam bentuk jalur history. History ini terdiri dari kumpulan titik/dot
yang mewakili commit dan pull request yang telah dilakukan.

Perhatikanlah contoh network graph berikut:

Pada gambar di atas terdapat beberapa branch, yakni branch1, branch2, dan branch3. Pada masing-masing branch terdapat dua commit
yang berbeda sebelum ketiga branch tersebut digabungkan ke dalam branch main. Berikut detailnya:

1. Branch1 menggunakan metode squash and merge, sehingga commit yang ada akan dikumpulkan menjadi satu commit baru
di dalam branch main.
2. Branch2 menggunakan metode rebase and merge, sehingga commit yang ada akan dipindahkan ke dalam branch main.
3. Branch3 menggunakan metode merge, sehingga commit yang ada akan masuk dalam history commit branch main dan
terbentuk satu commit baru hasil dari penggabungan tersebut.

Catatan: Insights Graph repository hanya tersedia di repository publik dengan GitHub Free dan GitHub Free untuk organisasi. Sedangkan
untuk repository private dapat digunakan melalui GitHub Pro, GitHub Team, GitHub Enterprise Cloud, dan GitHub Enterprise Server.
Untuk informasi lebih lanjut, lihat " Tentang grafik repositori " dan " Produk GitHub ."

Latihan Melakukan Squashing Changes

Tujuan
Latihan melakukan squashing change bertujuan untuk menggabungkan beberapa commit menjadi satu sewaktu pull request dengan
menggunakan Squash and Merge. Beberapa bagian dari latihan ini akan menjawab sejumlah pertanyaan mengenai cara bagaimana
menggabungkan commit sewaktu melakukan pull request, seperti:

• Apa itu squashing change?

• Bagaimana cara menggabungkan beberapa commit sewaktu melakukan pull request?
• Apa yang perlu diperhatikan sewaktu melakukan squashing change?
• Bagaimana menggunakan Squash and Merge?
• Bagaimana cara melihat hasil dari hasil Squash and Merge pada Network graph.

Tahapan Proses
Berikut tahapan proses yang akan kita lakukan dalam latihan melakukan squashing changes:

• Membuka Repository
 • Membuat Branch
• Melakukan Commit minimal 3
• Melakukan Pull Request
• Menerima Pull Request dan memilih Squash Changes oleh pengelola repository.
• Melihat hasilnya pada network graph.

Latihan Melakukan Squash Changes

Untuk memulai Squash changes, ada beberapa tahapan yang dapat dilakukan. Ikutilah langkah demi langkah berikut:

1. Buatlah commit terlebih dahulu pada repository di dalam branch development dengan jumlah minimal 3 commit. Kontributor
dapat berasal dari anggota tim atau dari kolaborator (baik pemilik repository atau orang yang memiliki hak akses untuk
mengelola). Contohnya seperti ini:

2. Setelah melakukan commit, lanjutkan dengan membuat pull request baru.

3. Kemudian masuk ke halaman pull requests pada dashboard repository kolaborator dan buka detail dari pull
request tersebut. Lanjutkan melakukan merge menggunakan Squash and merge untuk melakukan penggabungan.

Jika dilihat pada bagian Squash and merge terdapat informasi, "The 6 commits from this branch will be combined into one
commit in the base branch.” Artinya, 6 commit dari branch development akan digabung menjadi satu commit di base branch
(branch utama). Informasi tersebut dapat membantu Anda untuk mengetahui jumlah commit yang akan digabungkan.

4. Setelah memilih Squash and merge, daftar commit yang telah dilakukan akan tampil di kolom komentar. Di sini kita masih bisa
mengedit informasi tersebut sesuai keinginan.

Kemudian klik Confirm squash and merge sehingga perubahan yang Anda lakukan terkirim dan digabungkan ke branch
utama.

5. Selanjutnya Anda dapat melihat hasil dari squash and merge pada Network graph. Caranya, buka repository terlebih dahulu
dan pilih tab Insights. Kemudian pada menu sebelah kiri klik Network.

6. Network graph atau jalur history merupakan hasil dari merge menggunakan Squash and merge. Di dalam riwayat ini, tidak
ada commit yang tercatat. Seperti yang diketahui sebelumnya, kita sudah mengerjakan sebanyak 6 commit dan melakukan pull
request beserta merge.

Squashing change dilakukan untuk membersihkan jalur dari perubahan-perubahan yang dirasa tidak perlu dicatat pada halaman
history jalur. Sehingga hanya akan ditampilkan hasil akhir yang telah dilakukan saja.

7. Untuk melihat lebih detail dari apa saja perubahan yang telah dilakukan, klik dot yang berwarna hitam. Selanjutnya akan
tampil halaman detail dari perubahan tersebut. Sehingga, Anda dapat melihat deskripsi dan catatan perubahan yang telah
dikerjakan.

8. Sedangkan jika dilihat pada Merge commit, setiap commit akan tercatat di dalam jalur dan perubahannya akan dinaikan ke
branch utama. Sehingga, untuk melihat setiap deskripsi atau catatan perubahan, Anda harus membuka satu per satu commit
 pada network graph. Contohnya pada titik berwarna biru, yang merupakan history commit

Mantap! Anda sudah mempraktikkan squashing change dalam latihan. Sehingga, Anda dapat membedakan antara menggunakan Merge
commit dengan Squash and merge dalam menanggapi pull request. Mari kita lanjut ke materi selanjutnya untuk mempelajari code
review. Semangat!

Apa Itu Code Reviews

Seperti yang kita tahu, GitHub merupakan platform yang ditujukan untuk bekerja secara kolaborasi bersama tim. Setiap anggota tim dapat
melakukan penambahan dan perubahan repository yang menjadi rumah utama pada pengerjaan projek. Setiap perubahan dapat dilihat
berdasarkan hasil file yang diubah oleh anggota tim.

Setiap perubahan yang diwakilkan dalam pull request, seorang pengelola (administrator) mampu memberikan review-nya terlebih dahulu.
Dengan adanya proses review ini, administrator mampu mengomentari perubahan, menyetujui perubahan, atau meminta perubahan lebih
lanjut sebelum pull request digabungkan.

Proses review ini lazim dilakukan oleh tim pengembangan yang peduli dengan kualitas kode perubahan. Proses ini juga bisa digunakan
untuk transfer ilmu dari si administrator (pengelola repository) ke si pembuat pull request. Biasanya administrator lebih senior dari sisi
skill pengembangan dibandingkan dengan si pembuat pull request.

Adapun beberapa tujuan yang dicapai dari pengulasan kode (code reviews) ini adalah ketika kontributor lain selesai mengerjakan suatu
masalah atau fitur, kontributor lain dapat memeriksa kode dan mempertimbangkan beberapa pertanyaan berikut:

• Apakah ada kesalahan logika yang jelas dalam kode?

• Melihat persyaratannya, apakah semua kasus diimplementasikan sepenuhnya?
• Apakah pengujian otomatis sudah cukup untuk kode baru? Apakah pengujian otomatis ada yang perlu ditulis ulang untuk
memperhitungkan perubahan kode?
• Apakah kode baru sudah sesuai dengan style guideline (panduan penulisan kode) yang ada?

Code review dilakukan dengan mengikuti alur kerja pengembangan (development workflow) yang ada. Misalnya, ketika ada anggota tim
yang menggunakan dua branch di dalam repository untuk mengerjakan projek, maka code review akan dilakukan terlebih dahulu sebelum
menggabungkan pull request. Hal ini bertujuan untuk memastikan semua kode yang ditulis dapat berjalan dengan baik. Biasanya seorang
pengulas akan melakukan pengujian secara manual maupun secara otomatis. Oleh karena itu, code review ini penting untuk dilakukan
agar tidak ada yang terlewat dan mencegah terjadinya kesalahan/bug sewaktu menggabungkan ke base branch (cabang utama).

Apa yang harus dicari dalam Code Reviews

Berikut beberapa aspek yang dapat digunakan sebagai acuan dalam melakukan ulasan kode:

• Kode dirancang dengan baik.

• Fungsionalitasnya dapat berjalan dengan baik.
• Setiap perubahan yang dilakukan masuk akal dan terlihat bagus.
 • Kodenya tidak lebih kompleks dari yang seharusnya.
• Developer mengimplementasikan hal-hal yang diperlukan saat ini saja. Bukan menyediakan kode untuk masa depan, tetapi
tidak digunakan saat ini.
• Kode memiliki unit test (pengujian unit) yang sesuai.
• Pengujian dirancang dengan baik.
• Pengembang menggunakan nama yang jelas untuk segala penamaan.
• Komentar yang ditambahkan jelas dan bermanfaat. Selain itu komentar ditujukan untuk menjelaskan kode apa yang ditulis
beserta alasannya.
• Kode telah didokumentasikan dengan tepat.
• Kode ditulis sesuai dengan panduan (style guideline) yang telah disepakati.

Selain beberapa poin di atas, pastikan juga untuk memberikan ulasan pada setiap baris kode. Bahkan dianjurkan untuk memberikan pujian
kepada kontributor ketika penulisan kode sudah sesuai dan bagus.

Keuntungan Bagi Tim Ketika Melakukan Code Review

Setiap tim dapat mengambil manfaat dari ulasan kode, terlepas dari metodologi pengembangannya. Namun, tim yang gesit dapat
mewujudkan manfaat besar karena pekerjaan didesentralisasikan ke seluruh anggota tim. Tidak akan ada seorang pun yang menjadi satu-
satunya yang mengetahui bagian tertentu dari basis kode. Sederhananya, ulasan kode membantu dan memfasilitasi anggota tim untuk
berbagi pengetahuan di seluruh basis kode.

Catatan : Jika code review dilakukan dengan benar, sebenarnya menghemat waktu dalam jangka panjang.

Code Review Pada GitHub

Di dalam GitHub, ulasan kode merupakan hal yang wajib dilakukan sebelum menggabungkan pull-request ke dalam branch utama. Hal ini
bertujuan agar tidak terjadi konflik saat anggota tim lain melakukan perubahan dan merge di kemudian hari. Ulasan kode ini sebenarnya
dilakukan oleh anggota tim yang memiliki akses administrator atau pemilik repository di dalam repository

Timbul pertanyaan, “Kapan code review atau ulasan kode dilakukan?” Terdapat dua kondisi yang cocok untuk melakukan ulasan kode,
antara lain:

• Pertama, ulasan kode dilakukan sewaktu anggota tim melakukan Pull request dan sebelum menggabungkannya (merge) ke
branch utama (base branch).

Kondisi ini dapat dijalankan sebelum pengelola (administrator/pemilik) repository melakukan merge. Reviews akan dilakukan
dengan cara memeriksa setiap perubahan yang dilakukan, apakah terdapat kesalahan atau tidak. Jika dirasa tidak ada kesalahan,
merge dapat langsung dilakukan.

• Kedua, ulasan kode dapat dilakukan setelah merge (penggabungan) perubahan ke base branch (branch utama). Mengapa ulasan
kode dilakukan setelah merge (penggabungan)? Sebab terkadang anggota tim (kontributor) bisa saja melewatkan proses ulasan
kode sewaktu melakukan pull request, sehingga akan membuat pekerjaan menjadi kurang efisien dan memengaruhi kinerja tim
dalam mengembangkan sebuah produk.

Ulasan kode perlu dilakukan agar tidak menimbulkan permasalahan ke depannya. Dampaknya, anggota tim lain harus
menunggu proses code review tersebut agar tidak terjadi masalah lain sewaktu menggabungkan perubahan ke base branch
(cabang utama).

Dengan dilakukannya code review, diharapkan anggota tim dapat mengerjakan setiap bagian dengan teliti untuk meminimalisir terjadinya
kesalahan antar anggota tim.

Latihan Melakukan Code Reviews

Tujuan
Latihan melakukan code reviews bertujuan untuk memanfaatkan fitur code review sewaktu melakukan pull request. Biasanya digunakan
untuk melakukan ulasan kode pada pull request yang dilakukan dan menanggapinya dengan komentar dan ulasan. Beberapa bagian dari
latihan ini akan menjawab sejumlah pertanyaan, seperti:

• Apa itu Code Review?

• Bagaimana melakukan Code Review?
• Apa efek setelah melakukan code review dalam pull request.
• Apa yang perlu diperhatikan sewaktu melakukan code review?

Tahapan Proses
Berikut tahapan proses yang akan kita lakukan dalam latihan melakukan code reviews:

• Membuka halaman daftar pull request yang dilakukan oleh kontributor.

• Memilih salah satu pull request dan melihat detail perubahan.
• Membandingkan perubahan dalam pull request dengan original repository.
• Memberikan komentar pada baris kode.
• Meminta kontributor untuk memperbaiki kode/data dalam pull request.
• Menerima pull request agar dapat digabungkan ke original repository.
• Melihat hasil perubahan yang telah dilakukan setelah penggabungan.
• Memberikan feedback pada kontributor atas kontribusi yang diberikan.

Latihan Melakukan Code Reviews

Untuk mulai melakukan code review pada pull request, ikutilah beberapa tahapan berikut;

1. Posisikan Anda sebagai kolaborator (pemilik repository) yang menerima beberapa pull request. Anda dapat membuka
bagian pull request pada repository terlebih dahulu.

Pilih satu dari pull request tersebut untuk melihat perubahan yang dilakukan secara lebih detail.

2. Dapat dilihat other-team sebagai kontributor yang telah melakukan perubahan pada file repository. Anda dapat melihat
bahwa other-team meminta Anda sebagai kolaborator melakukan untuk mereviu atau mengulas perubahan tersebut terlebih
dahulu.

Untuk memulai reviu, klik Add your review.

3. Terlihat pada tab Files changed terdapat perubahan dari file yang dilakukan. Bagian nomor satu di sebelah kiri merupakan
kondisi isi dari file yang belum dilakukan perubahan. Sedangkan bagian nomor dua di sebelah kanan merupakan file yang telah
dilakukan perubahan. Melalui indikator berwarna hijau, Anda dapat melihat di mana perubahan tersebut terjadi.

4. Untuk memberikan komentar dalam berkas tersebut, arahkan kursor pada baris perubahan dan muncul ikon tambah (+)
berwarna biru. Klik ikon tersebut dan akan tampil input komentar. Isilah komentar ulasan yang diharapkan, lalu klik Start a
review.

5. Seperti inilah hasilnya:

 Anda juga dapat menambahkan kembali komentar dengan cara yang sama.

6. Selanjutnya, jika revisi yang dilakukan oleh kontributor telah selesai, Anda perlu melakukan penyelesaian review dengan cara
klik Finish your review. Kemudian akan tampil form untuk memberikan rekap dari ulasan kode yang telah dilakukan. Anda
juga dapat melihat komentar sebelumnya yang sudah dilakukan.

Terdapat 3 kondisi status reviewyang dapat digunakan yaitu;

a. Comment: memberikan umpan balik secara langsung tanpa menyetujui perubahan atau meminta perubahan
tambahan.
b. Approve: mengirimkan umpan balik dan menyetujui penggabungan perubahan yang diusulkan dalam pull request.
c. Request changes: mengirimkan umpan balik perbaikan yang harus ditangani sebelum pull request dapat di-merge.

7. Pada percobaan ini, kita akan memilih Request changes untuk meminta kontributor memperbaiki pull request. Kemudian
lanjutkan dengan klik Submit review. Terlihat hasil dari peninjauan kode yang dilakukan oleh pengelola bahwa terdapat satu
perbaikan yang harus dilakukan.

8. Katakanlah kontributor sudah melakukan perubahan. Sehingga kolaborator (pemilik repository) dapat menanggapi hasil
perbaikan dengan cara klik Change requested yang berada di bawah hasil reviu sebelumnya. Kemudian lanjutkan dengan
klik Dismiss review.

9. Isilah pesan perbaikan yang telah dilakukan, kemudian klik Dismiss review.

10. Selanjutnya akan muncul form konfirmasi yang dilakukan oleh other-team sebagai kontributor bahwa ia telah melakukan
perbaikan dan mengirim hasil perbaikan di dalam pull request terbaru.

11. Kemudian akan ada commit baru dari hasil perbaikan yang telah dilakukan oleh other-team sebagai kontributor.

12. Selanjutnya pengelola repository dapat mengkonfirmasi kembali hasil dari perubahan tersebut, apakah perubahan sesuai
dengan yang diharapkan atau tidak. Jika dirasa perbaikan yang diminta telah dilakukan, pengelola akan langsung melakukan
merge ke branch main sesuai dengan pull request yang diminta. Kemudian pengola repository dapat melanjutkan dengan
klik Confirm squash and merge.

13. Sehingga, hasil dari pull request tersebut telah digabungkan ke branch utama.

Catatan: Sebagai pengelola repository, jangan lupa untuk memberikan informasi kepada kontributor bahwa pull-request telah
dilakukan. Anda juga dapat memberikan pesan motivasi untuk menyemangati mereka..

Mantap! Dengan code reviews, pihak kolaborator (pengelola repository) dapat berkomunikasi dengan pihak kontributor (yang melakukan
pull-request) untuk mendapatkan kode/data terbaik. Dengan ini Anda diharapkan dapat melakukan code review ketika berkolaborasi pada
projek repository dengan orang lain.

Rangkuman Kolaborasi dengan Tim

Pada rangkuman ini akan mengulas kembali apa saja yang telah dipelajari pada materi kolaborasi dengan tim. Berikut poin-poinnya:

• Kolaborasi adalah proses dua orang atau lebih, entitas atau organisasi yang bekerja sama untuk menyelesaikan tugas atau
mencapai suatu tujuan. Sebagian besar kolaborasi membutuhkan kepemimpinan, meskipun bentuk kepemimpinan dapat
bersifat sosial dalam kelompok yang terdesentralisasi dan egaliter (sederajat).
• Fitur kolaborasi ini dapat Anda temukan pada GitHub dengan menambahkan akun lainnya (kolaborator) ke dalam repository
yang tersimpan.
• Di dalam GitHub sendiri terdapat dua cara kolaborasi bersama tim yang sering digunakan:
o Repository Organisasi: Pemilik organisasi dapat menambahkan kolaborator dengan tingkat izin yang berbeda
untuk berbagai repository.
 o Repository Pribadi: Pemilik repository dapat menambahkan kolaborator dengan akses read & write untuk satu
repository.
• Fork adalah proses menyalin proyek repository orang lain ke repository pribadi. Fork bertindak sebagai jembatan antara
repositori asli (original repository) dan repositori salinan (fork repository). Anda dapat menawarkan perubahan yang dilakukan
pada repositori salinan ke repositori asli untuk membantu membuat proyek orang lain lebih baik dengan melakukan pull
request.
• Squash bertujuan untuk membuat riwayat commit yang lebih ramping dalam repository. Pada dasarnya setiap commit akan
membantu untuk melihat setiap perubahan yang telah dilakukan, tetapi tak semua commit selalu menjadi hal yang penting
untuk disimpan dalam riwayat Git. Contohnya ketika melakukan beberapa perubahan pada formating (perubahan spasi, titik,
koma). Jika Anda menggabungkan beberapa commit ini menjadi satu commit, perubahan yang dilakukan menjadi terlihat lebih
jelas terlihat, serta menjadi lebih fokus pada tujuan dari commit tersebut.
• Untuk melakukan squashing dalam GitHub, Anda dapat menggunakan Squash & Merge sewaktu melakukan pull request.
• Network graph dalam GitHub digunakan untuk melihat berbagai alur dari riwayat commit sebuah repository.
• Network Graph dalam GitHub hanya tersedia secara gratis untuk repository publik dengan akun pribadi dan akun organisasi.
Sedangkan untuk repository private dapat digunakan secara berbayar melalui GitHub Pro, GitHub Team, GitHub Enterprise
Cloud, dan GitHub Enterprise Server. Untuk informasi lebih lanjut, lihat " Tentang grafik repositori " dan " Produk GitHub ."
• Network graph semua commit yang dilakukan akan terlihat dalam bentuk jalur history. History ini terdiri dari kumpulan
titik/dot yang mewakili commit dan pull request yang telah dilakukan.
• Code reviews bertujuan untuk mengomentari perubahan, menyetujui perubahan, atau meminta perubahan lebih lanjut sebelum
pull request digabungkan.
• Berikut beberapa aspek yang dapat digunakan sebagai acuan dalam melakukan ulasan kode/code reviews:
o Kode dirancang dengan baik.
o Fungsionalitasnya dapat berjalan dengan baik.
o Setiap perubahan yang dilakukan masuk akal dan terlihat bagus.
o Kodenya tidak lebih kompleks dari yang seharusnya.
o Developer mengimplementasikan hal-hal yang diperlukan saat ini saja. Bukan menyediakan kode untuk masa
depan, tetapi tidak digunakan saat ini.
o Kode memiliki unit test (pengujian unit) yang sesuai.
o Pengujian dirancang dengan baik.
o Pengembang menggunakan nama yang jelas untuk segala penamaan.
o Komentar yang ditambahkan jelas dan bermanfaat. Selain itu komentar ditujukan untuk menjelaskan kode apa yang
ditulis beserta alasannya.
o Kode telah didokumentasikan dengan tepat.
o Kode ditulis sesuai dengan panduan (style guideline) yang telah disepakati.
• Code review dilakukan ketika anggota tim/kontributor melakukan perubahan dan melakukan pull request.
• Selain mempelajari teori pada modul ini terdapat latihan-latihan yang telah dilakukan diantaranya yaitu;
o Latihan Berkolaborasi dengan Tim: Mengajarkan bagaimana menambahkan anggota tim di dalam repository agar
dapat saling berkolaborasi. Melakukan verifikasi email setelah pengelola repository mengundang sebagai
kolaborator atau salah satu anggota tim kolaborasi. Kemudian melakukan melakukan perubahan dengan membuat
branch baru dan menggabungkannya ke branch utama menggunakan pull request dan merge.
o Latihan Berkolaborasi pada Public Repository: Mengajarkan bagaimana menyalin repository orang/organisasi
lain dan kemudian menyimpannya ke dalam repository pribadi. Lalu melakukan perubahan pada repository salinan
dan dilanjutkan dengan melakukan pull request agar perubahan yang dilakukan dapat diimplementasikan ke dalam
repositori asli (original repository).
o Latihan Revert : Mengajarkan bagaimana mengembalikan perubahan/commit yang telah dilakukan. Salah satu
keuntungan menggunakan Git revert, yakni mampu menargetkan commit pada titik yang diinginkan dalam riwayat
commit.
o Latihan Squashing Changes : Mengajarkan bagaimana menggabungkan atau merekap beberapa commit menjadi
satu. Kemudian menggunakan fitur Squash and Merge untuk mengirim rekap commit tersebut ke dalam branch
utama (base branch). Serta melihat jalur history commit dan pull request yang telah dilakukan melalui
fitur Network graph.
o Latihan Code Review: Mengajarkan bagaimana menggunakan fitur code review dalam GitHub, seperti
memberikan ulasan kode pada permintaan pull request dari anggota tim (kontributor). Serta mengirim hasil reviews
yang telah dilakukan dengan memberikan status pesan reviews seperti:
▪ Comment: memberikan umpan balik secara langsung tanpa menyetujui perubahan atau meminta
perubahan tambahan.
▪ Approve: mengirimkan umpan balik dan menyetujui penggabungan perubahan yang diusulkan dalam
pull request.
▪ Request changes: mengirimkan umpan balik perbaikan yang harus ditangani sebelum pull request dapat
di-merge.

Dengan mempelajari setiap materi yang ada, diharapkan Anda akan dapat memahami bagaimana berkolaborasi bersama tim, serta
menghadirkan produk atau aplikasi yang berkualitas. Jika Anda masih bingung mengenai kolaborasi, kami sarankan untuk mencoba setiap
latihan yang ada ya. Semangat!