Siin on kõik Giti käsud, mida ma eelmisel nädalal kasutasin, ja mida nad teevad.

Nagu enamik algajaid, alustasin StackOverflow'st Git-käskude otsimist ja seejärel vastuste kopeerimist-kleepimist, saamata tegelikult aru, mida nad tegid.

Ma mäletan, et mõtlesin,"Kas poleks tore, kui oleks olemas nimekiri kõige tavalisematest Git-käskudest koos selgitusega, miks need on kasulikud?"

Noh, siin olen aastaid hiljem, et koostada selline nimekiri ja koostada mõned parimad tavad, mida isegi kesktasemel edasijõudnud arendajad peaksid kasulikuks pidama.

Asjade praktilisuse huvides võtan selle loendi välja tegelikest Giti käskudest, mida ma eelmisel nädalal kasutasin.

Peaaegu iga arendaja kasutab Giti ja tõenäoliselt ka GitHubi. Kuid keskmine arendaja kasutab neid kolme käsku tõenäoliselt ainult 99% ajast:

git add --allgit commit -am ""git push origin master

See on kõik hästi ja hästi, kui töötate ühe inimese meeskonnas, häkatonil või viskamisrakenduses, kuid kui stabiilsus ja hooldus hakkavad saama esmatähtsaks, on koristamine kohustus, hargnemiseni strateegiast kinnipidamine ja kirjutamine oluliseks saavad sidusad pühendumissõnumid.

Alustan tavaliselt kasutatavate käskude loendiga, et algajatel oleks hõlpsam mõista, mis on Gitiga võimalik, seejärel liigun täpsemate funktsioonide ja parimate tavade juurde.

Regulaarselt kasutatavad käsud

Giti initsialiseerimiseks hoidlas (repo) peate lihtsalt tippima järgmise käsu. Kui te Gitit ei initsialiseeri, ei saa te selles repos käivitada muid Giti käske.

git init

Kui te kasutate GitHub ja sa surudes koodi oma GitHub repo, mis on salvestatud online, te kasutate kaugjuhtimispuldi repo. Selle kaugrepo vaikenimi (tuntud ka kui varjunimi) on päritolu . Kui olete projekti Githubist kopeerinud, on sellel juba päritolu . Seda päritolu saate vaadata käsuga git remote -v , mis loetleb kaughoidla URL-i.

Kui algatasite oma Giti repo ja soovite seostada seda GitHubi repoga, peate selle GitHubis looma, kopeerima pakutava URL-i ja kasutama käsku git remote add origin RL>, kusjuures GitHubi pakutav URL asendab “”. Sealt saate lisada, siduda ja edastada oma kaughoidlat.

Viimast kasutatakse siis, kui peate kaughoidlat muutma. Oletame, et kopeerisite kellegi teise repo ja soovite muuta kaughoidla algse omaniku oma enda GitHubi kontole. Järgige sama protsessi nagu git-i kaug-algallika lisamine , välja arvatud kaug-repo muutmiseks kasutage selle asemel set-url-i .

git remote -vgit remote add origin git remote set-url origin 

Repo kopeerimiseks on kõige tavalisem kasutada git klooni, millele järgneb repo URL.

Pidage meeles, et kaughoidla lingitakse kontoga, kust te repo kloonisite. Nii et kui kloonisite kellelegi teisele kuuluva repo, ei saa te GitHubi minna enne, kui muudate ülaltoodud käskude abil päritolu .

git clone 

Leiate ennast kiiresti harude kasutamisest. Kui te ei saa aru, mis harud on, on ka teisi õpetusi, mis on palju põhjalikumad ja enne jätkamist peaksite need läbi lugema (siin on üks).

Käsk git branch loetleb kõik teie kohaliku masina harud. Kui soovite luua uue haru, võite kasutada git-haru mina>, kus & lt; name> tähistab filiaali nime, näiteks “kapten”.

Git kassasse me> käsk lülitub olemasolevale harule. Uue haru loomiseks ja sellele kohe vahetamiseks võite kasutada ka käsku git checkout -b & lt; name>. Enamik inimesi kasutab seda eraldi filiaali- ja kassakäskude asemel.

git branchgit branch git checkout git checkout -b 

Kui olete teinud hunnik muudatusi filiaali, olgem kutsuvad seda "arendada", ja te soovite ühendada, et filiaali tagasi oma master filiaal, siis kasutage git ühendamise

ch> käsk. Peate kontrollima peaharu, n run git ühendama d evelop ühendama arenema põhiharu.

git merge 

Kui töötate mitme inimesega, leiate end olukorrast, kus repot värskendati GitHubis, kuid teil pole muudatusi lokaalselt. Sel juhul saate kasutada git pull originaali

