Подобно на повечето начинаещи, започнах да търся StackOverflow за Git команди, след това да копирам отговорите, без наистина да разбирам какво са направили.

Спомням си, че си мислех,„Не би ли било хубаво, ако имаше списък с най-често срещаните Git команди, заедно с обяснение защо са полезни?“

Е, ето ме години по-късно, за да съставя такъв списък и да изложа някои най-добри практики, които дори средно напредналите разработчици трябва да намерят за полезни.

За да запазя нещата на практика, базирам този списък от действителните Git команди, които използвах през изминалата седмица.

Почти всеки разработчик използва Git и най-вероятно GitHub. Но средният разработчик вероятно използва само тези три команди 99% от времето:

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

Всичко това е добре и добре, когато работите в екип от един човек, хакатон или приложение за изхвърляне, но когато стабилността и поддръжката започват да стават приоритет, почистването на ангажименти, придържането към стратегия за разклоняване и писането съгласуваните съобщения за ангажиране става важно.

Ще започна със списъка с често използвани команди, за да улесня начинаещите да разберат какво е възможно с Git, след което ще премина към по-разширената функционалност и най-добрите практики.

Редовно използвани команди

За да инициализирате Git в хранилище (repo), просто трябва да въведете следната команда. Ако не инициализирате Git, не можете да стартирате други Git команди в рамките на това репо.

git init

Ако използвате GitHub и натискате код към репозитория на GitHub, който се съхранява онлайн, използвате отдалечен репо. Името по подразбиране (известно също като псевдоним) за това отдалечено репо е origin . Ако сте копирали проект от Github, той вече има произход . Можете да видите този произход с командата git remote -v , която ще изброи URL адреса на отдалеченото репо.

Ако сте инициализирали вашето собствено Gpo репо и искате да го свържете с GitHub репо, ще трябва да създадете такова в GitHub, да копирате предоставения URL адрес и да използвате командата git remote add originRL>, като URL адресът, предоставен от GitHub, заменя „“. Оттам можете да добавяте, фиксирате и натискате към отдалеченото репо.

Последният се използва, когато трябва да смените отдалеченото хранилище. Да приемем, че сте копирали репо от някой друг и искате да промените отдалеченото хранилище от първоначалния собственик на вашия собствен акаунт в GitHub. Следвайте същия процес като git remote add origin , освен вместо това използвайте set-url, за да промените отдалеченото репо.

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

Най-често срещаният начин за копиране на репо е използването на git clone, последван от URL адреса на репото.

Имайте предвид, че отдалеченото хранилище ще бъде свързано с акаунта, от който сте клонирали репото. Така че, ако сте клонирали репо, което принадлежи на някой друг, няма да можете да натиснете GitHub, докато не промените произхода, като използвате командите по-горе.

git clone 

Бързо ще се озовете с помощта на клонове. Ако не разбирате какво представляват клоновете, има и други уроци, които са много по-задълбочени и трябва да ги прочетете, преди да продължите (ето един).

Командата git клон изброява всички клонове на вашата локална машина. Ако искате да създадете нов клон, можете да използвате git branchme>, с & lt; name>, представляващо името на клона, като “master”.

В Git касатаme> команда превключва към съществуващ клон. Можете също така да използвате командата git checkout -b & lt; name>, за да създадете нов клон и незабавно да преминете към него. Повечето хора използват това вместо отделни команди за клон и плащане.

git branchgit branch git checkout git checkout -b 

Ако сте направили куп промени в клон, нека го наречем „разработка“ и искате да обедините този клон обратно във вашия главен клон, използвайте git merge

ch> команда. Няма да можете да изтеглите главния клон, а n run git merge d evelop за сливане ще се развие в master клона.

git merge 

Ако работите с множество хора, ще се окажете в позиция, при която репото е актуализирано в GitHub, но нямате промените локално. Ако случаят е такъв, можете да използвате git pull origin

ch> за изтегляне на най-новите промени от този отдалечен клон.

git pull origin 

Ако сте любопитни да видите какви файлове са променени и какво се проследява, можете да използвате git status . Ако искате да видите колко е променен всеки файл, можете да използвате git diff, за да видите броя редове, променени във всеки файл.

git statusgit diff --stat

Разширени команди и най-добри практики

Скоро стигате до точка, в която искате вашите ангажименти да изглеждат добре и да останат последователни. Може също да се наложи да бъркате в историята на вашите ангажименти, за да улесните разбирането на вашите ангажименти или да върнете случайна пробивна промяна.

Командата git log ви позволява да видите историята на фиксирането. Ще искате да използвате това, за да видите историята на вашите ангажименти.

Вашите ангажименти ще идват със съобщения и хеш , който е произволна поредица от цифри и букви. Примерен хеш може да изглежда така: c3d882aa1aa4e3d5f18b3890132670fbeac912f7

git log

Да приемем, че сте натиснали нещо, което е счупило приложението ви. Вместо да го поправяте и да натискате нещо ново, по-скоро просто се върнете с един ангажимент и опитайте отново.

Ако искате да се върнете назад във времето и да изтеглите приложението си от предишен коммит, можете да направите това директно, като използвате хеш като име на клон. Това ще отдели приложението ви от текущата версия (защото редактирате исторически запис, а не текущата версия).

git checkout c3d88eaa1aa4e4d5f

След това, ако направите промени от този исторически клон и искате да натиснете отново, ще трябва да направите натиск със сила.

Внимание: Силово натискане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.