Шпаргалка по Git

$ git clone ssh://user@domain.com/repo.git
$ git init

Локальные изменения

$ git status
$ git diff

Устаревающий способ

$ git add .

Советую использовать эту команду

$ git add -A
$ git add -p <файл>
$ git commit -a
$ git commit
$ git commit --amend

История коммитов

$ git log
$ git log -p <файл>
$ git blame <файл>

Ветки и теги

$ git branch -av
$ git checkout <ветка>
$ git branch <новая-ветка>
$ git checkout -b <новая-ветка>
$ git checkout --track <репо/ветка>
$ git branch -d <ветка>
$ git tag <имя-тега>

Обновление и публикация

$ git remote -v
$ git remote show <репо>
$ git remote add <короткое-имя> <url>
$ git fetch <репо>
$ git pull <репо> <ветка>
$ git push <репо> <ветка>
$ git branch -dr <репо/ветка>
$ git push --tags

Слияние и перемещение

$ git merge <ветка>
$ git rebase <ветка>
$ git rebase --abort
$ git rebase --continue
$ git mergetool
$ git add <разрешенный-файл>$ git rm <разрешенный-файл>

Отмена

$ git reset --hard HEAD
$ git checkout HEAD <файл>
$ git revert <коммит>

…и отменить все изменения после него

$ git reset --hard <коммит>

…и сохранить все изменения как незакоммиченые

$ git reset <коммит>

…и сохранить неотслеживаемые локальные изменения

$ git reset --keep <коммит>

Лучшие практики

Добавляйте в коммит связанные изменения

Коммит должен содержать связанные изменения. Например, правки двух разных багов должны быть в двух разных коммитах. Маленькие коммиты помогают другим разработчикам проще понимать изменения и откатить их, если что-то пойдет не так.
При помощи таких инструментов, как область подготовленных файлов и возможности добавлять только часть изменений из файла, Git упрощает создание очень мелких коммитов.

Делайте коммиты часто

Частая публикация коммитов позволяет вам делать их маленькими и, опять же, помогает добавлять в коммит только связанные изменения. Более того, почаще делитесь своим кодом с остальными. Таким образом, всем будет легче, если вы чаще будете интегрировать свои изменения и это поможет избежать конфликтов при слиянии. Большие и редкие коммиты усложняют жизнь и затрудняет решение конфликтов.

Не публикуйте коммиты с незаконченной работой

Вы должны коммитить код, только если он завершен. Это не значит, что вы должны полностью закончить работу над большой задачей перед коммитом. Наоборот: разделите работу над задачей на логические части и помните о своевременной и частой публикации коммитов. Но не публикуйте изменения только чтобы в репозитории что-то появилось перед вашим уходом из офиса в конце рабочего дня. Если вы собираетесь опубликовать коммит только потому, что вам нужна чистая рабочая область (при переключении веток, перед pull и т.д.) присмотритесь к функци “stash”.

Тестируйте код перед коммитом

Не поддавайтесь искушению закоммитить что-то, что на ваш взгляд уже готово. Протестируйте внимательно и убедитесь в том, что работа закончена и в коде нет ошибок (на сколько это может проверить один человек). В то время, как полусырые изменения в вашем локальном репозитории вы можете простить себе самому, вы должны тщательно протестировать код перед тем как публиковать/делится своим кодом с другими.

Пишите хорошие комментарии

Начните свое сообщение с краткого резюме своих изменений (ориентируйтесь на 50 символов). Отделите это сообщение от основного текста пустой строкой. В теле сообщения следует дать подробные ответы на следующие вопросы:

Используйте слова в настоящем времени («меняется», не «был изменен» или «изменения») чтобы при git merge сгенерированное сообщение выглядело хорошо.

Система контроля версий не хранилище бекапов

Хранение резервных копий файлов на удаленном сервере это только приятный побочный эффект использования системы контроля версий. Но вы не должны использовать Git только для этого. При работе с системой обратите особое внимание на семантику коммитов (смотри пункт 1) — вы не должны просто запихивать файлы в репозиторий.

Используйте ветки

Ветвление — это одна из самых мощных возможностей Git. И это не случайно: быстрое и простое ветвление было требованием номер один с самого начала. Ветки являются самым простым инструментом чтобы избежать смешивания разных линий разработки. Вы должны повсеместно использовать ветки в своей разработке: для работы над новыми задачами, для исправления багов, для идей…

Согласуйте рабочий процесс

Git позволяет выбрать из большого количества рабочих процессов: длинные ветки, тематические ветки, слияние или перемещение, gitflow… Что из этого выберите вы зависит от нескольких факторов: ваш проект, ваше общее направление развития, среда разработки и (возможно самое важное) ваши личные предпочтения и предпочтения вашей команды. Что бы вы не выбрали убедитесь, что все следуют процессу, который был согласован.

Помощь и документация

Вызов помощи git в командной строке

$ git help <command>

Нашли ошибку? Воспользуйтесь функцией Private notes: выделяете текст с ошибкой, нажимаете на символ замка в появившемся дудле и оставляете свой комментарий. Спасибо!

Перевод шпаргалки от Git Tower

Frontend-дева. Верстаю, пишу и перевожу статьи, менторю, выступаю. Поддержать переводы: https://www.tinkoff.ru/sl/2QSPTULCQcC

Frontend-дева. Верстаю, пишу и перевожу статьи, менторю, выступаю. Поддержать переводы: https://www.tinkoff.ru/sl/2QSPTULCQcC