1. Panduan terperinci untuk Git untuk pemula

Hari ini kita akan bercakap tentang sistem kawalan versi, iaitu Git.

Anda benar-benar tidak boleh menjadi pengaturcara sepenuhnya tanpa mengetahui dan memahami alat ini. Sudah tentu, anda tidak perlu menyimpan semua arahan dan ciri Git dalam kepala anda untuk digunakan secara berterusan. Anda perlu mengetahui satu set arahan yang akan membantu anda memahami semua yang berlaku.

Asas Git

Git ialah sistem kawalan versi teragih untuk kod kami. Mengapa kita memerlukannya? Pasukan memerlukan beberapa jenis sistem untuk mengurus kerja mereka. Ia diperlukan untuk menjejaki perubahan yang berlaku dari semasa ke semasa.

Iaitu, kita perlu dapat melihat langkah demi langkah fail mana yang telah berubah dan bagaimana. Ini amat penting apabila anda menyiasat perkara yang berubah dalam konteks satu tugasan, membolehkan perubahan itu dikembalikan.

Mari bayangkan situasi berikut: kami mempunyai kod yang berfungsi, segala-galanya di dalamnya adalah baik, tetapi kemudian kami memutuskan untuk menambah baik atau mengubah sesuatu. Bukan masalah besar, tetapi "penambahbaikan" kami memecahkan separuh daripada ciri program dan menjadikannya mustahil untuk berfungsi. Jadi sekarang apa? Tanpa Git, anda perlu duduk dan berfikir selama berjam-jam, cuba mengingati bagaimana semuanya pada asalnya. Tetapi dengan Git, kami hanya melancarkan semula komit — dan itu sahaja.

Atau bagaimana jika terdapat dua pembangun membuat perubahan kod mereka sendiri pada masa yang sama? Tanpa Git, mereka menyalin fail kod asal dan mengubah suainya secara berasingan. Akan tiba masanya apabila kedua-duanya ingin menambah perubahan mereka pada direktori utama. Apa yang anda lakukan dalam kes ini?

Tidak akan ada masalah seperti itu jika anda menggunakan Git.

Memasang Git

Mari pasang Java pada komputer anda Proses ini berbeza sedikit untuk sistem pengendalian yang berbeza.

Memasang pada Windows

Seperti biasa, anda perlu memuat turun dan menjalankan fail exe. Semuanya mudah di sini: klik pada pautan Google yang pertama , lakukan pemasangan, dan itu sahaja. Untuk melakukan ini, kami akan menggunakan konsol bash yang disediakan oleh Windows.

Pada Windows, anda perlu menjalankan Git Bash. Begini rupanya dalam Menu Mula:

Sekarang ini ialah gesaan arahan yang boleh anda gunakan.

Untuk mengelak daripada pergi ke folder dengan projek setiap kali untuk memesan untuk membuka Git di sana, anda boleh membuka gesaan arahan dalam folder projek dengan butang kanan tetikus dengan laluan yang kami perlukan:

Memasang pada Linux

Biasanya Git adalah sebahagian daripada pengedaran Linux dan sudah dipasang, kerana ia adalah alat yang pada asalnya ditulis untuk pembangunan kernel Linux. Tetapi ada situasi yang tidak. Untuk menyemak, anda perlu membuka terminal dan tulis: git --version. Jika anda mendapat jawapan yang boleh difahami, maka tiada apa yang perlu dipasang.

Buka terminal dan pasang. Untuk Ubuntu, anda perlu menulis: sudo apt-get install git. Dan itu sahaja: kini anda boleh menggunakan Git dalam mana-mana terminal.

Memasang pada macOS

Di sini juga, anda perlu menyemak sama ada Git sudah ada (lihat di atas, sama seperti di Linux).

Jika anda tidak memilikinya, maka cara paling mudah untuk mendapatkannya ialah memuat turun versi terkini . Jika Xcode dipasang, maka Git pasti akan dipasang secara automatik.

Tetapan Git

Git mempunyai tetapan pengguna untuk pengguna yang akan menyerahkan kerja. Ini masuk akal dan perlu, kerana Git mengambil maklumat ini untuk medan Pengarang apabila komit dibuat.

Sediakan nama pengguna dan kata laluan untuk semua projek anda dengan menjalankan arahan berikut:

Jika anda perlu menukar pengarang untuk projek tertentu (untuk projek peribadi, contohnya), anda boleh mengalih keluar "--global". Ini akan memberi kita perkara berikut:

Sedikit teori

