Вы наверное не совсем понимаете логику работы гита, раз такой вопрос возник.
Репозиторий надо рассматривать как дерево состояний проекта. Каждый коммит это определённое состояние. Название ветки это лишь указатель на некоторое состояние.
создал локальную ветку задачи branchTaskName от локальной develop-ветки (предварительно ее обновив)
Точнее вы создали тематическую ветку не от другой ветки, а от конкретного состояния, на которое указывал в тот момент указатель
develop в распакованной (
checkout) в рабочий каталог ветке.
Нужно ли мне обновлять свою ветку задачи branchTaskName свежими изменениями?
Моё мнение — нужно. Ведь ваша задача состоит не в создании сферических файлов в вакууме, а в изменении файлов проекта. Причём изменений относительно уже устаревшего состояния. Желательно чтобы ваша работа опиралась на актуальный проект, а не на старую версию.
Как правильно обновить ветку задачи branchTaskName чтобы не было проблем при отправке своей ветки в удаленный репозиторий?
Тут тоже странное утверждение. У вас неоткуда взяться проблемам при отправке (
push) изменений во внешний репозиторий. Проблемы могут возникнуть уже после, когда вашу ветку будут интегрировать (
merge) с основной веткой (
develop). Чтобы избежать этих проблем мы заранее предпринимаем определённые действия.
Способов собственно два:
1) Мы забираем новое состояние
develop в свою тематическую ветку через коммит слияния. И для этого вовсе не обязательно переключаться в локальную
develop, обновлять её (
pull) а затем возвращаться к себе чтобы сделать
git merge develop. Это бессмысленные манипуляции. Достаточно просто скачать к себе в локальный репозиторий обновления внешнего репозитория
git fetch (Лайвхак: эту операцию можно автоматизировать. Настройте автоматическое выполнение fetch по расписанию, и у вас всегда будет под рукой доступ к актуальному проекту). Затем сделайте
git merge origin/develop. Указатель
origin/develop это и есть ссылка на состояние проекта на момент последнего скачивания (
fetch). В принципе эти два шага эквивалентны одной команде
git pull origin develop — внутри делается всё то же самое.
2) Второй способ — пересадить вашу ветку на новое актуальное состояние проекта (
rebase). Выглядеть будет так, если бы вы начали работать над фичей вот только что, и тут точно не возникнет конфликтов, так как база ветки актуальная. Это делается тоже в два шага. Сначала убедимся что у нас всё актуально
git fetch, затем собственно пересадим ветку на актуальное состояние
git rebase develop. Последний вариант мне нравится тем, что история не засоряется коммитами слияния. Но тут предполагается, что тематическая ветка принадлежит только вам и никто больше в ней не работает. Так как после пересадки её придётся удалять из внешнего репозитория и создавать там заново через
git push --force. Если работа над фичей ведётся совместно с коллегами, то такой рабочий процесс не очень подойдёт.
Если вы не коммитите напрямую в
master и в
develop, то держать их у себя локально (делать
checkout в рабочий каталог) тоже нет смысла. Вы всегда можете начать новую тематическую ветку от актуального состояния, на которое ссылаются
origin/master или
origin/develop. Так вы не наступите на грабли, когда люди забывают переключиться из мастера и начинают коммитить туда. Нет мастера — нет проблем.
