Git: ведение множества веток тем на часто меняющейся основе - PullRequest
16 голосов
/ 23 февраля 2012

В моем повседневном рабочем процессе git у меня есть много веток тем, например:

              o--o--o (t2)
             /
         o--o (t1)
        /
 o--o--o (master)
        \
         o--o--o (t3)

Когда я получаю от апстрима,

              o--o--o (t2)
             /
         o--o (t1)
        /
 o--o--o--n--n--n (master)
        \
         o--o--o (t3)

Я хочу rebase все ветки моей темы поверх нового мастера:

                        o'--o'--o' (t2)
                       /
                  o'--o' (t1)
                 /
 o--o--o--n--n--n (master)
                 \
                  o'--o'--o' (t3)

В настоящее время я делаю это вручную, используя git rebase --onto.В этом сценарии весь процесс обновления будет выглядеть следующим образом:

$ git checkout master
$ git pull
$ git rebase master t1
$ git rebase --onto t1 t2~3 t2
$ git rebase master t3

При переходе между различными ветками темы и добавлении коммитов это становится еще более неприятным.

Зависимости между ветвями темы в моем случае - просто дерево-подобно: ни одна ветвь не зависит от более чем одной другой ветки.(Я должен в конечном итоге сделать апстрим зависимыми патчами в каком-то определенном порядке, поэтому я выбираю этот порядок априори.)

Существуют ли какие-либо инструменты, которые могут помочь мне управлять этим рабочим процессом?Я видел TopGit , но, похоже, он довольно сильно связан с рабочим процессом на основе электронной почты tg patch, который мне не подходит.

Ответы [ 2 ]

6 голосов
/ 28 февраля 2012

Почти тот же вопрос был задан в списке рассылки git: Перебазирование нескольких веток одновременно ... К связанному ответу прикреплен скрипт perl, который генерирует необходимые вам команды.

Если вы хотите, чтобы этот сценарий был быстрым и избегал его использования, также рассмотрите возможность использования git-new-workdir для настройки рабочей копии только для автоматической перебазировки.

Если вы решаете те же конфликтыснова и снова, рассмотрите возможность включения git rerere .

Сказав все это, вот альтернативный рецепт:

# Construct a placeholder commit that has all topics as parent.
HEADS="$(git for-each-ref refs/heads/\*)" &&
MAGIC_COMMIT=$(echo "Magic Octopus"$'\n\n'"$HEADS" |
  git commit-tree \
    $(git merge-base $(echo "$HEADS" | sed 's/ .*//' ))^{tree} \
    $(echo "$HEADS" | sed 's/ .*//;s/^/-p /')) &&
git update-ref refs/hidden/all $MAGIC_COMMIT

# Rebase the whole lot at once.
git rebase --preserve-merges master refs/hidden/all

# Resolve conflicts and all that jazz.

# Update topic refs from the rebased placeholder.
PARENT=
echo "$HEADS" |
while read HASH TYPE REF
do
  let ++PARENT
  git update-ref -m 'Mass rebase' "$REF" refs/hidden/all^$PARENT "$HASH"
done
0 голосов
/ 23 февраля 2012

Не перебазируйте.Начните свои функции с общей точки.В конечном итоге слияния - это гораздо меньше работы.

Вот что мы делаем:

http://dymitruk.com/blog/2012/02/05/branch-per-feature/

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...