Модуль 08 — Командная работа

В большинстве команд работа идёт по одной схеме (её называют GitHub Flow или просто «ветка под задачу»): в main напрямую не коммитят, каждая задача — своя ветка, в main она попадает только после проверки.

# 1. свежий main
$ git switch main
$ git pull

# 2. ветка под задачу
$ git switch -c feature/contacts-form

# 3. работа: коммиты маленькими шагами
$ git add contacts.html
$ git commit -m "Добавить форму обратной связи"

# 4. ветка на сервер
$ git push -u origin feature/contacts-form

# 5. на GitFlic — запрос на слияние в main, проверка, слияние

# 6. забрать результат, удалить ветку
$ git switch main
$ git pull
$ git branch -d feature/contacts-form

Запрос на слияние (merge request, на других платформах — pull request) — предложение влить ветку в другую, чаще всего в main. Это не команда Git, а функция git-хостинга: страница, на которой видны все изменения ветки, идёт обсуждение и принимается решение.

Пример описания:

Добавить форму обратной связи

Что сделано:
- форма с полями «имя», «почта», «сообщение» в contacts.html
- проверка заполнения полей в браузере

Как проверить:
открыть contacts.html, отправить пустую форму — появится подсказка

Не сделано:
отправка на почту — отдельной задачей

Проверяющий читает изменения, оставляет комментарии к строкам. Исправления делаются в той же ветке обычными коммитами и git push — запрос обновляется сам. Когда замечаний нет, запрос сливают кнопкой в интерфейсе; ветку после этого можно удалить на сервере.

В рабочем каталоге всегда есть файлы, которым не место в репозитории: служебные файлы редактора и ОС, зависимости, результаты сборки, логи и — главное — файлы с паролями. Файл .gitignore в корне проекта перечисляет шаблоны, которые Git не показывает в git status и не добавляет через git add ..

# служебные файлы ОС и редакторов
.DS_Store
Thumbs.db
.vscode/
.idea/

# зависимости и сборка
node_modules/
dist/
__pycache__/
*.pyc

# логи и временные файлы
*.log
*.tmp

# секреты: пароли, ключи, токены
.env
*.key

# исключение из правила: пример настроек — в репозиторий
!.env.example

Проверить, какое правило скрывает файл: git check-ignore -v app.log.

Вы на середине задачи, а нужно срочно переключиться на другую ветку. Коммитить недоделанное не хочется. git stash убирает несохранённые изменения в отдельное хранилище и очищает рабочий каталог:

$ git stash push -m "форма: половина полей"
Saved working directory and index state On feature/contacts-form: форма: половина полей

$ git switch main           # срочная работа ...
$ git switch feature/contacts-form

$ git stash list
stash@{0}: On feature/contacts-form: форма: половина полей

$ git stash pop              # вернуть изменения и удалить из хранилища

Новые неотслеживаемые файлы по умолчанию в stash не попадают — добавьте флаг -u. Stash — временное место на час, не на неделю: через неделю никто не вспомнит, что там лежит.

Главный вопрос перед отменой: отправлен ли коммит на сервер.

git revert — для общей истории. Создаёт новый коммит, обратный указанному. История не переписывается, у коллег ничего не ломается:

$ git revert b82e4d1
[main 6f0e1a3] Revert "Перенести контакты в подвал страницы"
 1 file changed, 3 insertions(+), 3 deletions(-)
$ git push

git reset — для своих, ещё не отправленных коммитов. Передвигает текущую ветку назад, как будто последних коммитов не было:

Тег — постоянная метка на коммите, обычно номер версии. В отличие от ветки, тег не сдвигается.

$ git tag -a v1.0 -m "Первая публичная версия портфолио"
$ git tag
v1.0
$ git show v1.0 --stat
$ git push origin v1.0          # теги отправляются отдельно

Номера версий обычно пишут по схеме MAJOR.MINOR.PATCH: v1.0.0 → v1.0.1 (исправление) → v1.1.0 (новая возможность) → v2.0.0 (несовместимые изменения).

git rebase main переносит коммиты текущей ветки так, будто она была создана от последнего коммита main. История получается прямой, без коммитов слияния. Команда переписывает коммиты — у них меняются хеши.

До:        A ◀── B ◀── C            main
                  ▲
                  └── D ◀── E        feature

git rebase main (на ветке feature)

После:     A ◀── B ◀── C            main
                        ▲
                        └── D' ◀── E'    feature