Что такое коммит, ветка и HEAD в Git и что означает «detached HEAD»?

Коммит хранит снимок всего проекта вместе с родительскими коммитами, автором и сообщением, и идентифицируется хешем от всего этого.

В чём разница между git fetch и git pull и что меняет git pull --rebase?

`git fetch` скачивает новые коммиты и сдвигает ветки удалённого отслеживания вроде `origin/main`, но никогда не трогает вашу ветку и ваши файлы.

В чём разница между merge и rebase и почему нельзя делать rebase ветки, в которой работают другие?

Merge соединяет две истории merge-коммитом и оставляет все существующие коммиты как есть.

Как пошагово разрешить конфликт слияния и чего нельзя делать никогда?

Откройте каждый файл с конфликтом, поймите, что хотела каждая сторона, напишите версию, которая сохраняет оба намерения, и удалите маркеры.

Что делают git stash и git cherry-pick и какие ловушки есть у каждой из них?

`git stash` откладывает незакоммиченные изменения и оставляет чистую рабочую копию; `git stash pop` возвращает их обратно.

Как работает .gitignore и почему Git продолжает отслеживать файл, который вы туда добавили?

`.gitignore` лишь не даёт добавить неотслеживаемые файлы; файл, который Git уже отслеживает, остаётся отслеживаемым, что бы ни говорили шаблоны.

Ваша ветка и main обе меняли gradle/libs.versions.toml, и конфликт сидит в [versions]. Как его разрешить и что запустить перед коммитом?

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

Каждая команда ниже выполняется отдельно, начиная с одной и той же запушенной истории. Что покажут git log и git status после каждой и какая безопасна для запушенной ветки?

A, B и C сдвигают `main` обратно на `b2` и отличаются только тем, куда попадает изменение из `c3`: в индекс, в рабочую копию или никуда.

Как привести в порядок коммиты ветки интерактивным rebase перед мержем и почему пушить с --force-with-lease, а не с --force?

`git rebase -i origin/main` показывает список коммитов ветки; если заменить `pick` на `squash`, `fixup`, `reword` или `drop` или переставить строки, коммиты перепишутся в историю, которую приятно читать.

После git reset --hard или неудачного rebase коммиты будто пропали. Как их вернуть и когда это невозможно?

Reset или rebase не удаляет коммиты, а лишь перестаёт на них указывать.

Как git bisect находит коммит, который что-то сломал, и как автоматизировать поиск через git bisect run?

Вы помечаете один коммит плохим, а более старый хорошим, и Git ищет делением пополам среди коммитов между ними: извлекает средний, вы проверяете его и отвечаете `good` или `bad`, и диапазон сокращается вдвое, пока не останется один коммит.

Каким должно быть хорошее сообщение коммита и как Conventional Commits превращают историю в номера версий и changelog?

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

Каким должен быть хороший pull request и как вы ревьюите чужой?

Хороший pull request делает одну вещь, читается за один присест и объясняет, зачем он нужен и как проверен.

Ваша фича-ветка живёт три недели и теперь конфликтует с половиной main. Как её влить и как избежать такого в следующий раз?

Влейте `main` в ветку сейчас одним осознанным мержем, разрешите конфликты и прогоните тесты, а результат по возможности отправьте несколькими pull request, которые реально отревьюить.

Что должно быть в pre-commit хуке и почему CI всё равно должен запускать те же проверки?

Pre-commit хук должен запускать быстрые самоисправляющие проверки только по застейдженным файлам, например форматтер и быстрый линт.

Вы закоммитили секрет и запушили его. Что делать и почему недостаточно удалить его новым коммитом?

Сначала отзовите секрет и выпустите новый, потому что он уже в истории, во всех клонах и форках, а новый коммит прячет его только из последней версии.

PR #42 сломал оформление заказа, поэтому его merge откатили в main. Автор исправил ветку и влил её снова, но скидок в main по-прежнему нет. Почему?

Revert отменяет изменения, но не историю: два коммита PR #42 по-прежнему в `main`, поэтому второй merge приносит только то, что появилось в ветке после, то есть один фикс.

Когда стоит держать несколько приложений и общие библиотеки в одном монорепозитории, а не в отдельных репозиториях, и чего стоит каждый вариант?

Монорепозиторий выбирают, когда код меняется вместе: приложения делят дизайн-систему, API-клиент и модели, и один pull request должен обновить библиотеку и всех её пользователей сразу.

Irbisa · Шпаргалка

Git и командная работа

Merge и rebase, конфликты, reset и revert, cherry-pick, stash, reflog и bisect, стратегии ветвления, pull request и код-ревью, соглашения о коммитах, секреты в истории, файлы Gradle и keystore

Junior-разработчик · 18 вопросов

