# Our git workflow
# Working on a Story
# Prepare the branch
git checkout master
(some projects can usedevelop
for upstream).git pull origin master
git checkout -b PROJ-XXX
git push origin PROJ-XXX
- Create Merge Request of
PROJ-XXX
to the parent branch (master
,develop
or maybehotfix-*
) with prefixDraft:
.
# Finishing the Story
- Remove
Draft:
prefix from the Merge Request. - Perform Code Review
- Merge the MR. Some projects have a project leader who's resposible for approving MRs.
# How to working with a team on single Story
Story must be splitted to several sub-tasks. Every team member creates his own branch. The workflow is similiar as working on a Story:
- Checkout current Story branch
git checkout PROJ-XXX
- Sync it
git pull origin PROJ-XXX
- Create new branch for the subtask
git checkout -b PROJ-YYYY
# Workflow for hotfixes
# Preparing the branch
- Pull all the tags
git pull --tags
- Choose a version for the hotfix
git tag -l --sort=-v:refname
- Checkout that version
git checkout 9.12.4.2
- Make a new branch with prefix
hotfix-
git checkout -b hotfix-9.12.4.3
- Push it
git push origin hotfix-9.12.4.3
- Create a MR with
hotfix-9.12.4.3
as the source branch . That will help you to not forget to merge all the bug fixes to the upstream.
# Cherry picking fixes from upstream
- Use
git cherry-pick
in order to accumulate all the merged fixed fromdevelop
to the hotfix branch. Example:git cherry-pick ba47d721 -m 1
- Push the brahch
git push origin hotfix-9.12.4.3
# Our git conventions
- Make and push commits regularly.
- Commits on upstream must have Jira's ID. Example,
PROJ-5222 your message
If you're working in branch and later intended to usesquash commits
, you can omit that. - Use Present Simple Tense for commit messages. Example,
PROJ-5522 add README.md
.
# Создание Merge-Request
# Рекомендации
- В Title пишем "TASK-ID Заголовок". Пример "GDBC-2244 подключение сервера Autocert".
- В Assignees указываем всех, от кого нужен финдбек.
- Ставьте галочку
Delete source branch when merge request is accepted.
. - Ставьте галочку
Squash commits when merge request is accepted
# Когда мержить
- Проверьте, что у проекта нет метки
DRAFT:
илиWIP:
в Title. - Обратите внимание на блок
X/Y discussions resolved
- это сколько было замечаний и сколько из них отмечены галочкой✓
. Все диалоги должны быть разрешены (Resolved). - Перед сливанием ставьте галочку "Remove source branch". Если это ваша ветка, ставим
Squash commits
.
# Рефакторинг
- Планируйте рефакторинг через SOB.
- Убедитесь, что тесты покрывают код, который вы собираетесь менять.
- Не увлекайтесь. Сделайте план того, что будете менять и придерживайтесь его.
# Встраивание подпроектов (git subtree)
Использование Git Subtree предпочтительнее, чем Git Submodules, т.к. дает больше контроля за встроенными проектами и их обновлением. Инструкция основана на статьях:
- https://www.atlassian.com/git/tutorials/git-subtree (opens new window)
- https://medium.com/@v/git-subtrees-a-tutorial-6ff568381844 (opens new window)
# Добавление второго репозитория как substree
Добавляем новый репозиторий как remote upstream:
git remote add <remote_name> <git_url>
Убедитесь, что у вас все изменения закоммичены:
git status
Если нет, нужно закоммитить.
Подключаем subtree к папке:
git subtree add --prefix=<folder> <remote_namee> <git_branch>
Ветку git_branch
желательно всегда использовать master
.
# Push изменений у subtree
Делаем обычный commit:
git commit -a
Пушим изменения substree в исходный репозиторий:
git subtree push --prefix=<folder> <remote_name> <git_branch>
# Pull изменений subtree
Убедитесь, что все изменения закоммичены
git status
Подгржаем коммиты с внешнего репозитория:
git subtree pull --squash --prefix=<folder> <remote_name> <git_branch>