Untuk menyelami topik ini, kami harus memperkenalkan anda kepada beberapa perkataan dan tindakan baharu... Jika tidak, tiada apa yang perlu dibincangkan. Sudah tentu, ini adalah jargon yang datang kepada kami daripada bahasa Inggeris, jadi saya akan menambah terjemahan dalam kurungan.

Apa perkataan dan tindakan?

• git repositori
• komited
• cawangan
• bercantum
• konflik
• tarik
• menolak
• bagaimana untuk mengabaikan beberapa fail (.giignore)

Dan sebagainya.

Status dalam Git

Git mempunyai beberapa patung yang perlu difahami dan diingati:

• tidak dikesan
• diubahsuai
• dipentaskan
• komited

Bagaimana anda harus memahami ini?

Ini ialah status yang digunakan pada fail yang mengandungi kod kami. Dalam erti kata lain, kitaran hidup mereka biasanya kelihatan seperti ini:

• Fail yang dibuat tetapi belum ditambahkan pada repositori mempunyai status "tidak dijejaki".
• Apabila kami membuat perubahan pada fail yang telah ditambahkan pada repositori Git, maka statusnya "diubah suai".
• Antara fail yang telah kami ubah, kami memilih yang kami perlukan (sebagai contoh, kami tidak memerlukan kelas yang disusun), dan kelas ini ditukar kepada status "berperingkat".
• Komit dibuat daripada fail yang disediakan dalam keadaan berperingkat dan masuk ke repositori Git. Selepas itu, tiada fail dengan status "berperingkat". Tetapi mungkin masih terdapat fail yang statusnya "diubah suai".

Begini rupanya:

Apakah komitmen?

Komit ialah peristiwa utama dalam hal kawalan versi. Ia mengandungi semua perubahan yang dibuat sejak komit bermula. Komit dipautkan bersama seperti senarai pautan tunggal.

Khususnya, terdapat komitmen pertama. Apabila komit kedua dibuat, ia (yang kedua) tahu apa yang datang selepas yang pertama. Dan dengan cara ini, maklumat boleh dikesan.

Komit juga mempunyai maklumatnya sendiri, yang dipanggil metadata:

• pengecam unik commit, yang boleh digunakan untuk mencarinya
• nama pengarang komit, yang menciptanya
• tarikh komit dibuat
• ulasan yang menerangkan perkara yang telah dilakukan semasa komit

Begini rupanya:

Apakah cawangan?

Cawangan adalah penunjuk kepada beberapa komitmen. Oleh kerana komit mengetahui komit mana yang mendahuluinya, apabila cawangan menunjuk ke komit, semua komit sebelumnya juga terpakai padanya.

Oleh itu, kami boleh mengatakan bahawa anda boleh mempunyai seberapa banyak cawangan yang anda mahu menunjukkan komitmen yang sama.

Kerja berlaku dalam cawangan, jadi apabila komit baharu dibuat, cawangan mengalihkan penunjuknya ke komit yang lebih terkini.

Bermula dengan Git

Anda boleh bekerja dengan repositori tempatan sahaja dan juga dengan repositori jauh.

Untuk mempraktikkan arahan yang diperlukan, anda boleh mengehadkan diri anda kepada repositori tempatan. Ia hanya menyimpan semua maklumat projek secara setempat dalam folder .git.

Jika kita bercakap tentang repositori jauh, maka semua maklumat disimpan di suatu tempat pada pelayan jauh: hanya salinan projek disimpan secara tempatan. Perubahan yang dibuat pada salinan tempatan anda boleh ditolak (git push) ke repositori jauh.

Dalam perbincangan kami di sini dan di bawah, kami bercakap tentang bekerja dengan Git dalam konsol. Sudah tentu, anda boleh menggunakan beberapa jenis penyelesaian berasaskan GUI (contohnya, IntelliJ IDEA), tetapi pertama sekali anda harus memikirkan arahan yang sedang dilaksanakan dan maksudnya.

Bekerja dengan Git dalam repositori tempatan

Untuk membuat repositori tempatan, anda perlu menulis:

Ini akan mencipta folder .git tersembunyi dalam direktori semasa konsol.

Folder .git menyimpan semua maklumat tentang repositori Git. Jangan padamkannya ;)

Seterusnya, fail ditambahkan pada projek dan ia diberikan status "Tidak Dijejaki". Untuk menyemak status semasa kerja anda, tulis ini:

Kami berada di cawangan induk, dan di sini kami akan kekal sehingga kami bertukar ke cawangan lain.

Ini menunjukkan fail mana yang telah berubah tetapi belum lagi ditambahkan ke status "berperingkat". Untuk menambahkannya ke status "berperingkat", anda perlu menulis "git add". Kami mempunyai beberapa pilihan di sini, sebagai contoh:

• git add -A - tambah semua fail ke status "berperingkat".
• git add . — tambah semua fail daripada folder ini dan semua subfolder. Pada asasnya sama seperti yang sebelumnya;
• git add <file name> — menambah fail tertentu. Di sini anda boleh menggunakan ungkapan biasa untuk menambah fail mengikut beberapa corak. Contohnya, git add *.java: Ini bermakna anda hanya mahu menambah fail dengan sambungan java.

Dua pilihan pertama jelas mudah. Perkara menjadi lebih menarik dengan penambahan terkini, jadi mari kita tulis:

Untuk menyemak status, kami menggunakan arahan yang telah kami ketahui:

Di sini anda boleh melihat bahawa ungkapan biasa telah berfungsi dengan betul: test_resource.txt kini mempunyai status "berperingkat".

Dan akhirnya, peringkat terakhir untuk bekerja dengan repositori tempatan (terdapat satu lagi apabila bekerja dengan repositori jauh ;)) — mencipta komit baharu:

Seterusnya ialah arahan yang bagus untuk melihat sejarah komit pada cawangan. Mari kita gunakannya:

Di sini anda boleh melihat bahawa kami telah mencipta komit pertama kami dan ia termasuk teks yang kami sediakan pada baris arahan. Adalah sangat penting untuk memahami bahawa teks ini harus menerangkan setepat mungkin perkara yang telah dilakukan semasa komitmen ini. Ini akan membantu kita berkali-kali pada masa hadapan.

Pembaca yang ingin tahu yang masih belum tertidur mungkin tertanya-tanya apa yang berlaku pada fail GitTest.java. Mari kita ketahui sekarang. Untuk melakukan ini, kami menggunakan:

Seperti yang anda lihat, ia masih "tidak dikesan" dan sedang menunggu di sayap. Tetapi bagaimana jika kita tidak mahu menambahnya pada projek itu sama sekali? Kadang-kadang itu berlaku.

Untuk menjadikan perkara lebih menarik, mari cuba tukar fail test_resource.txt kami. Mari tambahkan beberapa teks di sana dan semak status:

Di sini anda boleh melihat dengan jelas perbezaan antara status "tidak dijejaki" dan "diubah suai".

GitTest.java "tidak dijejaki", manakala test_resource.txt "diubah suai".

Memandangkan kami mempunyai fail dalam keadaan diubah suai, kami boleh menyemak perubahan yang dibuat padanya. Ini boleh dilakukan menggunakan arahan berikut:

Iaitu, anda boleh melihat dengan jelas di sini apa yang saya tambahkan pada fail teks kami: hello world!

Mari tambahkan perubahan kami pada fail teks dan buat komit:

Untuk melihat semua komitmen, tulis:

Seperti yang anda lihat, kami kini mempunyai dua komitmen.

Kami akan menambah GitTest.java dengan cara yang sama. Tiada ulasan di sini, hanya arahan:

Bekerja dengan .giignore

Jelas sekali, kami hanya mahu menyimpan kod sumber sahaja, dan tiada yang lain, dalam repositori. Jadi apa lagi yang boleh ada? Sekurang-kurangnya, kelas terkumpul dan/atau fail yang dijana oleh persekitaran pembangunan.

Untuk memberitahu Git supaya mengabaikannya, kita perlu mencipta fail khas. Lakukan ini: buat fail bernama .giignore dalam akar projek. Setiap baris dalam fail ini mewakili corak untuk diabaikan.

Dalam contoh ini, fail .giignore akan kelihatan seperti ini:

Mari kita lihat:

• Baris pertama ialah mengabaikan semua fail dengan sambungan .class
• Baris kedua ialah mengabaikan folder "sasaran" dan semua yang terkandung di dalamnya
• Baris ketiga ialah mengabaikan semua fail dengan sambungan .iml
• Baris keempat ialah mengabaikan folder .idea

Mari cuba gunakan contoh. Untuk melihat cara ia berfungsi, mari tambahkan GitTest.class yang disusun pada projek dan semak status projek:

Jelas sekali, kami tidak mahu menambah kelas yang disusun secara tidak sengaja kepada projek (menggunakan git add -A). Untuk melakukan ini, buat fail .gitignore dan tambahkan semua yang diterangkan sebelum ini:

Sekarang mari kita gunakan komit untuk menambah fail .gitignore pada projek:

Dan kini detik kebenaran: kami mempunyai kelas terkumpul GitTest.class yang "tidak dijejaki", yang kami tidak mahu tambahkan pada repositori Git.

Sekarang kita harus melihat kesan fail .giignore:

Sempurna! .giignore +1 :)

Bekerja dengan cawangan

