1. Panduan mendetail tentang Git untuk pemula

Hari ini kita akan berbicara tentang sistem kontrol versi, yaitu Git.

Anda benar-benar tidak bisa menjadi programmer penuh tanpa mengetahui dan memahami alat ini. Tentu saja, Anda tidak harus menyimpan semua perintah dan fitur Git di kepala Anda untuk terus digunakan. Anda perlu mengetahui sekumpulan perintah yang akan membantu Anda memahami semua yang terjadi.

Dasar Git

Git adalah sistem kontrol versi terdistribusi untuk kode kita. Mengapa kita membutuhkannya? Tim membutuhkan semacam sistem untuk mengelola pekerjaan mereka. Diperlukan untuk melacak perubahan yang terjadi dari waktu ke waktu.

Artinya, kita harus bisa melihat langkah demi langkah file mana yang telah berubah dan bagaimana caranya. Ini sangat penting saat Anda menyelidiki apa yang berubah dalam konteks satu tugas, sehingga memungkinkan untuk mengembalikan perubahan tersebut.

Bayangkan situasi berikut: kami memiliki kode yang berfungsi, semua yang ada di dalamnya bagus, tetapi kemudian kami memutuskan untuk meningkatkan atau mengubah sesuatu. Bukan masalah besar, tetapi "peningkatan" kami merusak setengah dari fitur program dan membuatnya tidak mungkin berfungsi. Jadi sekarang apa? Tanpa Git, Anda harus duduk dan berpikir berjam-jam, mencoba mengingat bagaimana awalnya semuanya. Tetapi dengan Git, kami hanya membatalkan komit — dan hanya itu.

Atau bagaimana jika ada dua pengembang yang membuat perubahan kode mereka sendiri pada saat yang bersamaan? Tanpa Git, mereka menyalin file kode asli dan memodifikasinya secara terpisah. Ada saatnya keduanya ingin menambahkan perubahan mereka ke direktori utama. Apa yang Anda lakukan dalam kasus ini?

Tidak akan ada masalah seperti itu jika Anda menggunakan Git.

Menginstal Git

Ayo instal Java di komputer Anda Proses ini sedikit berbeda untuk sistem operasi yang berbeda.

Menginstal di Windows

Seperti biasa, Anda perlu mengunduh dan menjalankan file exe. Semuanya sederhana di sini: klik tautan Google pertama , lakukan penginstalan, dan hanya itu. Untuk melakukan ini, kami akan menggunakan konsol bash yang disediakan oleh Windows.

Di Windows, Anda perlu menjalankan Git Bash. Begini tampilannya di Start Menu:

Sekarang ini adalah prompt perintah yang dapat Anda kerjakan.

Untuk menghindari keharusan pergi ke folder dengan proyek setiap kali untuk membuka Git di sana, Anda dapat membuka command prompt di folder proyek dengan tombol kanan mouse dengan jalur yang kita butuhkan:

Menginstal di Linux

Biasanya Git adalah bagian dari distribusi Linux dan sudah diinstal, karena ini adalah alat yang awalnya ditulis untuk pengembangan kernel Linux. Tetapi ada situasi ketika tidak. Untuk memeriksanya, Anda perlu membuka terminal dan menulis: git --version. Jika Anda mendapatkan jawaban yang dapat dipahami, maka tidak ada yang perlu diinstal.

Buka terminal dan instal. Untuk Ubuntu, Anda perlu menulis: sudo apt-get install git. Dan begitulah: sekarang Anda dapat menggunakan Git di terminal mana saja.

Menginstal di macOS

Di sini juga, Anda harus terlebih dahulu memeriksa apakah Git sudah ada (lihat di atas, sama seperti di Linux).

Jika Anda tidak memilikinya, maka cara termudah untuk mendapatkannya adalah mengunduh versi terbaru . Jika Xcode diinstal, maka Git pasti akan diinstal secara otomatis.

Pengaturan Git

Git memiliki pengaturan pengguna untuk pengguna yang akan mengirimkan pekerjaan. Ini masuk akal dan perlu, karena Git mengambil informasi ini untuk bidang Penulis saat komit dibuat.

Siapkan nama pengguna dan kata sandi untuk semua proyek Anda dengan menjalankan perintah berikut:

Jika Anda perlu mengubah pembuat untuk proyek tertentu (untuk proyek pribadi, misalnya), Anda dapat menghapus "--global". Ini akan memberi kita yang berikut:

Sedikit teori

