Работа над задачами. Связка кода в #Git и задач в трекере.
- Если планируется большая фича, которая +- долго не попадет в главную ветку, создается отдельная ветка `feature/{randomFeatureName}`.
- Когда берете очередную задачу в работу, изначально определяете родительскую ветку. Либо `develop`, либо `feature/{randomFeatureName}`.
- Для задачи создается отдельная ветка `feature/{issueNumber}`.
- После внесенных изменений создается коммит с префиксом `{issueNumber}: `.
- Затем все заливается в родительскую ветку через Pull Request.
Работа над задачами - багами.
Аналогично работе над задачами, описанной выше, с несколькими нюансами:
- Если задача вернулась от тестеров, по commit message можно найти изменения, которые были сделаны не верно.
- В случае нового бага, после того как он был локализован, можно найти исходную задачу, в рамках которой баг появился и кто был за нее ответственный.
Плюсы подхода
- Легкая навигация по коду в контексте задач из трекера.
- Доступ к истории изменений по конкретной задаче.
- Более точечные Пул Реквесты, которые легче отсматривать.
- Полная информация о задаче в контексте Пул Реквеста.
Минусы подхода
- Требуется больше времени для поддержания структуры.
- Больша работы по созданию\удалению веток, т.к. ветка будет нужна даже для небольшой задачи.
Для упрощения поддержки структуры Commit Message можно воспользоваться готовыми commit-message хуками, например
https://gist.github.com/dryaz/6e55f55ffad6aeb188032e9481f78a45Он позволит просто написать привычное human readable сообщение, и далее сам отформатирует его в нечто, вида
XX-1234: {Тут ваше сообщение}
Issue in tracker
https://{Тут адрес вашего таск трекера}/XX-1234