Sememangnya, bekerja di satu cawangan sahaja menyusahkan pembangun bersendirian, dan adalah mustahil apabila terdapat lebih daripada seorang dalam satu pasukan. Itulah sebabnya kami mempunyai cawangan.

Cawangan hanyalah penunjuk alih untuk melakukan.

Dalam bahagian ini, kita akan meneroka bekerja di cawangan yang berbeza: cara menggabungkan perubahan dari satu cawangan ke cawangan lain, konflik yang mungkin timbul dan banyak lagi.

Untuk melihat senarai semua cawangan dalam repositori dan memahami yang mana anda berada, anda perlu menulis:

Anda boleh lihat bahawa kami hanya mempunyai satu cawangan induk. Asterisk di hadapannya menunjukkan bahawa kita berada di dalamnya. Dengan cara ini, anda juga boleh menggunakan arahan "status git" untuk mengetahui cawangan mana kami berada.

Kemudian terdapat beberapa pilihan untuk membuat cawangan (mungkin terdapat lebih banyak — ini adalah yang saya gunakan):

• buat cawangan baharu berdasarkan cawangan kami (99% daripada kes)
• buat cawangan berdasarkan komitmen tertentu (1% daripada kes)

Mari buat cawangan berdasarkan komitmen tertentu

Kami akan bergantung pada pengecam unik komit. Untuk mencarinya, kami menulis:

Kami telah menyerlahkan komitmen dengan ulasan "menambah hello world..." Pengecam uniknya ialah 6c44e53d06228f888f2f454d3cb8c1c976dd73f8. Kami ingin mencipta cawangan "pembangunan" yang bermula dari komit ini. Untuk melakukan ini, kami menulis:

Cawangan dibuat dengan hanya dua komit pertama daripada cawangan induk. Untuk mengesahkan perkara ini, kami mula-mula pastikan untuk beralih ke cawangan lain dan melihat bilangan komit di sana:

Dan seperti yang dijangkakan, kami mempunyai dua komitmen. Ngomong-ngomong, inilah perkara yang menarik: belum ada fail .gitignore dalam cawangan ini, jadi fail yang disusun kami (GitTest.class) kini diserlahkan dengan status "tidak dijejaki".

Kini kami boleh menyemak semula cawangan kami dengan menulis ini:

Anda boleh melihat bahawa terdapat dua cabang: "tuan" dan "pembangunan". Kami sedang dalam pembangunan.

Mari buat cawangan berdasarkan cawangan semasa

Cara kedua untuk mencipta cawangan ialah menciptanya daripada yang lain. Kami ingin membuat cawangan berdasarkan cawangan induk. Pertama, kita perlu beralih kepadanya, dan langkah seterusnya ialah mencipta yang baharu. Mari kita lihat:

• git checkout master - tukar ke cawangan induk
• git status — sahkan bahawa kami sebenarnya berada di cawangan induk

Di sini anda boleh melihat bahawa kami telah bertukar kepada cawangan induk, fail .gitignore berkuat kuasa dan kelas yang disusun tidak lagi diserlahkan sebagai "tidak dijejaki".

Sekarang kami membuat cawangan baharu berdasarkan cawangan induk:

Jika anda tidak pasti sama ada cawangan ini sama dengan "master", anda boleh menyemak dengan mudah dengan melaksanakan "git log" dan melihat semua komit. Patutlah ada empat daripadanya.

Penyelesaian konflik

Sebelum kita meneroka apa itu konflik, kita perlu bercakap tentang menggabungkan satu cabang kepada yang lain.

Gambar ini menggambarkan proses penggabungan satu cabang kepada yang lain:

Di sini, kami mempunyai cawangan utama. Pada satu ketika, cawangan sekunder dicipta daripada cawangan utama dan kemudian diubah suai. Setelah kerja selesai, kita perlu menggabungkan satu cabang ke yang lain.

Dalam contoh kami, kami mencipta cawangan feature/update-txt-files. Seperti yang ditunjukkan oleh nama cawangan, kami sedang mengemas kini teks.

Sekarang kita perlu membuat komitmen baharu untuk kerja ini:

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

Akibatnya, cawangan induk kini juga termasuk komit yang telah ditambahkan pada feature/update-txt-files.

Fungsi ini telah ditambahkan, supaya anda boleh memadamkan cawangan ciri. Untuk melakukan ini, kami menulis:

Mari kita rumitkan keadaan: sekarang katakan bahawa anda perlu menukar fail txt sekali lagi. Tetapi kini fail ini akan ditukar dalam cawangan induk juga. Dengan kata lain, ia akan berubah secara selari. Git tidak akan dapat memikirkan apa yang perlu dilakukan apabila kami ingin menggabungkan kod baharu kami ke dalam cawangan induk.