Untuk menyelami topik, kami harus memperkenalkan Anda pada beberapa kata dan tindakan baru... Jika tidak, tidak akan ada yang perlu dibicarakan. Tentu saja, jargon ini berasal dari bahasa Inggris, jadi saya akan menambahkan terjemahan dalam tanda kurung.

Kata-kata dan tindakan apa?

• repositori git
• melakukan
• cabang
• menggabungkan
• konflik
• menarik
• dorongan
• cara mengabaikan beberapa file (.gitignore)

Dan seterusnya.

Status di Git

Git memiliki beberapa patung yang perlu dipahami dan diingat:

• tidak terlacak
• diubah
• dipentaskan
• berkomitmen

Bagaimana seharusnya Anda memahami ini?

Ini adalah status yang berlaku untuk file yang berisi kode kami. Dengan kata lain, siklus hidup mereka biasanya terlihat seperti ini:

• File yang dibuat tetapi belum ditambahkan ke repositori memiliki status "tidak terlacak".
• Saat kami melakukan perubahan pada file yang telah ditambahkan ke repositori Git, maka statusnya "dimodifikasi".
• Di antara file yang telah kami ubah, kami memilih yang kami butuhkan (misalnya, kami tidak memerlukan kelas yang dikompilasi), dan kelas ini diubah menjadi status "bertahap".
• Komit dibuat dari file yang disiapkan dalam keadaan bertahap dan masuk ke repositori Git. Setelah itu, tidak ada file dengan status "dipentaskan". Tapi mungkin masih ada file yang statusnya "dimodifikasi".

Begini tampilannya:

Apa itu komit?

Komit adalah acara utama dalam hal kontrol versi. Ini berisi semua perubahan yang dilakukan sejak komit dimulai. Komit ditautkan bersama seperti daftar tertaut tunggal.

Secara khusus, ada komit pertama. Saat komit kedua dibuat, ia (komit kedua) mengetahui apa yang terjadi setelah komit pertama. Dan dengan cara ini, informasi dapat dilacak.

Sebuah komit juga memiliki informasinya sendiri, yang disebut metadata:

• pengidentifikasi unik komit, yang dapat digunakan untuk menemukannya
• nama pembuat komit, yang membuatnya
• tanggal komit dibuat
• komentar yang menjelaskan apa yang dilakukan selama komit

Begini tampilannya:

Apa itu cabang?

Cabang adalah penunjuk ke beberapa komit. Karena sebuah komit mengetahui komit mana yang mendahuluinya, ketika sebuah cabang menunjuk ke sebuah komit, semua komit sebelumnya juga berlaku untuknya.

Karenanya, kami dapat mengatakan bahwa Anda dapat memiliki cabang sebanyak yang Anda inginkan untuk menunjuk ke komit yang sama.

Pekerjaan terjadi di cabang, jadi saat komit baru dibuat, cabang memindahkan penunjuknya ke komit yang lebih baru.

Memulai dengan Git

Anda dapat bekerja dengan repositori lokal sendiri maupun dengan repositori jarak jauh.

Untuk mempraktikkan perintah yang diperlukan, Anda dapat membatasi diri pada repositori lokal. Itu hanya menyimpan semua informasi proyek secara lokal di folder .git.

Jika kita berbicara tentang repositori jarak jauh, maka semua informasi disimpan di suatu tempat di server jarak jauh: hanya salinan proyek yang disimpan secara lokal. Perubahan yang dilakukan pada salinan lokal Anda dapat didorong (git push) ke repositori jarak jauh.

Dalam diskusi kami di sini dan di bawah ini, kami berbicara tentang bekerja dengan Git di konsol. Tentu saja, Anda dapat menggunakan semacam solusi berbasis GUI (misalnya, IntelliJ IDEA), tetapi pertama-tama Anda harus mencari tahu perintah apa yang sedang dijalankan dan apa artinya.

Bekerja dengan Git di repositori lokal

Untuk membuat repositori lokal, Anda perlu menulis:

Ini akan membuat folder .git tersembunyi di direktori konsol saat ini.

Folder .git menyimpan semua informasi tentang repositori Git. Jangan hapus ;)

Selanjutnya, file ditambahkan ke proyek, dan diberi status "Tidak Dilacak". Untuk memeriksa status pekerjaan Anda saat ini, tulis ini:

Kami berada di cabang master, dan di sini kami akan tetap sampai kami beralih ke cabang lain.

Ini menunjukkan file mana yang telah diubah tetapi belum ditambahkan ke status "dipentaskan". Untuk menambahkannya ke status "staged", Anda perlu menulis "git add". Kami memiliki beberapa opsi di sini, misalnya:

