#git #version-control #branch #git-branch
Вопрос:
В команде, к которой я только что присоединился, у них есть репозиторий git, структурированный таким образом:
-----------------> Main project
|-----------> Sub-project1
|-----------> Sub-project2
Таким образом, разработка осуществляется в основной магистрали «Основной проект» (и краткосрочных ответвлениях). Ветви «Подпроект1» и «Подпроект2» содержат код, который не связан с тем, что находится в основной магистрали, т. е. файлы в этих ветвях там не существуют.
Является ли это разумным/распространенным способом использования git или любой системы контроля версий в целом?
Комментарии:
1. Нехорошо использовать филиалы для независимых проектов. Вместо этого рассмотрите возможность использования подмодулей?
2. Нет. Репозитории дешевы, почему бы не создать репо для каждого подпроекта?
3. Привет, не могли бы вы удалить тег «rcs», пожалуйста ? Это вопрос о git, а не о rcs (смущает, что rcs-это конкретная часть программного обеспечения, а не общее описание систем контроля версий).
Ответ №1:
Нет. Это не распространенный способ в git. Вообще говоря, главная ветвь (основная, если вам нравится новейшая номенклатура github) содержит код разработчика сверху. Другие ветви (то, что вы назвали «краткосрочными ветвями») должны быть созданы для применения исправлений/изменений/улучшений (огромный рефакторинг, если необходимо), начиная с кода, доступного в главной ветви. Таким образом, вы сможете объединить ветви поверх главной ветви с помощью запроса на вытягивание (и/или запросов на слияние, здесь, опять же, если вы используете gitlab и предпочитаете его номенклатуру). Это обычный способ работы в git.
Никто не может сказать, что вы не должны создавать ветви «Подпроект1» и «Подпроект2» для хранения файлов, не связанных с «Основным проектом». Но что, если по какой-то причине вам нужно использовать эти файлы в другом проекте, расположенном в другом репозитории git? Что делать, если «Подпроект1» содержит необходимый вам инструмент? Если вы загрузите все репо (оно может стать огромным… GBs), переключить ветку, вытащить файл? хорошо, git частичный клон, разреженная проверка и т. Д… может помочь, но не лучше ли избежать этой сложности, разработав лучшее репо с самого начала, чтобы все было в порядке?
Итак, после этой преамбулы я думаю, что в вашем случае хорошо подходит другое репозиторий git со своими собственными ветвями вместо ветвей «Подпроект1» и «Подпроект2». Если вам нужно в будущем интегрировать что-то, исходящее из «Подпроекта 1», в другой проект (включая «Основной проект»), вы можете использовать подмодули git. Их следует использовать осторожно, но они полезны во многих обстоятельствах.
Комментарии:
1. Вы точно описали, как я использую git, который, по-видимому, является стандартным, и спасибо вам за подтверждение моих сомнений относительно другого подхода.
Ответ №2:
Это, конечно, не обычно, разделение отдельных историй-одна из тех вещей, которые люди, изучающие Git, изучают, возможно, разумно, практично, чисто, но трудно указать на какие-либо непоправимые недостатки этого. Вы можете случайно клонировать и создавать рабочие деревья для отдельных ветвей в любом случае; вы можете извлекать и продвигать любые истории в любом случае, на самом деле в том, как они это делают, очень мало существенной разницы, это просто немного нечисто с точки зрения эстетики, ориентированной на Git. И если все эти ветви являются частью единого рабочего процесса разработки, что ж, да, одна выборка, и все это для вас. Поэтому я бы не назвал это неразумным, основываясь только на том, что вы здесь рассказали.