-
Notifications
You must be signed in to change notification settings - Fork 6
Соглашение по работе с Git
Alexey Chudinov edited this page Sep 19, 2015
·
16 revisions
-
git clone <url>- клонируем проект.
-
git pull --rebase origin master- обновляем веткуmasterс ключём--rebase, чтобы избежать промежуточных коммитов. - Если конфликтов не произошло, то пропускаем этот пункт. Если есть, то правим руками (см. п. 3.4).
- Делаем изменения в коде, например, добавляем главную страницу.
-
git add -A- индексируем изменения. -
git commit -m 'feat #100: добавил главную страницу'- закоммитили в соответствии с соглашением по коммитоименованию. -
git push origin master- заливаем изменения в удалённый репозиторийй в веткуmaster.
- Правим руками файлы, содержащие конфликты (посмотреть их можно через
git status):
<<<<<<< HEAD
// 1 секция: Код текущей ветки
=======
// 2 секция: Наш изменения в коде
>>>>>>> master
Чтобы разрешить конфликт, нужно оставить только 2-ю секцию:
// 2 секция: Наш изменения в коде
- После этого индексируем изменения.
git add -A
- Далее нужно продолжить
rebaseс помощью команды:
git rebase --continue
- Если конфликтов больше нет и
reabaseзавершился, то на это всё, если конфликты есть, то повторить итерацию.
Название веток указываем как feat/<name>, причем <name> пишем на русском языке.
-
git pull --rebase origin master- обновляем веткуmasterс ключём--rebase, чтобы избежать промежуточных коммитов. -
git checkout -b feat/<name>- создаём ветку сfeat/<name>, где<name>- название фичи. - Делаем изменения в коде, например, добавляем главную страницу.
-
git add -A- индексируем изменения. -
git commit -m 'feat #100: добавил главную страницу'- закоммитили в соответствии с соглашением по коммитоименованию, обязательно указав номер задачи. -
git push origin feat/<name>- заливаем нашу ветку в удалённый репозиторий.
- Находясь в ветке фичи выполняем команду:
git rebase master
- Если конфликтов нет, то пропускаем этот пункт. Если есть, то разрешаем конфликты (см. п. 3.4).
-
git push origin master- заливаем итоговые изменения в удалённый репозиторий.
Если необходимо внести изменения, но при этом создание фичи не планируется,
то следует назвать ветку как <type>, где <type> совпадает с типом,указанным в п. 2.2.
-
git commit --amend- позволяет изменить название коммита. Если нужно включить ещё и изменённые файлы, то перед этим проиндексировать файлы. -
git reset --hard HEAD^- полное удаление последнего коммита.
Каждый коммит начинается с типа (type) и сообщения (subject).
В самом конце может быть описание (body) с замечанием и т.п.
-
type- тип изменений, который содержит коммит; -
scope- область кода в которой сделали изменение; -
subject- сообщение; -
body(не обязательно) - подробно описание изменнений или важное замечание.
<type>: <subject> в <scope>
<BLANK LINE>
<body>
Примеры:
feat: добавил дополнительную валидацию в модель User
fix: исправил баг с авторизацией в контроллере User
refactor: вынес повторяющийся код в отдельный метод findById в контроллере User
Здесь можно написать поясняющие подробности
Все коммиты пишем на русском языке, за исключением типа (type)
Каждая строка в коммите может содержать не более 100 символов
-
feat- новая фича; -
fix- багофикс; -
docs- изменения в документации; -
style- форматирование кода или любые другие изменения, не влияющие на работу кода; -
refactor- изменения в коде, которые не относятся к фиксам или фиче; -
test- добавлен или обновлён тест; -
chore- измененения в сборщике, зависимостях и т.п.
- Первое слово с прописной буквы, не с заглавной;
- Не ставьте точку на конце.