• git add -A — tambahkan semua file ke status "staged".
• git tambahkan. — tambahkan semua file dari folder ini dan semua subfolder. Intinya sama dengan yang sebelumnya;
• git add <file name> — menambahkan file tertentu. Di sini Anda dapat menggunakan ekspresi reguler untuk menambahkan file menurut beberapa pola. Misalnya, git add *.java: Artinya Anda hanya ingin menambahkan file dengan ekstensi java.

Dua opsi pertama jelas sederhana. Segalanya menjadi lebih menarik dengan tambahan terbaru, jadi mari kita menulis:

Untuk memeriksa statusnya, kami menggunakan perintah yang sudah kami kenal:

Di sini Anda dapat melihat bahwa regular expression telah bekerja dengan benar: test_resource.txt sekarang memiliki status "staged".

Dan terakhir, tahap terakhir untuk bekerja dengan repositori lokal (ada satu lagi saat bekerja dengan repositori jarak jauh;)) — membuat komit baru:

Selanjutnya adalah perintah yang bagus untuk melihat riwayat komit di cabang. Mari kita manfaatkan:

Di sini Anda dapat melihat bahwa kami telah membuat komit pertama kami dan menyertakan teks yang kami sediakan di baris perintah. Sangat penting untuk dipahami bahwa teks ini harus menjelaskan seakurat mungkin apa yang dilakukan selama komit ini. Ini akan membantu kita berkali-kali di masa depan.

Pembaca yang ingin tahu yang belum tertidur mungkin bertanya-tanya apa yang terjadi dengan file GitTest.java. Mari kita cari tahu sekarang. Untuk melakukan ini, kami menggunakan:

Seperti yang Anda lihat, itu masih "tidak terlacak" dan menunggu di sayap. Tetapi bagaimana jika kita sama sekali tidak ingin menambahkannya ke proyek? Terkadang itu terjadi.

Agar lebih menarik, sekarang mari kita coba ubah file test_resource.txt kita. Mari tambahkan beberapa teks di sana dan periksa statusnya:

Di sini Anda dapat dengan jelas melihat perbedaan antara status "tidak terlacak" dan "dimodifikasi".

GitTest.java "tidak terlacak", sedangkan test_resource.txt "dimodifikasi".

Sekarang kita memiliki file dalam keadaan dimodifikasi, kita dapat memeriksa perubahan yang dilakukan padanya. Ini dapat dilakukan dengan menggunakan perintah berikut:

Yaitu, Anda dapat dengan jelas melihat di sini apa yang saya tambahkan ke file teks kami: halo dunia!

Mari tambahkan perubahan kita ke file teks dan buat komit:

Untuk melihat semua komitmen, tulis:

Seperti yang Anda lihat, kami sekarang memiliki dua komitmen.

Kami akan menambahkan GitTest.java dengan cara yang sama. Tidak ada komentar di sini, hanya perintah:

Bekerja dengan .gitignore

Jelas, kami hanya ingin menyimpan kode sumber saja, dan tidak ada yang lain, di dalam repositori. Jadi apa lagi yang bisa ada? Minimal, kelas dan/atau file yang dikompilasi dihasilkan oleh lingkungan pengembangan.

Untuk memberi tahu Git agar mengabaikannya, kita perlu membuat file khusus. Lakukan ini: buat file bernama .gitignore di root proyek. Setiap baris dalam file ini mewakili pola yang harus diabaikan.

Dalam contoh ini, file .gitignore akan terlihat seperti ini:

Mari lihat:

• Baris pertama adalah mengabaikan semua file dengan ekstensi .class
• Baris kedua adalah mengabaikan folder "target" dan semua isinya
• Baris ketiga adalah mengabaikan semua file dengan ekstensi .iml
• Baris keempat adalah mengabaikan folder .idea

Mari kita coba menggunakan contoh. Untuk melihat cara kerjanya, mari tambahkan GitTest.class yang dikompilasi ke proyek dan periksa status proyek:

Jelas, kami tidak ingin secara tidak sengaja menambahkan kelas yang dikompilasi ke proyek (menggunakan git add -A). Untuk melakukan ini, buat file .gitignore dan tambahkan semua yang dijelaskan sebelumnya:

Sekarang mari gunakan komit untuk menambahkan file .gitignore ke proyek:

Dan sekarang momen kebenaran: kami memiliki kelas terkompilasi GitTest.class yang "tidak terlacak", yang tidak ingin kami tambahkan ke repositori Git.

Sekarang kita akan melihat efek dari file .gitignore:

