Tässä ovat kaikki Git-komennot, joita käytin viime viikolla, ja mitä he tekevät.

Kuten useimmat aloittelijat, aloin etsiä StackOverflow-ohjelmasta Git-komentoja, sitten kopioida-liittää vastauksia ymmärtämättä todella mitä he tekivät.

Muistan ajatella,"Eikö olisi hienoa, jos siellä olisi luettelo yleisimmistä Git-komennoista ja selitys miksi ne ovat hyödyllisiä?"

No, täällä olen vuosia myöhemmin laatia tällainen luettelo ja laatia joitain parhaita käytäntöjä, jotka jopa keskitason edistyneiden kehittäjien pitäisi olla hyödyllisiä.

Jotta asiat olisivat käytännöllisiä, perustan tämän luettelon todellisista Git-komennoista, joita käytin viime viikolla.

Lähes jokainen kehittäjä käyttää Gitiä ja todennäköisesti GitHubia. Mutta keskimääräinen kehittäjä käyttää todennäköisesti vain näitä kolmea komentoa 99% ajasta:

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

Se on kaikki hyvin, kun työskentelet yhden hengen tiimissä, hakkeroinnissa tai heitettävässä sovelluksessa, mutta kun vakaudesta ja ylläpidosta tulee etusijalla, siivoaminen, sitoutuminen haarautumisstrategiaan ja kirjoittaminen johdonmukaiset sitoutumisviestit tulevat tärkeiksi.

Aloitan yleisesti käytettyjen komentojen luettelosta, jotta aloittelijoille on helpompi ymmärtää, mikä on mahdollista Gitillä, ja siirry sitten edistyneempiin toimintoihin ja parhaisiin käytäntöihin.

Säännöllisesti käytetyt komennot

Jos haluat alustaa Gitin arkistossa (repo), sinun tarvitsee vain kirjoittaa seuraava komento. Jos et alusta Git-ohjelmaa, et voi suorittaa muita Git-komentoja tuossa repossa.

git init

Jos käytät GitHub ja olet työntämällä koodin GitHub repo joka on tallennettu verkossa, käytät kauko repo. Tämän etärepon oletusnimi (tunnetaan myös nimellä aliaksena) on alkuperä . Jos olet kopioinut projektin Githubista, sillä on jo alkuperä . Voit tarkastella kyseistä alkuperää komennolla git remote -v , joka listaa etärepon URL-osoitteen.

Jos olet alustanut oman Git-reposi ja haluat liittää sen GitHub-repoon, sinun on luotava yksi GitHubiin, kopioitava annettu URL-osoite ja käytettävä komentoa git remote add origin RL>, GitHubin toimittama URL korvaa “”. Sieltä voit lisätä, sitoutua ja lähettää etärepoosi.

Viimeistä käytetään, kun sinun on vaihdettava etätietovarasto. Oletetaan, että kopioit jonkun muun repon ja haluat vaihtaa etätallennustilan alkuperäiseltä omistajalta omalle GitHub-tilillesi. Noudata samaa prosessia kuin git-etälisäalku , paitsi käytä set-url -vaihtoehtoa sen sijaan, että vaihdat kauko-ohjausta.

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

Yleisin tapa kopioida repo on käyttää git-kloonia, jota seuraa repon URL-osoite.

Muista, että etätietovarasto linkitetään tiliin, josta kloonoit repon. Joten jos kloonasit toiselle kuuluvan repon, et voi siirtyä GitHubiin, ennen kuin muutat alkuperää yllä olevilla komennoilla.

git clone 

Löydät itsesi nopeasti haaroista. Jos et ymmärrä, mitä haarat ovat, on muita oppaita, jotka ovat paljon syvällisempiä, ja sinun tulisi lukea ne ennen jatkamista (tässä on yksi).

Komento git -haara listaa kaikki paikallisen koneesi haarat. Jos haluat luoda uuden haaran, voit käyttää git-haaraa minä>, jossa & lt; name> edustaa haaratoimiston nimeä, kuten "päällikkö".

Git kassalle me> -komento vaihtaa olemassa olevaan haaraan. Voit myös antaa meille git checkout -b & lt; name> -komennon uuden haaran luomiseksi ja siirtymiseksi siihen välittömästi. Useimmat ihmiset käyttävät tätä erillisten haara- ja kassakomentojen sijaan.

git branchgit branch git checkout git checkout -b 

Jos olet tehnyt joukko muutoksia sivuliikkeen, kutsutaan sitä ”kehittää”, ja haluat yhdistää, että haara takaisin oman master haara, käytät git yhdistämisen

ch> -komento. Sinun wa nt ch eckout master sivuliike, n run git yhdistämisen d evelop sulautua kehittyä master haara.

git merge 

Jos työskentelet useiden ihmisten kanssa, löydät itsesi tilanteesta, jossa repo päivitettiin GitHubissa, mutta sinulla ei ole muutoksia paikallisesti. Jos näin on, voit käyttää git pull-alkuperää

ch> vetääksesi tuoreimmat sivuhaaran muutokset.

git pull origin 

Jos haluat nähdä, mitä tiedostoja on muutettu ja mitä seurataan, voit käyttää git-tilaa . Jos haluat nähdä, kuinka paljon kutakin tiedostoa on muutettu, voit käyttää git diff -toimintoa nähdäksesi jokaisessa tiedostossa muutettujen rivien määrän.

git statusgit diff --stat

Edistyneet komennot ja parhaat käytännöt

Pian pääset pisteeseen, jossa haluat sitoutumiesi näyttävän hyvältä ja pysyvän johdonmukaisina. Saatat joutua myös hämäämään sitoutumishistoriasi kanssa, jotta tekosi olisi helpompi ymmärtää tai palauttaa vahingossa tapahtuva rikkominen.

Git log -komennolla näet sitoutua historiaa. Haluat käyttää tätä nähdäksesi tekemiesi tapahtumien historian.

Sitoumuksesi mukana tulee viestejä ja hash , joka on satunnainen numero- ja kirjainsarja. Hajautusesimerkki voi näyttää tältä: c3d882aa1aa4e3d5f18b3890132670fbeac912f7

git log

Oletetaan, että työnsit jotain, joka rikkoi sovelluksesi. Sen sijaan, että korjaat sen ja työntät jotain uutta, haluat mieluummin vain palata takaisin yhteen ja yrittää uudelleen.

Jos haluat mennä ajassa taaksepäin ja kassalle sovelluksen aiemman sitoutua, voit tehdä tämän suoraan käyttämällä hash kuin haara nimi. Tämä irrottaa sovelluksesi nykyisestä versiosta (koska muokkaat historiallista tietuetta nykyisen version sijaan).

git checkout c3d88eaa1aa4e4d5f

Sitten, jos teet muutoksia tuohon historialliseen haaraan ja haluat työntää uudelleen, sinun on tehtävä voima.

Varoitus: Pakota työntämistäis dangerous and should only be done if you absolutely must. It will overwrite the history of your app and you will lose whatever came after.

git push -f origin master

Other times it’s just not practical to keep everything in one commit. Perhaps you want to save your progress before trying something potentially risky, or perhaps you made a mistake and want to spare yourself the embarrassment of having an error in your version history. For that, we have git rebase.

Let’s say you have 4 commits in your local history (not pushed to GitHub) in which you’ve gone back and forth. Your commits look sloppy and indecisive. You can use rebase to combine all of those commits into a single, concise commit.

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.