Самая используемая технология разработчиков - это не Javascript.

Это не Python или HTML.

Самая используемая технология - это Git

Освоение Git существенно повлияет на то, как вы управляете кодом и ваш собственный повседневный рабочий процесс.  

Если вы не освоили основные команды git, начните с официальной документации . Это руководство не предназначено для того, чтобы превратить вас из абсолютного новичка в профессионала, и предполагает, что вы уже в некоторой степени владеете git.

Команды Git

Ведение журнала

Что я только что сделал?

git log
git log --oneline # more succinct output
git log --graph # with a visual graph of branche

Просмотр истории отмены действий

git reflog

Потому что иногда git log не работает, особенно для команд, которые не отображаются в вашей истории коммитов.

reflogв основном ваша подстраховка после выполнения «страшных» команд вроде git rebase. Вы сможете увидеть не только сделанные вами коммиты, но и каждое из действий, которые привели вас к этому.

Просмотр вашего текущего состояния + любые конфликты слияния

git status

Хотя git statusэто довольно простая команда, которую мы все изучаем на раннем этапе, ее важность как инструмента обучения для усвоения основ git заслуживает повторения. Она может помочь вам сориентироваться в сложной перестановке или слиянии.

Просмотр, чем отличаются ваши поэтапные (или неустановленные) изменения

git diff --staged # for staged changes
git diff # for unstaged changes

Увидеть различия между двумя ветками

git diff branch1..branch2

Навигация

Я хочу увидеть что я делал раньше

git reset <commit-sha>

Команда отменит фиксацию и деактивацию этих изменений, но оставит эти файлы в рабочем каталоге.

Хочу перейти в другую ветку

git switch branch-name   # new syntax (as of Git 2.23)
git checkout branch-name # old syntax

git checkoutможет немного сбивать с толку, потому что он может работать на уровне файлов и веток. Начиная с Git 2.23 , у нас теперь есть git restore(файл проверки) и git switch(ветка проверки), что очень полезно, если вы только начинаете, чтобы избежать checkoutпутаницы.

Я хочу вернуться в ветку, в которой был

git switch -

Модификации

Я углубился слишком далеко, давайте начнем сначала

git reset --hard HEAD

Эта команда приведет к сбросу вашего локального каталога в соответствии с последней фиксацией и отменой неустановленных изменений.

Я хочу вернуть файл в исходное состояние

git restore <filename>     # new syntax (as of Git 2.23)
git checkout -- <filename> # old syntax

Я хочу отменить последнюю фиксацию и переписать историю

git reset --hard HEAD~1

Я хочу перемотать назад n коммитов

git reset --hard HEAD~n        # n is the last n commits
git reset --hard <commit-sha>  # or to a specific commit

Существует важное различие между мягким, смешанным и жестким сбросом. По сути:

1. --soft: Отменить фиксацию изменений, но оставить эти изменения на стадии
2. --mixed (по умолчанию): отменить фиксацию и отключить изменения, но изменения остаются в рабочем каталоге
3. --hard: Отменить фиксацию, отключить и удалить изменения

Я переписал историю и теперь хочу отправить эти изменения в удаленный репозиторий.

git push -f

Эта команда необходима в любое время, когда ваш локальный и удаленный репозиторий расходятся.

ВНИМАНИЕ : Используйте с осторожностью. Ограничьте принудительную отправку в свои собственные ветки перед открытием запроса на перенос, чтобы случайно не испортить историю git своих товарищей по команде.

Я хочу добавить еще несколько изменений в последний коммит

git commit --amend

Я хочу переписать кучу коммитов локально

git rebase -i <commit hash> # where the commit hash is the one *before* all the changes you want to make

Откроется интерактивная подсказка, в которой вы можете выбрать, какие коммиты сохранить, сжать или удалить. Вы можете изменить сообщения фиксации здесь. Это очень полезно, например, при удалении опечаток или коммитов.

Это перебазирование - беспорядок, давайте его отбросим

git rebase --abort

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

Я хочу внести коммит из другой ветки

# From the branch you want to bring the commit *into*
git cherry-pick <commit-sha>

Я хочу добавить определенный файл из другой ветки

git checkout <branch-name> <file-name>

Я хочу перестать отслеживать файл в системе контроля версий

git rm --cached <file-name>

Мне нужно переключить ветки, но мое текущее состояние не работает

git stash # saves your changes to the top of the stash stack
git stash save "message to go along with changes"
git stash -u # stash untracked files as well

Я хочу посмотреть, что у меня в тайнике

git stash list

Я хочу вернуть кое-что из своего тайника

git stash pop # "pops" the most recent item added to the stash stack
git stash apply stash@{stash_index} # apply a given item in the stash (from git stash list)

Я хочу отменить фиксацию без перезаписи истории

git revert HEAD # undo the last commit
git revert <commit hash> # for a specific commit

Эта команда воспроизведет инверсию фиксации, заданную как новую фиксацию, тем самым отменив ваши изменения без отмены истории. Это гораздо более безопасный способ отменить фиксацию в общих ветвях, где перезапись истории имеет гораздо более серьезные последствия.

Я хочу узнать, какая фиксация вызвала ошибку

git bisect start
git bisect bad           # Current version is bad
git bisect good v1.1     # v1.1 is known to be good

git help bisect          # For more

Очистка

Боже мой, откуда у меня столько веток?

git branch --no-color --merged | command grep -vE "^(\+|\*|\s*(master|develop|dev)\s*$)" | command xargs -n 1 git branch -d

