Her er alle de Git-kommandoer, jeg brugte i sidste uge, og hvad de gør.

Som de fleste nybegyndere begyndte jeg at søge StackOverflow efter Git-kommandoer og derefter kopiere og indsætte svar uden virkelig at forstå, hvad de gjorde.

Jeg husker, at jeg tænkte,"Ville det ikke være rart, hvis der var en liste over de mest almindelige Git-kommandoer sammen med en forklaring på, hvorfor de er nyttige?"

Nå, her er jeg år senere til at udarbejde en sådan liste og lægge nogle bedste fremgangsmåder, som selv mellem-avancerede udviklere bør finde nyttige.

For at holde tingene praktiske baserer jeg denne liste ud af de faktiske Git-kommandoer, jeg brugte i løbet af den sidste uge.

Næsten enhver udvikler bruger Git og sandsynligvis GitHub. Men den gennemsnitlige udvikler bruger sandsynligvis kun disse tre kommandoer 99% af tiden:

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

Det er godt og godt, når du arbejder på et team til en person, en hackathon eller en smid-app, men når stabilitet og vedligeholdelse begynder at blive en prioritet, rydder op, holder sig til en forgreningsstrategi og skriver sammenhængende forpligtelsesbudskaber bliver vigtige.

Jeg starter med listen over almindeligt anvendte kommandoer for at gøre det lettere for nybegyndere at forstå, hvad der er muligt med Git, og derefter gå ind i den mere avancerede funktionalitet og bedste praksis.

Regelmæssigt anvendte kommandoer

For at initialisere Git i et lager (repo) skal du bare skrive følgende kommando. Hvis du ikke initialiserer Git, kan du ikke køre andre Git-kommandoer inden for den repo.

git init

Hvis du bruger GitHub, og du skubber kode til en GitHub-repo, der er gemt online, bruger du en ekstern repo. Standardnavnet (også kendt som et alias) for den eksterne repo er oprindelse . Hvis du har kopieret et projekt fra Github, har det allerede en oprindelse . Du kan se denne oprindelse med kommandoen git remote -v , som viser URL'en til den eksterne repo.

Hvis du initialiserede din egen Git-repo og vil knytte den til en GitHub-repo, skal du oprette en på GitHub, kopiere den angivne URL og bruge kommandoen git remote add origin RL>, med URL'en fra GitHub, der erstatter “”. Derfra kan du tilføje, forpligte og skubbe til din eksterne repo.

Den sidste bruges, når du har brug for at ændre det eksterne lager. Lad os sige, at du har kopieret en repo fra en anden og vil ændre det eksterne lager fra den oprindelige ejers til din egen GitHub-konto. Følg den samme proces som git remote add origin , undtagen brug set-url i stedet for at ændre den eksterne repo.

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

Den mest almindelige måde at kopiere en repo på er at bruge git-klon efterfulgt af URL'en til repo.

Husk, at det eksterne lager vil være knyttet til den konto, hvorfra du klonede repoen. Så hvis du klonede en repo, der tilhører en anden, kan du ikke skubbe til GitHub, før du ændrer oprindelsen ved hjælp af ovenstående kommandoer.

git clone 

Du finder hurtigt dig selv ved hjælp af grene. Hvis du ikke forstår, hvad grene er, er der andre selvstudier, der er meget mere dybtgående, og du bør læse dem, før du fortsætter (her er en).

Kommandoen git gren viser alle grene på din lokale maskine. Hvis du vil oprette en ny gren, kan du bruge git-gren mig>, med & lt; navn>, der repræsenterer filialens navn, såsom "master".

Den git kassen mig> kommando skifter til en eksisterende gren. Du kan også bruge kommandoen git checkout -b & lt; name> til at oprette en ny gren og straks skifte til den. De fleste mennesker bruger dette i stedet for separate filial- og check-kommandoer.

git branchgit branch git checkout git checkout -b 

Hvis du har foretaget en masse ændringer til en gren, lad os kalde det "udvikle", og du vil flette den gren tilbage til din masterfilial , du bruger git merge

ch> kommando. Du wa nt at ch eckout master filial, n køre git merge d evelop at fusionere udvikle sig til master gren.

git merge 

Hvis du arbejder med flere personer, finder du dig selv i en position, hvor en repo blev opdateret på GitHub, men du har ikke ændringerne lokalt. Hvis det er tilfældet, kan du bruge git pull-oprindelse

ch> for at trække de seneste ændringer fra den fjerntliggende gren.

git pull origin 

If you’re curious to see what files have been changed and what’s being tracked, you can use git status. If you want to see how much each file has been changed, you can use git diff to see the number of lines changed in each file.

git statusgit diff --stat

Advanced commands and best practices

Soon you reach a point where you want your commits to look nice and stay consistent. You might also have to fiddle around with your commit history to make your commits easier to comprehend or to revert an accidental breaking change.

The git log command lets you see the commit history. You’ll want to use this to see the history of your commits.

Your commits will come with messages and a hash, which is random series of numbers and letters. An example hash might look like this: c3d882aa1aa4e3d5f18b3890132670fbeac912f7

git log

Let’s say you pushed something that broke your app. Rather than fix it and push something new, you’d rather just go back one commit and try again.

If you want to go back in time and checkout your app from a previous commit, you can do this directly by using the hash as the branch name. This will detach your app from the current version (because you’re editing a historical record, rather than the current version).

git checkout c3d88eaa1aa4e4d5f

Then, if you make changes from that historical branch and you want to push again, you’d have to do a force push.

Caution: Force pushingis 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.