Sempurna! .gitignore +1 :)

Bekerja dengan cabang

Secara alami, bekerja di satu cabang saja tidak nyaman bagi pengembang soliter, dan tidak mungkin bila ada lebih dari satu orang dalam satu tim. Makanya kami punya cabang.

Cabang hanyalah pointer bergerak untuk melakukan.

Pada bagian ini, kita akan menjelajahi cara bekerja di cabang yang berbeda: cara menggabungkan perubahan dari satu cabang ke cabang lainnya, konflik apa yang mungkin muncul, dan banyak lagi.

Untuk melihat daftar semua cabang di repositori dan memahami di mana Anda berada, Anda perlu menulis:

Anda dapat melihat bahwa kami hanya memiliki satu cabang master. Tanda bintang di depannya menunjukkan bahwa kita ada di dalamnya. Omong-omong, Anda juga bisa menggunakan perintah "git status" untuk mengetahui di cabang mana kita berada.

Lalu ada beberapa opsi untuk membuat cabang (mungkin ada lebih banyak — ini yang saya gunakan):

• buat cabang baru berdasarkan cabang tempat kita berada (99% kasus)
• buat cabang berdasarkan komit tertentu (1% kasus)

Mari buat cabang berdasarkan komit tertentu

Kami akan mengandalkan pengidentifikasi unik komit. Untuk menemukannya, kami menulis:

Kami telah menyoroti komit dengan komentar "menambahkan halo dunia..." Pengidentifikasi uniknya adalah 6c44e53d06228f888f2f454d3cb8c1c976dd73f8. Kami ingin membuat cabang "pengembangan" yang dimulai dari komit ini. Untuk melakukan ini, kami menulis:

Cabang dibuat hanya dengan dua komit pertama dari cabang master. Untuk memverifikasi ini, pertama-tama kami memastikan untuk beralih ke cabang lain dan melihat jumlah komit di sana:

Dan seperti yang diharapkan, kami memiliki dua komitmen. Ngomong-ngomong, inilah poin yang menarik: belum ada file .gitignore di cabang ini, jadi file kompilasi kami (GitTest.class) sekarang disorot dengan status "tidak terlacak".

Sekarang kami dapat meninjau kembali cabang kami dengan menulis ini:

Anda dapat melihat bahwa ada dua cabang: "master" dan "development". Kami sedang dalam pengembangan.

Mari buat cabang berdasarkan yang sekarang

Cara kedua untuk membuat cabang adalah membuatnya dari yang lain. Kami ingin membuat cabang berdasarkan cabang master. Pertama, kita perlu beralih ke sana, dan langkah selanjutnya adalah membuat yang baru. Mari lihat:

• git checkout master — beralih ke cabang master
• git status — verifikasi bahwa kita benar-benar berada di cabang master

Di sini Anda dapat melihat bahwa kami beralih ke cabang master, file .gitignore berlaku, dan kelas yang dikompilasi tidak lagi disorot sebagai "tidak terlacak".

Sekarang kami membuat cabang baru berdasarkan cabang master:

Jika Anda tidak yakin apakah cabang ini sama dengan "master", Anda dapat dengan mudah memeriksa dengan menjalankan "git log" dan melihat semua komit. Seharusnya ada empat dari mereka.

Resolusi konflik

Sebelum kita menjelajahi apa itu konflik, kita perlu berbicara tentang menggabungkan satu cabang ke cabang lainnya.

Gambar ini menggambarkan proses penggabungan satu cabang ke cabang lainnya:

Di sini, kami memiliki cabang utama. Di beberapa titik, cabang sekunder dibuat dari cabang utama dan kemudian dimodifikasi. Setelah pekerjaan selesai, kita perlu menggabungkan satu cabang ke cabang lainnya.

Dalam contoh kami, kami membuat cabang feature/update-txt-files. Seperti yang ditunjukkan oleh nama cabang, kami memperbarui teks.

Sekarang kita perlu membuat komit baru untuk pekerjaan ini:

Sekarang, jika kita ingin menggabungkan cabang feature/update-txt-files menjadi master, kita perlu pergi ke master dan menulis "git merge feature/update-txt-files":

Akibatnya, cabang master sekarang juga menyertakan komit yang ditambahkan ke file fitur/perbarui-txt.

Fungsionalitas ini telah ditambahkan, sehingga Anda dapat menghapus cabang fitur. Untuk melakukan ini, kami menulis:

