Шпаргалка по командам git
Что делать, когда под руками нет SourceTree
Основной сценарий
Шаг 1
У нас есть задача (issue), которую мы планируем сделать. В центральном репозитории создаём ветку для решения задачи. Например, для задачи с номером 234 создаём ветку features/issue-234.
Примечание: префикс features/ влияет на отображение > веток в таких графических клиентах, как Git Extensions и Sourcetree. Ветки, в чьих именах встреыется символ / выглядят как файлы в каталогах. Так, ветка features/issue-234 выглядит как ветка issue-234 в каталоге features.
Так удобно группировать ветки.
Шаг 2
Теперь в удалённом репозитории есть ветка, где мы будем работать над задачей. Нам нужна такая же ветка в локальном репозитории. Локальную ветку надо создать и связать с удалённой.
Сначала скачиваем из удалённого репозитория изменения, включая новые ветки
git fetch
Чтобы убедиться, что удалённая ветка доступна локально, выполняем команду
git branch -a
Создаём локальную ветку, которая указывает на удалённую ветку
git checkout -b features/issue-234 origin/features/issue-234
или, короче
git checkout -t origin/features/issue-234
Шаг 3
Далее работаем над задачей в локальной ветке, время от времени фиксируя изменения.
Прежде, чем фиксировать, смотрим, что успели сделать.
git status
- Untracked — git не отслеживает изменения в этих файлах и не хранит их.
- Changes not staged for commit — git отлеживает и хранит эти файлы. Сейчас эти файлы изменены, но git не будет сохранять эти изменения при фиксации.
- Changes to be committed — файлы изменены и git сохранит эти изменения при следующей фиксации.
Помечаем для фиксации файлы file₁..fileₙ.
git add file₁ ... fileₙ
Помечаем для фиксации все файлы в текущем каталоге и его подкаталогах. Помеченными окажутся в том числе все новые файлы.
git add .
Фиксируем все файлы, помеченные для фиксации. Git попросит ввести комментарий.
git commit
Команда git commit -a работает также, как git add . и git commit вместе, за тем исключением, что новые файлы не будут зафиксированы.
Команда git commit -m "Комментарий к коммиту" фиксирует изменения с указанным комментарием, не запуская внешний редактор.
Отправляем изменения в центральный репозиторий.
git push
Откат изменений
Если вы изменили файлы, но ещё не фиксировали изменения, вы можете изменить отдельные файлы:
git checkout -- file₁ ... fileₙ
Либо вы можете отказить изменения во всех файлах в каталоге и его подкаталогах:
git checkout -- .
Если вы зафиксировали изменения, но ещё не отправили их в удалённый репозиторий, откатите последнюю фиксацию:
git reset --hard
Если комит был отправлен в удалённый репозиторий, считается корректным не удалять его, а создать парный к нему отменяющий коммит.
git revert <commit-id>
Если вы случайно добаили к списку отслеживаемых файлов что-то, что не надо отслеживать, например, временные файлы *.tmp или результаты компиляции *.obj, вы можете удалить их из репозитория:
git rm --cached file₁ ... fileₙ
Без флага --cached git удалит файлы и в репозитории, и на диске. Эта же команда используется, если вы обновили .gitignore и хотите удалить из репозитория файлы, которые соответствуют новым правилам .gitignore:
git rm --cached .
git add .
Первая команда удалит из репозитория всех файлы (оставив их на диске), а вторая снова добавит их в репозиторий. При добавлении git проверит файлы на соответствие шаблонам .gitignore.
Удалить с диска новые файлы
git clean -f -d
Шаг 4
Решив задачу мы должны слить все изменения в основную ветку — master или main. Это делается через pull request в центральном репозитории. Ставим галочку удалить исходную ветку после слияния, чтобы не пришлось удалять эти ветку вручную.
Теперь надо избавиться от локальной ветки, где мы работали. Сначала переключимся на основную ветку.
git checkout master
«Затягиваем» в неё изменения из центрального репозитория.
git fetch
После изменения можно слить с текущей веткой:
git merge
После слияния в истории репозитория остаются «следы» — коммиты сначла расходятся, потом снова сходятся. Можно избавиться от следов, склеив все коммиты в одну ветку:
git rebase
Вместо команд:
git fetch
git merge
можно использовать:
git pull
Вместо команд:
git fetch
git rebase
можно использовать:
git pull --rebase
Синхронизация веток
Смотрим, какие ветки живы локально, но при этом удалены на сервере.
git remote prune origin
Удаляем ветки, которые показала предыдущая команда.
git branch -d features/issue-234
Удаляем из центрального репозитория ветки, которых нет у нас:
git push --mirror
Вливаем изменения из центрального репозитория
Если в ветке master появились изменения, мы можем влить в нашу ветку, чтобы в будущем упростить pull request. Переключаемся на ветку master, загружаем обновления, переключаемя на рабочую ветку, сливаемся с master и выгружаем результат в центральный репозиторий. Если конфликтов не было, pull request пройдёт без проблем.
git checkout master
git pull
git checkout features/issue-234
git merge master
git push