Bermula dengan Git: panduan komprehensif untuk pemula

Daripada perkenalan

hello! Hari ini kita akan bercakap tentang sistem kawalan versi, iaitu Git. Anda tiada kaitan dengan pengaturcaraan jika anda tidak tahu/faham Git. Tetapi keindahannya ialah 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 teragih 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.

Memasang Git

Mari pasang Java pada komputer anda.

Memasang pada Windows

Seperti biasa, anda perlu memuat turun dan menjalankan fail exe. Segala-galanya 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 membuka Git di sana, anda boleh membuka gesaan arahan dalam folder projek dengan butang tetikus kanan 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 Git pada Ubuntu . Saya sedang mengusahakan Ubuntu, jadi saya boleh memberitahu anda apa yang perlu ditulis untuknya: sudo apt-get install git.

Memasang pada macOS

Di sini juga, anda perlu menyemak sama ada Git sudah ada di sana. Jika anda tidak memilikinya, maka cara paling mudah untuk mendapatkannya ialah dengan memuat turun versi terkini di sini . 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:

git config --global user.name "Ivan Ivanov"
git config --global user.email ivan.ivanov@gmail.com

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

git config user.name "Ivan Ivanov"
git config user.email ivan.ivanov@gmail.com

Sedikit teori...

Untuk menyelami topik ini, kami harus memperkenalkan anda kepada beberapa perkataan dan tindakan baharu...

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

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 adalah status yang digunakan pada fail yang mengandungi kod kami:

1. Fail yang dibuat tetapi belum ditambahkan pada repositori mempunyai status "tidak dijejaki".
2. Apabila kami membuat perubahan pada fail yang telah ditambahkan pada repositori Git, maka statusnya "diubah suai".
3. Antara fail yang telah kami ubah, kami memilih fail yang kami perlukan, dan kelas ini ditukar kepada status "berperingkat".
4. 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".

Inilah 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. Lebih khusus: Terdapat komitmen pertama. Apabila komit kedua dibuat, ia tahu apa yang berlaku 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 mula-mula anda harus memikirkan arahan yang sedang dilaksanakan dan maksudnya.

Bekerja dengan Git dalam repositori tempatan

Seterusnya, saya cadangkan anda mengikuti dan melaksanakan semua langkah yang saya lakukan semasa anda membaca artikel tersebut. Ini akan meningkatkan pemahaman dan penguasaan anda terhadap bahan tersebut. Nah, selamat makan! :) Untuk membuat repositori tempatan, anda perlu menulis:

git init

Ini akan mencipta folder .git 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:

git status

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, ini adalah sama seperti yang sebelumnya
• git add <nama fail> — 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:

git add *.txt

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

git status

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:

git commit -m "all txt files were added to the project"

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

git log

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:

git status

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:

git 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:

git diff

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:

git add test_resource.txt
git commit -m "added hello word! to test_resource.txt"

Untuk melihat semua komitmen, tulis:

git log

Seperti yang anda lihat, kami kini mempunyai dua komitmen. Kami akan menambah GitTest.java dengan cara yang sama. Tiada ulasan di sini, hanya arahan:

git add GitTest.java
git commit -m "added GitTest.java"
git status

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:

```
*.class
target/
*.iml
.idea/
```

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:

git status

Jelas sekali, kami tidak mahu menambah kelas yang disusun secara tidak sengaja pada projek (menggunakan git add -A). Untuk melakukan ini, cipta fail .gitignore dan tambahkan semua yang diterangkan sebelum ini: Sekarang mari kita gunakan komit untuk menambah fail .gitignore pada projek:

git add .gitignore
git commit -m "added .gitignore file"

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:

git status

Sempurna! .giignore +1 :)

Bekerja dengan cawangan dan sebagainya

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. Seperti yang saya katakan tadi, cawangan hanyalah penunjuk alih untuk melakukan. Dalam bahagian ini, kita akan meneroka bekerja di cawangan yang berbeza: cara menggabungkan perubahan daripada 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:

git branch -a

Anda boleh lihat bahawa kami hanya mempunyai satu cawangan induk. Asterisk di hadapannya menunjukkan bahawa kita berada di dalamnya. Ngomong-ngomong, anda juga boleh menggunakan arahan "status git" untuk mengetahui cawangan mana kami berada. Kemudian terdapat beberapa pilihan untuk mencipta 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:

git log

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

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

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

git status
git log

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:

git branch -a

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. Saya ingin membuat cawangan berdasarkan cawangan induk. Pertama, saya 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 dapat 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:

git checkout -b feature/update-txt-files

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 cawangan 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. Saya tidak akan menerangkan pelbagai ciri: Dalam artikel ini, saya hanya ingin menyampaikan pemahaman umum. Jika anda memerlukan butiran, anda boleh mencarinya sendiri. 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:

git add *.txt 
git commit -m "updated txt files"
git log

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":

git checkout master
git merge feature/update-txt-files
git log

Akibatnya, cawangan induk kini turut menyertakan komit yang telah ditambahkan pada feature/update-txt-files. Fungsi ini telah ditambahkan, supaya anda boleh memadamkan cawangan ciri. Untuk melakukan ini, kami menulis:

git branch -D feature/update-txt-files

Semuanya jelas setakat ini, ya? 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. Mari pergi! Kami akan membuat cawangan baharu berdasarkan induk, membuat perubahan pada text_resource.txt dan membuat komitmen untuk kerja ini:

git checkout -b feature/add-header
... we make changes to the file

git add *.txt
git commit -m "added header to txt"

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

git checkout master
… we updated test_resource.txt

git add test_resource.txt
git commit -m "added master header to 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:

git merge feature/add-header

Tetapi hasilnya akan menjadi konflik dalam fail test_resource.txt: Di sini kita dapat melihat bahawa Git tidak dapat memutuskan sendiri cara 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 lihat: Untuk memahami apa yang Git lakukan di sini, kami perlu ingat perubahan yang kami 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 di 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 lihat status perubahan. Penerangan akan sedikit berbeza. Daripada status "diubah suai", kami telah "tidak digabungkan". Jadi bolehkah kita menyebut status kelima? Saya rasa ini tidak perlu. Mari lihat:

git status

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

git add *.txt

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

git commit

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. Saya telah menerangkannya dalam artikel sebelum ini.
  Ikuti saya di GitHub . Saya sering mempamerkan kerja saya di sana dalam bidang yang saya belajar untuk bekerja.

• GitLab ialah alat berasaskan web untuk kitaran hayat DevOps dengan sumber terbuka . Ia ialah sistem berasaskan Git untuk mengurus repositori kod dengan wikinya sendiri, sistem penjejakan pepijat , saluran paip CI/CD dan fungsi lain.
  Selepas berita bahawa Microsoft membeli GitHub, beberapa pembangun menduplikasi projek mereka dalam GitLab.

• 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, saya mengeksport projek yang kami buat secara tempatan, dan kini semua orang boleh mengklonkannya untuk diri mereka sendiri dengan menulis:

git clone https://github.com/romankh3/git-demo

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

git pull

Dalam kes kami, tiada apa-apa dalam repositori jauh telah berubah pada masa ini, jadi jawapannya ialah: Sudah dikemas kini. Tetapi jika saya 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 perkara ini, mari tambahkan sesuatu yang lain pada fail teks kami: Sekarang sesuatu yang agak biasa bagi kami — kami membuat komitmen untuk kerja ini:

git add test_resource.txt
git commit -m "prepared txt for pushing"

Perintah untuk menolak ini ke repositori jauh ialah:

git push

Nah, itu sahaja yang saya ingin katakan. Terima kasih atas perhatian anda. Ikuti saya di GitHub , tempat saya menyiarkan pelbagai projek contoh hebat yang berkaitan dengan kajian peribadi dan kerja saya.

Pautan berguna

• Dokumentasi Git rasmi . Saya syorkan sebagai rujukan.