Mari kita perumit situasinya: sekarang katakanlah Anda perlu mengubah file txt lagi. Tapi sekarang file ini juga akan diubah di cabang master. Dengan kata lain, itu akan berubah secara paralel. Git tidak akan dapat mengetahui apa yang harus dilakukan ketika kita ingin menggabungkan kode baru kita ke dalam cabang master.

Kami akan membuat cabang baru berdasarkan master, membuat perubahan pada text_resource.txt, dan membuat komit untuk pekerjaan ini:

... kami membuat perubahan pada file

Buka cabang master dan perbarui juga file teks ini pada baris yang sama seperti di cabang fitur:

… kami memperbarui test_resource.txt

Dan sekarang hal yang paling menarik: kita perlu menggabungkan perubahan dari cabang feature/add-header ke master. Kami berada di cabang master, jadi kami hanya perlu menulis:

Tetapi hasilnya akan menjadi konflik di file test_resource.txt:

Di sini kita dapat melihat bahwa Git tidak dapat memutuskan sendiri cara menggabungkan kode ini. Ini memberi tahu kita bahwa kita perlu menyelesaikan konflik terlebih dahulu, dan baru kemudian melakukan komit.

OKE. Kami membuka file dengan konflik di editor teks dan melihat:

Untuk memahami apa yang dilakukan Git di sini, kita perlu mengingat perubahan apa yang kita buat dan di mana, lalu membandingkan:

1. Perubahan yang ada di baris ini di cabang master ditemukan antara "<<<<<<<< HEAD" dan "=======".
2. Perubahan yang ada di cabang feature/add-header ditemukan antara "=======" dan ">>>>>>> feature/add-header".

Beginilah cara Git memberi tahu kami bahwa ia tidak dapat menemukan cara melakukan penggabungan di lokasi ini dalam file. Itu membagi bagian ini menjadi dua bagian dari cabang yang berbeda dan mengundang kita untuk menyelesaikan sendiri konflik gabungan.

Cukup adil. Saya dengan berani memutuskan untuk menghapus semuanya, hanya menyisakan kata "header":

Mari kita lihat status perubahannya. Deskripsi akan sedikit berbeda. Alih-alih status "dimodifikasi", kami telah "membatalkan". Jadi bisakah kita menyebutkan status kelima? Saya tidak berpikir ini perlu. Mari kita lihat:

Kita dapat meyakinkan diri kita sendiri bahwa ini adalah kasus yang spesial dan tidak biasa. Ayo lanjutkan:

Anda mungkin memperhatikan bahwa deskripsi menyarankan hanya menulis "git commit". Mari kita coba menulis bahwa:

Dan begitu saja, kami melakukannya — kami menyelesaikan konflik di konsol.

Tentu saja, hal ini dapat dilakukan dengan lebih mudah di lingkungan pengembangan terintegrasi. Misalnya, di IntelliJ IDEA, semuanya diatur dengan sangat baik sehingga Anda dapat melakukan semua tindakan yang diperlukan langsung di dalamnya. Tapi IDE melakukan banyak hal "di bawah tenda", dan kita sering tidak mengerti apa yang sebenarnya terjadi di sana. Dan ketika tidak ada pemahaman, masalah bisa muncul.

Bekerja dengan repositori jarak jauh

Langkah terakhir adalah memikirkan beberapa perintah lagi yang diperlukan untuk bekerja dengan repositori jarak jauh.

Seperti yang saya katakan, repositori jarak jauh adalah suatu tempat di mana repositori disimpan dan dari mana Anda dapat mengkloningnya.

Apa jenis repositori jarak jauh yang ada? Contoh:

• GitHub adalah platform penyimpanan terbesar untuk repositori dan pengembangan kolaboratif.
• GitLab adalah alat berbasis web untuk siklus hidup DevOps dengan sumber terbuka. Ini adalah sistem berbasis Git untuk mengelola repositori kode dengan wikinya sendiri, sistem pelacakan bug, pipa CI/CD, dan fungsi lainnya.
• BitBucket adalah layanan web untuk hosting proyek dan pengembangan kolaboratif berdasarkan sistem kontrol versi Mercurial dan Git. Pada suatu waktu itu memiliki keuntungan besar dibandingkan GitHub karena menawarkan repositori pribadi gratis. Tahun lalu, GitHub juga memperkenalkan kemampuan ini kepada semua orang secara gratis.
• Dan seterusnya…

Saat bekerja dengan repositori jarak jauh, hal pertama yang harus dilakukan adalah mengkloning proyek ke repositori lokal Anda.

Untuk ini, kami mengekspor proyek yang kami buat secara lokal Sekarang semua orang dapat mengkloningnya sendiri dengan menulis:

