Ось усі команди Git, якими я користувався минулого тижня, і те, що вони роблять.

Як і більшість початківців, я розпочав пошук команд Git у StackOverflow, потім скопіював відповіді, не розуміючи, що вони зробили.

Я пам’ятаю, думав,"Чи не було б непогано, якби був список найпоширеніших команд Git разом із поясненням, чому вони корисні?"

Що ж, ось я роками пізніше складаю такий список і викладаю найкращі практики, які навіть середньо-просунуті розробники можуть виявити корисними.

Щоб все було практично, я базую цей список на основі фактичних команд Git, якими я користувався минулого тижня.

Майже кожен розробник використовує Git, і, швидше за все, GitHub. Але пересічний розробник, ймовірно, використовує ці три команди лише 99% часу:

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

Це все добре і добре, коли ви працюєте в команді від однієї особи, на хакатоні чи в додатку, який викидаєте, але коли стабільність та обслуговування починають ставати пріоритетними, очищення комітетів, дотримання стратегії розгалуження та написання узгоджене повідомлення про коміти стає важливим.

Я почну зі списку загальновживаних команд, щоб полегшити новачкам розуміння можливостей Git, а потім перейду до вдосконалених функціональних можливостей та найкращих практик.

Регулярно використовувані команди

Щоб ініціалізувати Git у сховищі (repo), вам просто потрібно ввести наступну команду. Якщо ви не ініціалізуєте Git, ви не зможете виконати будь-які інші команди Git у цьому репо.

git init

Якщо ви використовуєте GitHub і надсилаєте код до репозиторію GitHub, який зберігається в Інтернеті, ви використовуєте віддалений репо. Ім'я за замовчуванням (також відоме як псевдонім) для цього віддаленого репо - це джерело . Якщо ви скопіювали проект із Github, він уже має походження . Ви можете переглянути це джерело за допомогою команди git remote -v , де буде вказана URL-адреса віддаленого репо.

Якщо ви ініціалізували власне репозиторій Git і хочете пов’язати його з репозитарієм 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, за яким йде URL-адреса репо.

Майте на увазі, що віддалене сховище буде пов’язане з обліковим записом, з якого ви клонували репо. Отже, якщо ви клонували репо, яке належить комусь іншому, ви не зможете перейти на GitHub, доки не зміните джерело, використовуючи команди вище.

git clone 

Ви швидко опинитесь за допомогою гілок. Якщо ви не розумієте, що таке гілки, є інші настанови, які є набагато глибшими, і перед тим, як продовжувати, вам слід прочитати їх (ось один).

Команда git branch відображає всі гілки на вашому локальному комп'ютері. Якщо ви хочете створити нову гілку, ви можете використовувати гілку gitme>, з & lt; name>, що представляє назву гілки, наприклад «master».

Перевірка gitme> команда перемикається на існуючу гілку. Ви також можете використати команду git checkout -b & lt; name>, щоб створити нову гілку та негайно перейти до неї. Більшість людей використовують це замість окремих команд гілки та оформлення замовлення.

git branchgit branch git checkout git checkout -b 

Якщо ви зробили купу змін у гілці, назвемо це «розробкою», і ви хочете об’єднати цю гілку назад у свою головну гілку, ви використовуєте git merge

ch> команда. Ви ва нт до сп eckout майстер гілки, п запустити мерзотник злиття d evelop злитися перерости в основній гілці.

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.

Original text