Git ветки с совершенно другим контентом

Ответ 1

Я лично не буду хранить разные материалы в разных ветвях; в случае с документами и кодом я бы просто сделал myproject.git и myproject-docs.git(и подмодуль docs в код, если это было необходимо для процесса сборки).

С другой стороны, ничего плохого не произойдет, если вы это сделаете. Git не собирается рассказывать вам, что делать, поэтому вы можете сами принять решение о том, как вы хотите его использовать. Поэтому, чтобы ответить на ваш вопрос, это ни функция убийцы, ни что-то, что вас поразит, если вы не будете осторожны. Это просто, как кто-то хочет его использовать.

Ответ 2

Git отслеживает скоординированные изменения в (текстовых) файлах в проекте, поэтому он не знает и не заботится о слиянии ветвей или нет. Наличие независимых ветвей в репозитории Git аналогично наличию независимых проектов в репозитории Subversion, что является обычной практикой (из-за накладных расходов svn).

Поскольку структура данных Git сильно отличается от SVN, вы можете делать с ними разные вещи. В SVN ветвь признака несколько необычна, и ветвь функции, которая не часто сливается с туловищем, может быть "неприятным запахом", признаком того, что программист "потемнел" и создает код, который никогда не сможет быть интегрированы в проект. В Git ветвь функции - это совершенно безопасный и разумный рабочий процесс.

Таким образом, они могут использоваться по-разному, потому что Git не является SVN, хотя оба имеют репозитории и ветки и коммиты, и выполняют одну и ту же общую функцию управления версиями.

Поскольку у меня появилось больше опыта Git, то, что было странно, стало другим. Затем мне стало интересно, что я могу сделать с этим другим инструментом.

Ответ 3

Я бы сказал, что это больше похоже на ленивое обходное решение для того, что Git не может обрабатывать несколько проектов, хранящихся в одном хранилище. Вы можете это сделать, но нет способа вытащить только тот, который вам нужен.

Я говорю "ленивый", потому что было бы слишком сложно добавить эту функцию, когда сами разработчики Git обнаружили необходимость (для хранения документов). Поскольку они использовали эту странную ветку, их стимул для решения проблемы для всех остальных значительно уменьшился.

Ответ 4

Преимущество этого заключается в том, что можно вытащить только ветку docs, если это все, что вам интересно. Как и jrockway, вы можете сделать это, используя другой репозиторий и, если необходимо, подмодулировать, но с этой возможностью создать "голая" ветка, у вас есть возможность не делать этого.

Лично я все еще нахожусь на заборе об этом. Я понимаю, почему это может быть полезно, но я не полностью убежден, что это лучший способ пойти.

Ответ 5

Я думаю, это зависит от вашего проекта.

Git, очевидно, является проектом сообщества OSS, поэтому с документами в (том же) репозитории, чтобы каждый получил их, имеет смысл (для меня).

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

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

Ответ 6

Немного странно, когда вы привыкли к модели Subversion для представления дерева пользователям, но как только вы привыкнете к модели, она намного менее запутанна.

A git репозиторий - это просто дерево объектов, которое объясняет, как преобразовать каталог из одного состояния в другое. У этих объектов есть родитель. Некоторые объекты имеют двух (или более) родителей; сливается. У некоторых объектов нет родителя; начальная фиксация.

Как я понимаю, внутренне модель Subversion похожа на минус концепция того, откуда пришли слияния. Это только новые коммиты с удобной командой (svn merge) для получения патча различий между двумя другими коммитами.

Я использую эту функцию довольно часто для управления конфигурационными файлами, которые запускались из одного и того же каталога на разных хостах, например /etc/apache2. Это, как сказать, "это альтернативный старт этого материала, но он оставлен". Это позволяет мне сохранять состояние некоторых файлов, прежде чем я их перезапишу, но не беспокоиться о том, сливаются ли они правильно или вообще связаны с основной веткой.

В Subversion мне пришлось бы хранить эту резервную копию в каком-то несвязанном месте (где-то в zip файле) или в подкаталоге в репозитории. Кроме того, в subversion, если я удалю любую ссылку на эти файлы в текущем представлении дерева, становится очень сложно найти их снова.