Sekarang ada salinan lokal lengkap dari proyek tersebut. Untuk memastikan bahwa salinan lokal dari proyek tersebut adalah yang terbaru, Anda perlu menarik proyek tersebut dengan menulis:

Dalam kasus kami, tidak ada yang berubah di repositori jarak jauh saat ini, jadi jawabannya adalah: Sudah diperbarui.

Tetapi jika kami membuat perubahan apa pun pada repositori jarak jauh, yang lokal diperbarui setelah kami menariknya.

Dan terakhir, perintah terakhir adalah mendorong data ke repositori jarak jauh. Ketika kita telah melakukan sesuatu secara lokal dan ingin mengirimkannya ke repositori jarak jauh, pertama-tama kita harus membuat komit baru secara lokal. Untuk mendemonstrasikan ini, mari tambahkan sesuatu yang lain ke file teks kita:

Sekarang sesuatu yang sangat umum bagi kami — kami membuat komit untuk pekerjaan ini:

Perintah untuk mendorong ini ke repositori jarak jauh adalah:

Itu saja untuk saat ini!

2. Cara bekerja dengan Git di IntelliJ IDEA

Di bagian ini, Anda akan mempelajari cara bekerja dengan Git di IntelliJ IDEA.

Input yang diperlukan:

1. Baca, ikuti, dan pahami bagian sebelumnya. Ini akan membantu memastikan bahwa semuanya sudah diatur dan siap digunakan.
2. Instal IntelliJ IDEA. Semuanya harus beres di sini :)
3. Alokasikan satu jam untuk mencapai penguasaan penuh.

Mari bekerja dengan proyek demo yang saya gunakan untuk artikel tentang Git.

Kloning proyek secara lokal

Ada dua opsi di sini:

1. Jika Anda sudah memiliki akun GitHub dan ingin mendorong sesuatu nanti, lebih baik fork proyek dan mengkloning salinan Anda sendiri. Anda dapat membaca tentang cara membuat fork di artikel lain di bawah judul Contoh alur kerja fork .
2. Kloning repositori dan lakukan semuanya secara lokal tanpa kemampuan untuk mendorong semuanya ke server.

Untuk mengkloning proyek dari GitHub, Anda perlu menyalin tautan proyek dan meneruskannya ke IntelliJ IDEA:

1. Salin alamat proyek:

2. Buka IntelliJ IDEA dan pilih "Dapatkan dari Kontrol Versi":

3. Salin dan tempel alamat proyek:

4. Anda akan diminta untuk membuat proyek IntelliJ IDEA. Menerima pesanan:

5. Karena tidak ada sistem build, kami memilih "Buat proyek dari sumber yang ada":

6. Selanjutnya Anda akan melihat layar yang indah ini:

Sekarang setelah kami menemukan kloning, Anda dapat melihat-lihat.

Sekilas tentang IntelliJ IDEA sebagai UI Git

Perhatikan lebih dekat proyek yang dikloning: Anda sudah bisa mendapatkan banyak informasi tentang sistem kontrol versi.

Pertama, kami memiliki panel Kontrol Versi di sudut kiri bawah. Di sini Anda dapat menemukan semua perubahan lokal dan mendapatkan daftar komit (analog dengan "git log").

Mari beralih ke diskusi tentang Log. Ada visualisasi tertentu yang membantu kita memahami dengan tepat bagaimana perkembangan telah berjalan. Misalnya, Anda dapat melihat bahwa cabang baru telah dibuat dengan menambahkan tajuk ke komit txt, yang kemudian digabungkan ke dalam cabang master. Jika Anda mengklik komit, Anda dapat melihat di sudut kanan semua informasi tentang komit: semua perubahan dan metadatanya.

Selain itu, Anda dapat melihat perubahan yang sebenarnya. Kami juga melihat bahwa konflik diselesaikan di sana. IDEA juga menyajikan ini dengan sangat baik.

Jika Anda mengklik dua kali pada file yang diubah selama komit ini, kami akan melihat bagaimana konflik diselesaikan:

Kami mencatat bahwa di kiri dan kanan kami memiliki dua versi dari file yang sama yang perlu digabungkan menjadi satu. Dan di tengah, kami memiliki hasil gabungan akhir.

Ketika sebuah proyek memiliki banyak cabang, komit, dan pengguna, Anda perlu mencari secara terpisah berdasarkan cabang, pengguna, dan tanggal:

Sebelum memulai, ada baiknya juga menjelaskan bagaimana memahami di cabang mana kita berada.