Эта команда удалит все объединенные ветки, которые у вас есть локально, за исключением master, developer или dev. Если у вас разные имена для основной ветки и ветки разработки, вы можете соответствующим образом изменить grepрегулярное выражение.

Это длинная команда, которую следует запомнить, однако вы можете установить для нее такой псевдоним:

alias gbda='git branch --no-color --merged | command grep -vE "^(\+|\*|\s*(master|develop|dev)\s*$)" | command xargs -n 1 git branch -d'

Если вы используете Oh My Zosh, это уже сделано за вас. 

Давайте собираем мусор старые ветки / отдельные коммиты

git fetch --all --prune

Это также действительно полезная команда, если вы настроили удаленный репозиторий для удаления веток при слиянии.

⌨️ Псевдонимы

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

А еще лучше установите такой инструмент, как Oh My Zosh для оболочки Z (Zsh), и вы получите множество наиболее часто используемых команд git в качестве псевдонимов по умолчанию + завершение табуляции для них. 

Вот некоторые самых используемых:

gst - git status
gc  - git commit
gaa - git add --all
gco - git checkout
gp  - git push
gl  - git pull
gcb - git checkout -b
gm  - git merge
grb - git rebase
gpsup - git push --set-upstream origin $(current_branch)
gbda  - git branch --no-color --merged | command grep -vE "^(\+|\*|\s*(master|develop|dev)\s*$)" | command xargs -n 1 git branch -d
gfa - git fetch --all --prune

Если вы забыли, что означают эти или любые другие псевдонимы, которые вы себе присвоили, вы можете просто запустить команду run:

alias

Или для поиска заданного псевдонима:

alias grep <alias-name>

Другие полезные команды Git

Игнорирование файлов

Многие файлы не входят в систему контроля версий. Вы должны использовать для этого свой глобальный gitignore . Примерами того, что не входит в систему контроля версий, являются node_modulesкаталоги .vscodeили другие файлы IDE, а также виртуальные среды Python.

Для получения любой конфиденциальной информации вы можете использовать файлы среды и добавить их в свой локальный .gitignoreкаталог в корне вашего проекта.

Специальные файлы

Вам может потребоваться пометить определенные файлы как двоичные, чтобы git знал, как их игнорировать, и не создавал длинных различий. В Git есть .gitattributesфайл для этой цели. В проекте Javascript вы можете добавить свои yarn-lock.jsonили package-lock.json, чтобы Git не пытался различать их каждый раз, когда вы вносите изменения.

# .gitattributes
package-lock.json binary

Рабочие процессы Git

Rebase против слияния

Ваша команда может выбрать рабочий процесс перебазирования или слияния. У обоих есть свои плюсы и минусы, но оба они используются эффективно. По большей части, если вы действительно не знаете, что делаете, вам, вероятно, следует выбрать рабочий процесс слияния.

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

git rebase master

Настройки удаленного репозитория

1. Удалить ветки при слиянии

Как только все будет объединено, вам больше не нужно будет заботиться о ветке, поскольку история должна отражаться в вашей ветке master / dev. Это значительно сокращает количество веток, которыми вам нужно управлять. git fetch --all --prune  также значительно повышает эффективность содержания вашего локального репозитория в чистоте.

2. Предотвратить нажатие непосредственно на мастер

Без этого вполне объяснимая ошибка - случайно забыть, что вы на мастере, и сделать что-то что потенциально может тормозить вашу производственную сборку. git push

3. Требуется хотя бы одно одобрение перед объединением.

В зависимости от размера вашей команды вы можете потребовать даже более одного утверждения перед объединением. Хотя минимум должен быть один, даже если вы работаете в команде из двух человек. Вам не нужно часами разбирать каждую строчку, но в целом ваш код должен иметь две пары глаз. 

4. Требовать прохождения тестов CI для слияния

Неработающие изменения не следует объединять в производство. Рецензенты не смогут обнаружить неисправные изменения в 100% случаев, поэтому вместо этого автоматизируйте эти проверки. 

Запросы на вытягивание

Делайте запросы на вытягивание небольшими и краткими, в идеале не более пары сотен строк. Небольшие и частые запросы на вытягивание ускорят процесс проверки, приведут к написанию большего количества кода без ошибок и облегчат жизнь вашим товарищам по команде. Что также приведет к повышению продуктивности и большему совместному обучению. Вместе со своей командой возьмите на себя обязательство тратить определенное количество времени на ежедневную проверку открытых запросов на вытягивание.

Нам всем нравится просматривать это:

Если вы работаете над функцией, которая какое-то время будет в неисправном состоянии, используйте флаги функций, чтобы отключить ее в рабочей среде . Это предотвратит слишком большое отклонение вашей функциональной ветки от ветки dev / master и позволит вам делать более частые небольшие запросы на вытягивание. Чем дольше вы будете работать без слияния кода, тем сложнее будет сделать это позже.

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

Сообщения фиксации

Язык важен. В общем,  лучше не коммитить вещи в неисправном состоянии, и каждая фиксация должна иметь краткое сообщение, объясняющее, что должно делать изменение. Следуя официальной рекомендации Git ,  для сообщений коммитов лучше всего использовать настоящее, императивное значение. Думайте о каждом сообщении о фиксации как о команде для компьютера / git, которую вы можете добавить в конец этого предложения:

Если бы этот коммит был применен, он бы ...

Пример хорошего сообщения о фиксации в настоящем, императивном смысле может быть таким:

git commit -m "Add name field to checkout form"

Что теперь гласит: «Если бы эта фиксация была применена, она добавила бы поле имени в форму оформления заказа». Красиво и ясно.