Kami akan membuat cawangan baharu berdasarkan induk, membuat perubahan pada text_resource.txt dan membuat komitmen untuk kerja ini:

... kami membuat perubahan pada fail

Pergi ke cawangan induk dan juga kemas kini fail teks ini pada baris yang sama seperti dalam cawangan ciri:

… kami mengemas kini test_resource.txt

Dan sekarang perkara yang paling menarik: kita perlu menggabungkan perubahan daripada cawangan ciri/tambah-kepala kepada menguasai. Kami berada di cawangan induk, jadi kami hanya perlu menulis:

Tetapi hasilnya akan menjadi konflik dalam fail test_resource.txt:

Di sini kita dapat melihat bahawa Git tidak boleh memutuskan sendiri bagaimana untuk menggabungkan kod ini. Ia memberitahu kita bahawa kita perlu menyelesaikan konflik terlebih dahulu, dan kemudian melaksanakan komitmen.

OKEY. Kami membuka fail dengan konflik dalam editor teks dan melihat:

Untuk memahami apa yang Git lakukan di sini, kita perlu ingat perubahan yang kita buat dan di mana, dan kemudian bandingkan:

1. Perubahan yang terdapat pada baris ini dalam cawangan induk ditemui di antara "<<<<<<<< HEAD" dan "=======".
2. Perubahan yang terdapat dalam cawangan ciri/tambah-pengepala ditemui antara "=======" dan ">>>>>>> ciri/pengepala tambah".

Beginilah cara Git memberitahu kami bahawa ia tidak dapat mengetahui cara melaksanakan gabungan di lokasi ini dalam fail. Ia membahagikan bahagian ini kepada dua bahagian daripada cawangan yang berbeza dan menjemput kami untuk menyelesaikan konflik gabungan itu sendiri.

Cukup adil. Saya dengan berani memutuskan untuk mengalih keluar segala-galanya, hanya meninggalkan perkataan "header":

Mari kita lihat status perubahan. Penerangan akan berbeza sedikit. Daripada status "diubah suai", kami telah "tidak digabungkan". Jadi bolehkah kita menyebut status kelima? Saya rasa ini tidak perlu. Mari lihat:

Kita boleh meyakinkan diri kita bahawa ini adalah kes yang istimewa dan luar biasa. Jom sambung:

Anda mungkin perasan bahawa huraian mencadangkan menulis "git commit" sahaja. Mari cuba menulis itu:

Dan seperti itu, kami melakukannya - kami menyelesaikan konflik dalam konsol.

Sudah tentu, ini boleh dilakukan dengan lebih mudah dalam persekitaran pembangunan bersepadu. Contohnya, dalam IntelliJ IDEA, segala-galanya disediakan dengan baik sehingga anda boleh melakukan semua tindakan yang diperlukan terus di dalamnya. Tetapi IDE melakukan banyak perkara "di bawah hud", dan kita sering tidak faham apa sebenarnya yang berlaku di sana. Dan apabila tiada persefahaman, masalah boleh timbul.

Bekerja dengan repositori jauh

Langkah terakhir ialah memikirkan beberapa lagi arahan yang diperlukan untuk berfungsi dengan repositori jauh.

Seperti yang saya katakan, repositori jauh adalah tempat di mana repositori disimpan dan dari mana anda boleh mengklonkannya.

Apakah jenis repositori jauh yang ada? Contoh:

• GitHub ialah platform storan terbesar untuk repositori dan pembangunan kolaboratif.
• GitLab ialah alat berasaskan web untuk kitaran hayat DevOps dengan sumber terbuka. Ia adalah sistem berasaskan Git untuk mengurus repositori kod dengan wikinya sendiri, sistem penjejakan pepijat, saluran paip CI/CD dan fungsi lain.
• BitBucket ialah perkhidmatan web untuk pengehosan projek dan pembangunan kolaboratif berdasarkan sistem kawalan versi Mercurial dan Git. Pada satu masa ia mempunyai kelebihan besar berbanding GitHub kerana ia menawarkan repositori peribadi percuma. Tahun lepas, GitHub turut memperkenalkan keupayaan ini kepada semua orang secara percuma.
• Dan sebagainya…

Apabila bekerja dengan repositori jauh, perkara pertama yang perlu dilakukan ialah mengklon projek ke repositori tempatan anda.

Untuk ini, kami mengeksport projek yang kami buat secara tempatan Kini semua orang boleh mengklonkannya untuk diri mereka sendiri dengan menulis:

Kini terdapat salinan tempatan lengkap projek itu. Untuk memastikan bahawa salinan tempatan projek adalah yang terkini, anda perlu menarik projek dengan menulis:

Dalam kes kami, tiada apa-apa dalam repositori jauh telah berubah pada masa ini, jadi jawapannya ialah: Sudah dikemas kini.

Tetapi jika kami membuat sebarang perubahan pada repositori jauh, yang tempatan dikemas kini selepas kami menariknya.

Dan akhirnya, arahan terakhir adalah untuk menolak data ke repositori jauh. Apabila kita telah melakukan sesuatu secara tempatan dan ingin menghantarnya ke repositori jauh, kita mesti membuat komit baharu secara setempat dahulu. Untuk menunjukkan ini, mari tambah sesuatu yang lain pada fail teks kami:

Sekarang sesuatu yang agak biasa bagi kami — kami membuat komitmen untuk kerja ini:

Perintah untuk menolak ini ke repositori jauh ialah:

Itu sahaja buat masa ini!

2. Bagaimana untuk bekerja dengan Git dalam IntelliJ IDEA

Dalam bahagian ini, anda akan belajar cara bekerja dengan Git dalam IntelliJ IDEA.

Input yang diperlukan:

1. Baca, ikuti, dan fahami bahagian sebelumnya. Ini akan membantu memastikan segala-galanya disediakan dan sedia untuk digunakan.
2. Pasang IntelliJ IDEA. Semuanya harus teratur di sini :)
3. Peruntukkan satu jam untuk mencapai penguasaan sepenuhnya.

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

Mengklon projek secara tempatan

Terdapat dua pilihan di sini:

1. Jika anda sudah mempunyai akaun GitHub dan ingin meneruskan sesuatu kemudian, lebih baik anda membatalkan projek itu dan mengklon salinan anda sendiri. Anda boleh membaca tentang cara membuat garpu dalam artikel lain di bawah tajuk Contoh aliran kerja garpu .
2. Klon repositori dan lakukan semuanya secara tempatan tanpa keupayaan untuk menolak semuanya ke pelayan.

Untuk mengklon projek daripada GitHub, anda perlu menyalin pautan projek dan menghantarnya ke IntelliJ IDEA:

1. Salin alamat projek:

2. Buka IntelliJ IDEA dan pilih "Dapatkan daripada Kawalan Versi":

3. Salin dan tampal alamat projek:

4. Anda akan digesa untuk mencipta projek IntelliJ IDEA. Terima tawaran:

5. Oleh kerana tiada sistem binaan, kami memilih "Buat projek daripada sumber sedia ada":

6. Seterusnya anda akan melihat skrin yang cantik ini:

Sekarang setelah kami mengetahui pengklonan, anda boleh melihat sekeliling.

Pandangan pertama pada IntelliJ IDEA sebagai UI Git

Lihat lebih dekat projek klon: anda sudah boleh mendapatkan banyak maklumat tentang sistem kawalan versi.

Pertama, kami mempunyai anak tetingkap Kawalan Versi di sudut kiri bawah. Di sini anda boleh menemui semua perubahan setempat dan mendapatkan senarai komit (bersamaan dengan "git log").

Mari kita beralih kepada perbincangan Log. Terdapat visualisasi tertentu yang membantu kita memahami dengan tepat bagaimana pembangunan telah berjalan. Sebagai contoh, anda boleh melihat bahawa cawangan baharu telah dibuat dengan pengepala tambahan kepada komit txt, yang kemudiannya digabungkan ke dalam cawangan induk. Jika anda mengklik pada komit, anda boleh melihat di penjuru kanan semua maklumat tentang komit: semua perubahan dan metadatanya.

Selain itu, anda boleh melihat perubahan sebenar. Kami juga melihat bahawa konflik telah diselesaikan di sana. IDEA juga membentangkan ini dengan baik.

Jika anda mengklik dua kali pada fail yang telah diubah semasa komit ini, kami akan melihat cara konflik diselesaikan:

Kami ambil perhatian bahawa di sebelah kiri dan kanan kami mempunyai dua versi fail yang sama yang perlu digabungkan menjadi satu. Dan di bahagian tengah, kami mempunyai keputusan gabungan terakhir.

Apabila projek mempunyai banyak cawangan, komitmen dan pengguna, anda perlu mencari secara berasingan mengikut cawangan, pengguna dan tarikh:

Sebelum bermula, ia juga berbaloi untuk menerangkan cara memahami cabang mana kita berada.