Di pojok kanan bawah, ada tombol bertuliskan "Git: master". Apa pun yang mengikuti "Git:" adalah cabang saat ini. Jika Anda mengklik tombol tersebut, Anda dapat melakukan banyak hal berguna: beralih ke cabang lain, membuat yang baru, mengganti nama yang sudah ada, dan seterusnya.

Bekerja dengan repositori

Tombol pintas yang berguna

Untuk pekerjaan selanjutnya, Anda perlu mengingat beberapa hotkey yang sangat berguna:

1. CTRL+T — Dapatkan perubahan terbaru dari repositori jarak jauh (git pull).
2. CTRL+K — Buat komit / lihat semua perubahan saat ini. Ini termasuk file yang tidak terlacak dan yang dimodifikasi (git commit).
3. CTRL+SHIFT+K — Ini adalah perintah untuk mendorong perubahan ke repositori jarak jauh. Semua komit yang dibuat secara lokal dan belum ada di repositori jarak jauh akan didorong (git push).
4. ALT+CTRL+Z — Kembalikan perubahan pada file tertentu ke status komit terakhir yang dibuat di repositori lokal. Jika Anda memilih seluruh proyek di pojok kiri atas, Anda dapat mengembalikan perubahan di semua file.

Apa yang kita inginkan?

Untuk menyelesaikan pekerjaan, kita perlu menguasai skenario dasar yang digunakan di mana-mana.

Tujuannya adalah untuk mengimplementasikan fungsionalitas baru di cabang terpisah dan kemudian mendorongnya ke repositori jarak jauh (maka Anda juga perlu membuat permintaan tarik ke cabang utama, tetapi itu di luar cakupan pelajaran ini).

Apa yang diperlukan untuk melakukan ini?

1. Dapatkan semua perubahan saat ini di cabang utama (misalnya, "master").

2. Dari cabang utama ini, buat cabang terpisah untuk pekerjaan Anda.

3. Menerapkan fungsi baru.

4. Pergi ke cabang utama dan periksa apakah ada perubahan baru saat kami bekerja. Jika tidak, maka semuanya baik-baik saja. Tetapi jika ada perubahan, maka kami melakukan hal berikut: pergi ke cabang kerja dan rebase perubahan dari cabang utama ke cabang kami. Jika semuanya berjalan dengan baik, maka bagus. Tapi sangat mungkin akan ada konflik. Seperti yang terjadi, mereka dapat diselesaikan terlebih dahulu, tanpa membuang waktu di repositori jarak jauh.

   Apakah Anda bertanya-tanya mengapa Anda harus melakukan ini? Ini sopan santun dan mencegah terjadinya konflik setelah mendorong cabang Anda ke repositori lokal (tentu saja ada kemungkinan konflik masih akan terjadi, tetapi menjadi jauh lebih kecil).

5. Dorong perubahan Anda ke repositori jarak jauh.

Bagaimana cara mendapatkan perubahan dari server jarak jauh?

Kami menambahkan deskripsi ke README dengan komit baru dan ingin mendapatkan perubahan ini. Jika perubahan dilakukan baik di repositori lokal maupun di repositori jarak jauh, maka kita diundang untuk memilih antara penggabungan dan rebase. Kami memilih untuk bergabung.

Masukkan CTRL+T :

Anda sekarang dapat melihat bagaimana README telah berubah, yaitu perubahan dari repositori jarak jauh ditarik masuk, dan di pojok kanan bawah Anda dapat melihat semua detail perubahan yang berasal dari server.

Buat cabang baru berdasarkan master

Semuanya sederhana di sini.

Pergi ke pojok kanan bawah dan klik Git: master . Pilih + Cabang Baru .

Biarkan kotak centang Checkout branch dipilih dan masukkan nama cabang baru. Dalam kasus kami: ini akan menjadi readme-improver .

Git: master kemudian akan berubah menjadi Git: readme-improver .

Mari kita simulasikan pekerjaan paralel

Agar konflik muncul, seseorang harus membuatnya.

Kami akan mengedit README dengan komit baru melalui browser, sehingga mensimulasikan kerja paralel. Seolah-olah seseorang membuat perubahan pada file yang sama saat kami sedang mengerjakannya. Akibatnya akan terjadi konflik. Kami akan menghapus kata "fully" dari baris 10.

Terapkan fungsionalitas kami

Tugas kita adalah mengubah README dan menambahkan deskripsi ke artikel baru. Artinya, pekerjaan di Git dilakukan melalui IntelliJ IDEA. Tambahkan ini:

