Git: как избежать повторяющихся коммитов с помощью sub-sub-sub Git -repos?

У меня есть много субрепозиториев, то есть одно большое зонтичное репо с меньшими репозиториями. Теперь, когда я делаю коммит в репозитории листьев, это автоматически означает, что я получаю изменения в его родителях. Если вы предполагаете, что структура представляет собой двоичное дерево, вы можете понять, что это нелепо — наличие глубокой структуры 5 git-repo может легко означать $ git commit -m 'did 1'; cd ..; git commit -m 'did 1 as mentioned'; ... git commit -m 'did 1 same as earlier'. Как я могу избежать такого повторяющегося совершения?

Пример 1: графический пример проблемы

X---------|
          |
Y---------A --------|
                    |
          B --------|<-----Pictures (graphic designers, animators--have repo)
                    |
          C --------|

Изменение в картинках изменит A, B, C, X и Y — раздутый коммит, 6 коммитов из-за одного изменения, плохое повторение! Теперь люди, работающие с картинками, могут быть совершенно другими людьми, чем люди, работающие с X, Y, A, B и C, что делает вещи более неясными.

Пример 2: практический пример для пробной версии с вложенными вложенными... -репозиториями

Пожалуйста, скопируйте этот практический пример здесь. Вы можете протестировать вещи там с 3-уровневыми -sub-repos.

Пока предлагается

  1. Основные подмодули в Git, подробнее здесь.

  2. Gitslave здесь.


git commit repeat
person hhh    schedule 09.04.2012    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Не создавайте репозитории внутри репозиториев. Это позволит избежать повторяющихся коммитов. Возможно решат и другие проблемы.

Если вы действительно считаете, что вам нужны репозитории внутри репозиториев, используйте подмодули.

person GoZoner    schedule 09.04.2012
comment
Как предложил @GoZoner, подмодули - это то, что вам нужно. Вы можете прочитать о них здесь: progit.org/book/ch6-6.html - person asm; 09.04.2012
comment
Где находится «детский каталог WWW» относительно «Hello»? - person GoZoner; 12.04.2012
comment
Как указал GoZoner, мы не знаем, что такое «WWW», но после настройки подмодулей ваша файловая структура должна быть идентична тому, что есть сейчас. Единственная разница будет заключаться в том, как вы совершаете действия. Теперь, когда я думаю об этом, вам все равно придется совершать несколько раз с подмодулями, вы просто будете фиксировать изменения подмодулей вместо реальных файлов. Я не думаю, что есть способ делать то, что вы хотите, без множественных коммитов всего. - person asm; 12.04.2012
comment
Вы спрашиваете, как превратить текущий подрепозиторий в подмодуль? - person GoZoner; 27.04.2012
comment
@GoZoner В настоящее время я rm репозиторий или перемещаю его в другое место, делаю глупую фиксацию, а затем добавляю вещь обратно, чтобы сделать подрепозиторий в подмодуль, один коммит агани, не уверен, правильно ли - получить один дополнительный коммит, плохо ? - person hhh; 14.05.2012

arrow_upward
0
arrow_downward

Возможно, ваш дизайн или структура плохи, возможно, причина в команде GoZoner "Don't create repositories within repositories.", но также возможно, что ваш проект достиг точки, требующей более мощных инструментов. Бывают случаи, когда базовых подмодулей недостаточно, а ваши репозитории слишком широки, тогда вам, вероятно, следует обратить внимание на -- GitSlave! Это инструмент рабочего процесса, в котором вы указываете свой суперрепозиторий, а затем подчиненные репозитории. Вместо повторяющихся коммитов вы используете gits -command -- manual здесь.

Похожие темы

person hhh    schedule 19.08.2012

arrow_upward
0
arrow_downward

Часто ли файлы в ваших репозиториях сопровождаются изменениями, связанными с другими файлами в других репозиториях? Если это так, несколько репозиториев не вам в друзья. Вы должны использовать несколько репозиториев только тогда, когда они полностью (или почти полностью) независимы друг от друга.

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

Репозиторий, являющийся подмодулем другого репозитория, означает, что он зависит от этого подмодуля. Связи зависимостей между подмодулями, вероятно, плохая идея, если API нестабилен, но если API стабилен, поэтому изменения в одном не будут напрямую влиять на другой (т. е. нет необходимости в изменении кода), тогда два подмодуля верхнего уровня могут зависят друг от друга.

Итак, я все время говорил о подмодулях, но существует альтернатива под названием «поддерево», если вы хотите проверить это, чтобы увидеть, что вы предпочитаете. Он находится в разделе contrib/ основного репозитория git, поэтому он не установлен по умолчанию. Также существует стратегия поддерева (глава ProGit, ссылка на которую содержится в комментарии)

person alternative    schedule 19.08.2012
comment
@hhh Если исходный код в репозитории развертывания не может измениться, зачем вам репозиторий? Кроме того, я не пробовал git-slave, но мне он не кажется слишком впечатляющим; похоже, это решение для уменьшения повторения, а не для управления самими подрепозиториями. Да, и git subtree и git merge -s subtree - это разные сущности. - person alternative; 19.08.2012
comment
@hhh Git предназначен для отслеживания исходного кода, а не материалов для развертывания (именно поэтому я действительно не очень люблю Heroku...). Похоже, вы используете git в качестве инструмента развертывания, хотя этого делать не следует. Например, вы можете просто повторно развернуть tarballs или что-то в этом роде, если хотите не давать разработчикам исходники для графических материалов. Как правило, репозиторий git содержит минимум, необходимый для сборки проекта (нет сгенерированных файлов, нет ./configure [при использовании autoconf]) , именно потому, что всегда проблематично обновлять эти сгенерированные файлы при коммитах и ​​регенерировать репозитории. - person alternative; 19.08.2012
comment
Не могли бы вы различить "git subtree" и "git merge -s subtree" в своем ответе? Git-subtree — это какой-то внешний модуль для Git, а имя "subtree" в "-s subtree" просто заполнитель? Кроме того, я надеюсь, что вы просмотрите эту тему здесь потому что я предлагаю gitslave, но git-subtree может быть лучшей альтернативой, без понятия, просто новое предложение. - person hhh; 19.08.2012
comment
@hhh Я уже добавил это в ответ, и subtree относится к git subtree, а -s subtree - это git merge -s subtree (или аналогичная команда, похожая на слияние, которая принимает -s и -Xopts) - person alternative; 19.08.2012
comment
Значит, это здесь не то, что вы предлагаете? Извините, я пока не могу найти, что вы подразумеваете под git-subtree? Это дополнение к git? Это здесь git-поддерево, которое вы предлагаете? Какой-то пример или сценарий, когда это можно было бы использовать? В этой книге здесь ничего не говорится об экспериментальной функции git-subtree? - person hhh; 19.08.2012
comment
@hhh Вторая ссылка. Но код находится в разделе contrib/ файла git.git. Кроме того, я не особо предлагаю это, а скорее говорю, что это там (iirc, это был проект GSoC в прошлом году или что-то в этом роде. Я помню, что серия патчей была в списках рассылки, поэтому у нее есть обзоры кода от Junio ​​и т. д.) - person alternative; 19.08.2012