01
Что такое коммит, ветка и HEAD в Git и что означает «detached HEAD»?
Коммит хранит снимок всего проекта вместе с родительскими коммитами, автором и сообщением, и идентифицируется хешем от всего этого.
02
В чём разница между git fetch и git pull и что меняет git pull --rebase?
git fetch скачивает новые коммиты и сдвигает ветки удалённого отслеживания вроде origin/main, но никогда не трогает вашу ветку и ваши файлы.
```
git fetch origingit log --oneline main..origin/main    # what others pushedgit log --oneline origin/main..main    # what only you have git pull --rebase                      # fetch, then replay your commits on topgit config --global pull.rebase true   # the default from now on
```
03
В чём разница между merge и rebase и почему нельзя делать rebase ветки, в которой работают другие?
Merge соединяет две истории merge-коммитом и оставляет все существующие коммиты как есть.
```
# feature/cart was cut from main, and main has moved sincegit switch feature/cartgit rebase main                      # your commits replayed on top: new hashesgit push --force-with-lease          # only because the branch is yours alone git switch main…
```
04
Как пошагово разрешить конфликт слияния и чего нельзя делать никогда?
Откройте каждый файл с конфликтом, поймите, что хотела каждая сторона, напишите версию, которая сохраняет оба намерения, и удалите маркеры.
```
git merge main# CONFLICT (content): Merge conflict in app/src/main/kotlin/Cart.ktgit status --short                  # UU app/src/main/kotlin/Cart.ktgit log --merge --oneline -- app/src/main/kotlin/Cart.kt   # who changed it on each side # edit it: keep both intentions, delete <<<<<<< ||||||| ======= >>>>>>>…
```
05
Что делают git stash и git cherry-pick и какие ловушки есть у каждой из них?
git stash откладывает незакоммиченные изменения и оставляет чистую рабочую копию; git stash pop возвращает их обратно.
06
Как работает .gitignore и почему Git продолжает отслеживать файл, который вы туда добавили?
.gitignore лишь не даёт добавить неотслеживаемые файлы; файл, который Git уже отслеживает, остаётся отслеживаемым, что бы ни говорили шаблоны.
```
# local.properties is in .gitignore, yet:git ls-files local.properties     # prints the path: the file is trackedgit status --short                #  M local.properties git rm --cached local.propertiesgit commit -m "chore: stop tracking local.properties"…
```
07
Ваша ветка и main обе меняли gradle/libs.versions.toml, и конфликт сидит в [versions]. Как его разрешить и что запустить перед коммитом?
Разрешайте по смыслу, строка за строкой: оставьте новые записи обеих сторон, а там, где обе изменили одну версию, берите более новую, если только другая сторона не откатила её намеренно.
```
# gradle/libs.versions.toml after `git merge main` on feature/offline[versions]<<<<<<< HEADagp = "8.11.1"kotlin = "2.1.21"room = "2.7.2"…
```
08
Каждая команда ниже выполняется отдельно, начиная с одной и той же запушенной истории. Что покажут git log и git status после каждой и какая безопасна для запушенной ветки?
```
# main, already pushed:#   c3 Add retry     <- HEAD#   b2 Add client#   a1 Init# c3 changed app/src/main/kotlin/ApiClient.kt; the working tree is clean. git reset --soft HEAD~1    # Agit reset HEAD~1           # B (--mixed is the default)git reset --hard HEAD~1    # Cgit revert HEAD            # D
```
A, B и C сдвигают main обратно на b2 и отличаются только тем, куда попадает изменение из c3: в индекс, в рабочую копию или никуда.
09
Как привести в порядок коммиты ветки интерактивным rebase перед мержем и почему пушить с --force-with-lease, а не с --force?
git rebase -i origin/main показывает список коммитов ветки; если заменить pick на squash, fixup, reword или drop или переставить строки, коммиты перепишутся в историю, которую приятно читать.
```
git fetch origingit rebase -i --autosquash origin/main # the todo list Git opens, after your edits# (--autosquash already moved the fixup! commit under its target):pick 3f9c2e1 # feat: cart badge…
```
10
После git reset --hard или неудачного rebase коммиты будто пропали. Как их вернуть и когда это невозможно?
Reset или rebase не удаляет коммиты, а лишь перестаёт на них указывать.
```
$ git reset --hard HEAD~2          # oops: two commits "gone"$ git refloga872130 HEAD@{0}: reset: moving to HEAD~2d6eb664 HEAD@{1}: commit: Debounce search7a7b367 HEAD@{2}: commit: Add search fielda872130 HEAD@{3}: checkout: moving from main to feature/search…
```
11
Как git bisect находит коммит, который что-то сломал, и как автоматизировать поиск через git bisect run?
Вы помечаете один коммит плохим, а более старый хорошим, и Git ищет делением пополам среди коммитов между ними: извлекает средний, вы проверяете его и отвечаете good или bad, и диапазон сокращается вдвое, пока не останется один коммит.
```
git bisect startgit bisect bad                 # HEAD: the cart total is wronggit bisect good v3.8.0         # the last release where it was right # CartTotalRegressionTest.kt is new and untracked, under feature/cart/src/test/git bisect run sh -c '…
```
12
Каким должно быть хорошее сообщение коммита и как Conventional Commits превращают историю в номера версий и changelog?
Хорошее сообщение коротким заголовком в повелительном наклонении говорит, что делает коммит, а в теле объясняет зачем.
```
feat(cart): show a discount badge on eligible items The badge reads the rule from /v2/discounts instead of theclient-side list, so marketing can change rules without a release. Closes #418…
```
13
Каким должен быть хороший pull request и как вы ревьюите чужой?
Хороший pull request делает одну вещь, читается за один присест и объясняет, зачем он нужен и как проверен.
14
Ваша фича-ветка живёт три недели и теперь конфликтует с половиной main. Как её влить и как избежать такого в следующий раз?
Влейте main в ветку сейчас одним осознанным мержем, разрешите конфликты и прогоните тесты, а результат по возможности отправьте несколькими pull request, которые реально отревьюить.
15
Что должно быть в pre-commit хуке и почему CI всё равно должен запускать те же проверки?
Pre-commit хук должен запускать быстрые самоисправляющие проверки только по застейдженным файлам, например форматтер и быстрый линт.
```
# lefthook.yml: committed; `lefthook install` wires .git/hooks after a clonepre-commit:  commands:    ktlint:      glob: "*.{kt,kts}"      run: ktlint --format {staged_files}…
```
16
Вы закоммитили секрет и запушили его. Что делать и почему недостаточно удалить его новым коммитом?
Сначала отзовите секрет и выпустите новый, потому что он уже в истории, во всех клонах и форках, а новый коммит прячет его только из последней версии.
```
# 0) Revoke the secret at the provider and ship the new one. Only then:git clone git@github.com:acme/shop.git shop-clean && cd shop-clean # drop the file from every commitgit filter-repo --sensitive-data-removal --invert-paths --path app/play-service-account.json# or replace the value wherever it appears ("old==>new" per line):…
```
17
PR #42 сломал оформление заказа, поэтому его merge откатили в main. Автор исправил ветку и влил её снова, но скидок в main по-прежнему нет. Почему?
```
git switch maingit merge --no-ff feature/discounts   # PR #42: two feature commitsgit revert -m 1 HEAD                  # checkout broke: undo the mergegit push git switch feature/discounts# add a guard in app/src/main/kotlin/Cart.kt, away from the lines the feature changedgit commit -am "fix: skip checkout for an empty cart"git switch maingit merge feature/discounts           # merges cleanly
```
Revert отменяет изменения, но не историю: два коммита PR #42 по-прежнему в main, поэтому второй merge приносит только то, что появилось в ветке после, то есть один фикс.
18
Когда стоит держать несколько приложений и общие библиотеки в одном монорепозитории, а не в отдельных репозиториях, и чего стоит каждый вариант?
Монорепозиторий выбирают, когда код меняется вместе: приложения делят дизайн-систему, API-клиент и модели, и один pull request должен обновить библиотеку и всех её пользователей сразу.