Perubahan sudah selesai. Sekarang kita dapat membuat komit. Tekan CTRL+K , yang memberi kita:

Sebelum membuat komit, kita perlu mencermati apa yang ditawarkan jendela ini.

Di bagian Pesan Komit , kami menulis teks yang terkait dengan komit. Kemudian untuk membuatnya, kita perlu mengklik Commit .

Kami menulis bahwa README telah berubah dan membuat komit. Peringatan muncul di sudut kiri bawah dengan nama komit:

Periksa apakah cabang utama telah berubah

Kami menyelesaikan tugas kami. Berhasil. Kami menulis tes. Semuanya baik-baik saja. Namun sebelum mendorong ke server, kami masih perlu memeriksa apakah ada perubahan di cabang utama untuk sementara. Bagaimana itu bisa terjadi? Cukup mudah: seseorang menerima tugas setelah Anda, dan seseorang menyelesaikannya lebih cepat daripada Anda menyelesaikan tugas Anda.

Jadi kita harus pergi ke cabang master. Untuk melakukan ini, kita perlu melakukan apa yang ditunjukkan di pojok kanan bawah pada tangkapan layar di bawah ini:

Di cabang master, tekan CTRL+T untuk mendapatkan perubahan terbaru dari server jarak jauh. Melihat apa perubahannya, Anda dapat dengan mudah melihat apa yang terjadi:

Kata "fully" telah dihapus. Mungkin seseorang dari pemasaran memutuskan bahwa itu tidak boleh ditulis seperti itu dan memberi tugas kepada pengembang untuk memperbaruinya.

Kami sekarang memiliki salinan lokal dari versi terbaru dari cabang master. Kembali ke readme-improver .

Sekarang kita perlu mengubah perubahan dari cabang master menjadi milik kita. Kami melakukan ini:

Jika Anda melakukan semuanya dengan benar dan mengikuti saya, hasilnya akan menunjukkan konflik dalam file README:

Di sini kami juga memiliki banyak informasi untuk dipahami dan diserap. Ditampilkan di sini adalah daftar file (dalam kasus kami, satu file) yang memiliki konflik. Kita dapat memilih dari tiga opsi:

1. terima milik Anda — hanya terima perubahan dari readme-improver.
2. terima milik mereka — hanya terima perubahan dari master.
3. gabung — pilih sendiri apa yang ingin Anda simpan dan apa yang akan dibuang.

Tidak jelas apa yang berubah. Jika ada perubahan di cabang master, pasti dibutuhkan di sana, jadi kami tidak bisa begitu saja menerima perubahan kami. Karenanya, kami memilih merge :

Di sini kita dapat melihat bahwa ada tiga bagian:

1. Ini adalah perubahan dari readme-improver.
2. Hasil gabungan. Untuk saat ini, itulah yang ada sebelum perubahan.
3. Perubahan dari cabang master.

Kami perlu menghasilkan hasil gabungan yang akan memuaskan semua orang. Meninjau apa yang diubah SEBELUM perubahan kami, kami menyadari bahwa mereka hanya menghapus kata "fully". Oke tidak masalah! Itu artinya kita juga akan menghapusnya di hasil gabungan dan kemudian menambahkan perubahan kita. Setelah kami memperbaiki hasil gabungan, kami dapat mengklik Terapkan .

Kemudian pemberitahuan akan muncul, memberi tahu kami bahwa rebase berhasil:

Di sana! Kami menyelesaikan konflik pertama kami melalui IntelliJ IDEA.

Dorong perubahan ke server jarak jauh

Langkah selanjutnya adalah mendorong perubahan ke server jarak jauh dan membuat permintaan tarik. Untuk melakukan ini, cukup tekan CTRL+SHIFT+K . Kemudian kita mendapatkan:

Di sebelah kiri, akan ada daftar komit yang belum dimasukkan ke repositori jarak jauh. Di sebelah kanan akan ada semua file yang telah diubah. Dan itu saja! Tekan Push dan Anda akan mengalami kebahagiaan :)

Jika push berhasil, akan muncul notifikasi seperti ini di pojok kanan bawah:

Bonus: membuat permintaan tarik

Mari kita pergi ke repositori GitHub dan kita melihat bahwa GitHub sudah mengetahui apa yang kita inginkan:

Klik Bandingkan & tarik permintaan . Kemudian klik Buat permintaan tarik . Karena kita sudah menyelesaikan konflik sebelumnya, sekarang saat membuat pull request, kita bisa langsung menggabungkannya:

Itu saja untuk saat ini!