ch>, et tõmmata viimased muudatused sellest kaughargist.

git pull origin 

Kui soovite teada, milliseid faile on muudetud ja mida jälgitakse, saate kasutada git-olekut . Kui soovite näha, kui palju iga faili on muudetud, saate kasutada faili git diff, et näha igas failis muudetud ridade arvu.

git statusgit diff --stat

Täpsemad käsud ja parimad tavad

Varsti jõuate punkti, kus soovite, et teie kohustused näeksid kena välja ja püsiksid järjekindlad. Samuti peate võib-olla oma pühendumiste ajalooga ringi käima, et muuta teie kohustused hõlpsamalt mõistetavaks või tühistada juhuslik murranguline muutus.

Git log käsk võimaldab teil näha toime ajalugu. Seda soovite kasutada oma kohustuste ajaloo nägemiseks.

Teie kohustused tulevad sõnumite ja räsi abil , mis on juhuslik arvude ja tähtede jada. Räsi näide võib välja näha järgmine: c3d882aa1aa4e3d5f18b3890132670fbeac912f7

git log

Oletame, et lükkasite midagi, mis rikkus teie rakendust. Selle asemel, et seda parandada ja midagi uut suruda, pöördute pigem ühe kohustuse juurde tagasi ja proovige uuesti.

Kui sa tahad minna ajas tagasi ja kassasse oma rakenduse eelmisest toime, saate seda teha otse, kasutades hash kui filiaali nimi. See lahutab teie rakenduse praegusest versioonist (kuna muudate ajaloolist kirjet, mitte praegust versiooni).

git checkout c3d88eaa1aa4e4d5f

Siis, kui teete selles ajaloolises harus muudatusi ja soovite uuesti tõugata, peate tegema jõu tõuke.

Ettevaatust: sundige surumaon ohtlik ja seda tuleks teha ainult siis, kui peate seda kindlasti tegema. See kirjutab teie rakenduse ajaloo üle ja kaotate kõik, mis pärast tuli.

git push -f origin master

Teinekord pole lihtsalt otstarbekas kõike ühes kohustuses hoida. Võib-olla soovite salvestada oma edusammud, enne kui proovite midagi potentsiaalselt riskantset, või tegite vea ja tahate endale säästa piinlikkust, et teie versiooniajalugu sisaldab viga. Selleks on meil git ümberpaigutamine .

Oletame, et teie kohalikus ajaloos on 4 toimingut (mida pole GitHubi lükatud), milles olete edasi-tagasi liikunud. Teie kohustused näivad lohakad ja otsustusvõimetud. Rebase'i abil saate ühendada kõik need toimingud ühtseks, lühikeseks kohustuseks.

git rebase -i HEAD~4

The above command will open up your computer’s default editor (which is Vim unless you’ve set it to something else), with several options for how you can change your commits. It will look something like the code below:

pick 130deo9 oldest commit messagepick 4209fei second oldest commit messagepick 4390gne third oldest commit messagepick bmo0dne newest commit message

In order to combine these, we need to change the “pick” option to “fixup” (as the documentation below the code says) to meld the commits and discard the commit messages. Note that in vim, you need to press “a” or “i” to be able to edit the text, and to save and exit, you need to type the escape key followed by “shift + z + z”. Don’t ask me why, it just is.

pick 130deo9 oldest commit messagefixup 4209fei second oldest commit messagefixup 4390gne third oldest commit messagefixup bmo0dne newest commit message

This will merge all of your commits into the commit with the message “oldest commit message”.

The next step is to rename your commit message. This is entirely a matter of opinion, but so long as you follow a consistent pattern, anything you do is fine. I recommend using the commit guidelines put out by Google for Angular.js.

In order to change the commit message, use the amend flag.

git commit --amend

This will also open vim, and the text editing and saving rules are the same as above. To give an example of a good commit message, here’s one following the rules from the guideline:

feat: add stripe checkout button to payments page
- add stripe checkout button- write tests for checkout

One advantage to keeping with the types listed in the guideline is that it makes writing change logs easier. You can also include information in the footer (again, specified in the guideline) that references issues.

Note: you should avoid rebasing and squashing your commits if you are collaborating on a project, and have code pushed to GitHub. If you start changing version history under people’s noses, you could end up making everyone’s lives more difficult with bugs that are difficult to track.

There are an almost endless number of possible commands with Git, but these commands are probably the only ones you’ll need to know for your first few years of programming.

Sam Corcos is the lead developer and co-founder of Sightline Maps, the most intuitive platform for 3D printing topographical maps, as well as LearnPhoenix.io, an intermediate-advanced tutorial site for building scalable production apps with Phoenix and React.