Di sudut kanan bawah, terdapat butang berlabel "Git: master". Apa sahaja yang mengikuti "Git:" ialah cawangan semasa. Jika anda mengklik butang, anda boleh melakukan banyak perkara yang berguna: beralih ke cawangan lain, buat yang baharu, menamakan semula yang sedia ada dan seterusnya.

Bekerja dengan repositori

Kekunci panas yang berguna

Untuk kerja masa hadapan, anda perlu mengingati beberapa kekunci pintas yang sangat berguna:

1. CTRL+T — Dapatkan perubahan terkini daripada repositori jauh (git pull).
2. CTRL+K — Buat komit / lihat semua perubahan semasa. Ini termasuk kedua-dua fail yang tidak dijejaki dan diubah suai (git commit).
3. CTRL+SHIFT+K — Ini ialah arahan untuk menolak perubahan pada repositori jauh. Semua komit yang dibuat secara tempatan dan belum dalam repositori jauh akan ditolak (git push).
4. ALT+CTRL+Z — Tukar balik dalam fail tertentu kepada keadaan komit terakhir yang dibuat dalam repositori tempatan. Jika anda memilih keseluruhan projek di penjuru kiri sebelah atas, anda boleh melancarkan semula perubahan dalam semua fail.

Apa yang kita mahu?

Untuk menyelesaikan kerja, kita perlu menguasai senario asas yang digunakan di mana-mana.

Objektifnya adalah untuk melaksanakan fungsi baharu dalam cawangan berasingan dan kemudian menolaknya ke repositori jauh (maka anda juga perlu membuat permintaan tarik ke cawangan utama, tetapi itu di luar skop pelajaran ini).

Apa yang diperlukan untuk melakukan ini?

1. Dapatkan semua perubahan semasa dalam cawangan utama (contohnya, "tuan").

2. Daripada cawangan utama ini, buat cawangan berasingan untuk kerja anda.

3. Laksanakan fungsi baharu.

4. Pergi ke cawangan utama dan semak sama ada terdapat sebarang perubahan baharu semasa kami bekerja. Jika tidak, maka semuanya baik-baik saja. Tetapi jika terdapat perubahan, maka kami melakukan perkara berikut: pergi ke cawangan kerja dan asas semula perubahan daripada cawangan utama kepada kami. Jika semuanya berjalan lancar, maka hebat. Tetapi kemungkinan besar akan ada konflik. Seperti yang berlaku, mereka hanya boleh diselesaikan terlebih dahulu, tanpa membuang masa di repositori jauh.

   Adakah anda tertanya-tanya mengapa anda perlu melakukan ini? Ia adalah adab yang baik dan menghalang konflik daripada berlaku selepas menolak cawangan anda ke repositori tempatan (sudah tentu, terdapat kemungkinan konflik masih akan berlaku, tetapi ia menjadi lebih kecil ).

5. Tolak perubahan anda ke repositori jauh.

Bagaimana untuk mendapatkan perubahan daripada pelayan jauh?

Kami menambahkan perihalan pada README dengan komitmen baharu dan ingin mendapatkan perubahan ini. Jika perubahan dibuat dalam repositori tempatan dan dalam repositori terpencil, maka kami dijemput untuk memilih antara gabungan dan pangkalan semula. Kami memilih untuk bergabung.

Masukkan CTRL+T :

Anda kini boleh melihat bagaimana README telah berubah, iaitu perubahan dari repositori jauh ditarik masuk, dan di sudut kanan bawah anda boleh melihat semua butiran perubahan yang datang dari pelayan.

Buat cawangan baharu berdasarkan master

Semuanya mudah di sini.

Pergi ke penjuru kanan sebelah bawah dan klik Git: master . Pilih + Cawangan Baharu .

Biarkan kotak semak cawangan Checkout dipilih dan masukkan nama cawangan baharu. Dalam kes kami: ini akan menjadi readme-improver .

Git: master kemudiannya akan bertukar kepada Git: readme-improver .

Mari kita simulasi kerja selari

Untuk konflik muncul, seseorang perlu menciptanya.

Kami akan mengedit README dengan komit baharu melalui penyemak imbas, dengan itu mensimulasikan kerja selari. Seolah-olah seseorang membuat perubahan dalam fail yang sama semasa kami sedang mengusahakannya. Akibatnya akan menjadi konflik. Kami akan mengalih keluar perkataan "fully" daripada baris 10.

Laksanakan fungsi kami

Tugas kami ialah menukar README dan menambah penerangan pada artikel baharu. Iaitu, kerja dalam Git melalui IntelliJ IDEA. Tambah ini:

Perubahan telah dilakukan. Sekarang kita boleh membuat komitmen. Tekan CTRL+K , yang memberi kita:

Sebelum membuat komitmen, kita perlu melihat dengan teliti apa yang ditawarkan oleh tetingkap ini.

