Git ветки с совершенно разным контентом

Question

Поскольку Git имеет возможность отслеживать (и поддерживать его в чистоте) ветви с совершенно отличным контентом друг от друга в одном и том же хранилище, некоторые проекты (например, сам Git) начали использовать его.

Например, Git использует одну ветвь для самого кода, сохраняя при этом свою документацию в отдельной ветке. Одно и то же репо, просто разные ветки.

Может быть, это я, происходящий из SVN, но меня смущает отсутствие в этих ветвях «ничего общего». Развитие / постановка / производство отраслей; те, кого я понимаю. Ветки за неполные функции; конечно, я тоже этим занимаюсь. Черт возьми, у тебя есть документация с одной веткой на язык. Но нет общих файлов?

Является ли это просто (возможно, недоиспользуемой и / или недооцененной) возможностью в Git, к которой все должны привыкнуть и привыкнуть, или, возможно, опасным злоупотреблением со стороны кого-то, кому лень не дифференцировать два аспекта одного и того же проекта? *

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

Answer 5

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

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

Answer 6

Это немного странно, когда вы привыкли к модели Subversion, представляющей дерево пользователям, но как только вы привыкнете к модели, это станет намного менее запутанным.

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

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

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

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