Git и командная работа

Что такое коммит, ветка и `HEAD` в Git и что означает «detached HEAD»?

В чём разница между `git fetch` и `git pull` и что меняет `git pull --rebase`?

В чём разница между merge и rebase и почему нельзя делать rebase ветки, в которой работают другие?

Как пошагово разрешить конфликт слияния и чего нельзя делать никогда?

Что делают `git stash` и `git cherry-pick` и какие ловушки есть у каждой из них?

Как работает `.gitignore` и почему Git продолжает отслеживать файл, который вы туда добавили?

Ваша ветка и `main` обе меняли `gradle/libs.versions.toml`, и конфликт сидит в `[versions]`. Как его разрешить и что запустить перед коммитом?

Как привести в порядок коммиты ветки интерактивным rebase перед мержем и почему пушить с `--force-with-lease`, а не с `--force`?

После `git reset --hard` или неудачного rebase коммиты будто пропали. Как их вернуть и когда это невозможно?

Как `git bisect` находит коммит, который что-то сломал, и как автоматизировать поиск через `git bisect run`?

Каким должно быть хорошее сообщение коммита и как Conventional Commits превращают историю в номера версий и changelog?

Каким должен быть хороший pull request и как вы ревьюите чужой?

Ваша фича-ветка живёт три недели и теперь конфликтует с половиной `main`. Как её влить и как избежать такого в следующий раз?

Что должно быть в pre-commit хуке и почему CI всё равно должен запускать те же проверки?

Вы закоммитили секрет и запушили его. Что делать и почему недостаточно удалить его новым коммитом?

PR #42 сломал оформление заказа, поэтому его merge откатили в `main`. Автор исправил ветку и влил её снова, но скидок в `main` по-прежнему нет. Почему?

Когда стоит держать несколько приложений и общие библиотеки в одном монорепозитории, а не в отдельных репозиториях, и чего стоит каждый вариант?