Dalam bahagian Mesej Komit , kami menulis teks yang dikaitkan dengan komit. Kemudian untuk menciptanya, kita perlu mengklik Commit .

Kami menulis bahawa README telah berubah dan mencipta komit. Makluman muncul di sudut kiri bawah dengan nama komit:

Semak sama ada cawangan utama telah berubah

Kami menyelesaikan tugas kami. Ianya berfungsi. Kami menulis ujian. Semuanya baik-baik sahaja. Tetapi sebelum menolak ke pelayan, kami masih perlu menyemak sama ada terdapat sebarang perubahan dalam cawangan utama dalam masa yang sama. Bagaimana itu boleh berlaku? Agak mudah: seseorang menerima tugasan selepas anda, dan seseorang itu menyelesaikannya lebih cepat daripada anda menyelesaikan tugasan anda.

Jadi kita perlu pergi ke cawangan induk. Untuk melakukan ini, kita perlu melakukan apa yang ditunjukkan di sudut kanan bawah dalam tangkapan skrin di bawah:

Dalam cawangan induk, tekan CTRL+T untuk mendapatkan perubahan terkini daripada pelayan jauh. Melihat apa perubahan, anda boleh melihat dengan mudah apa yang berlaku:

Perkataan "fully" telah dialih keluar. Mungkin seseorang dari pemasaran memutuskan bahawa ia tidak sepatutnya ditulis seperti itu dan memberi pemaju tugas untuk mengemas kininya.

Kami kini mempunyai salinan tempatan versi terkini cawangan induk. Kembali ke readme-improver .

Sekarang kita perlu membuat asas semula perubahan daripada cawangan induk kepada kita. Kami melakukan ini:

Jika anda melakukan semuanya dengan betul dan mengikut saya, hasilnya akan menunjukkan konflik dalam fail README:

Di sini kami juga mempunyai banyak maklumat untuk difahami dan diserap. Ditunjukkan di sini ialah senarai fail (dalam kes kami, satu fail) yang mempunyai konflik. Kita boleh memilih daripada tiga pilihan:

1. terima milik anda — terima hanya perubahan daripada readme-improver.
2. terima mereka — terima hanya perubahan daripada tuan.
3. cantumkan — pilih sendiri apa yang anda mahu simpan dan apa yang perlu dibuang.

Tidak jelas apa yang berubah. Sekiranya terdapat perubahan adalah cawangan induk, ia mesti diperlukan di sana, jadi kita tidak boleh menerima perubahan kita begitu sahaja. Sehubungan itu, kami memilih gabungan :

Di sini kita dapat melihat bahawa terdapat tiga bahagian:

1. Ini adalah perubahan daripada readme-improver.
2. Hasil gabungan. Buat masa ini, ia adalah apa yang wujud sebelum perubahan.
3. Perubahan daripada cawangan induk.

Kami perlu menghasilkan hasil gabungan yang akan memuaskan hati semua orang. Menyemak perkara yang telah diubah SEBELUM perubahan kami, kami menyedari bahawa ia hanya mengalih keluar perkataan "fully". Okay, tiada masalah! Ini bermakna kami juga akan mengalih keluarnya dalam hasil gabungan dan kemudian menambah perubahan kami. Setelah kami membetulkan hasil gabungan, kami boleh mengklik Guna .

Kemudian pemberitahuan akan muncul, memberitahu kami bahawa pangkalan semula telah berjaya:

sana! Kami menyelesaikan konflik pertama kami melalui IntelliJ IDEA.

Tolak perubahan pada pelayan jauh

Langkah seterusnya ialah menolak perubahan pada pelayan jauh dan membuat permintaan tarik. Untuk melakukan ini, hanya tekan CTRL+SHIFT+K . Kemudian kita dapat:

Di sebelah kiri, akan terdapat senarai komit yang belum ditolak ke repositori jauh. Di sebelah kanan akan terdapat semua fail yang telah berubah. Dan itu sahaja! Tekan Push dan anda akan mengalami kebahagiaan :)

Jika tolakan berjaya, anda akan melihat pemberitahuan seperti ini di penjuru kanan sebelah bawah:

Bonus: mencipta permintaan tarik

Mari pergi ke repositori GitHub dan kami melihat bahawa GitHub sudah tahu apa yang kami mahukan:

Klik Bandingkan & tarik permintaan . Kemudian klik Buat permintaan tarik . Oleh kerana kami telah menyelesaikan konflik terlebih dahulu, kini apabila membuat permintaan tarik, kami boleh menggabungkannya dengan segera:

Itu sahaja buat masa ini!