2014-12-02 2 views
1

У меня вопрос о нестандартной стратегии ветвления git.Должен ли я использовать ветви Git для хранения несвязанного кода?

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

Некоторые другие требования

  • ветви никогда не должны сливаться до мастера. Но может быть mergable друг с другом, по некоторому именованию, как: Foo-файлы-мастер> Foo-файлы-bobswork

  • Я определенно не хочу отдельные операций РЕПО, так как в некоторых случаях мы говорим о только 1 или 2 файла, которые концептуально связаны, недостаточно, чтобы оправдать накладные расходы администратора отдельного репо.

  • Я колеблюсь, чтобы поместить все каталоги в одну ветку, потому что я не хочу клонировать все файлы, когда меня интересуют только две тысячи.

Возможно ли это? Это укусит меня в будущем?

Я искал и искал любую информацию об этом подходе и не нашел многого. Я нашел «orphan branches», который выглядит релевантным. Я собираюсь проверить это. Но игнорируя эту функцию за минуту, есть ли недостаток, чтобы иметь кучу ветвей, вытекающих из пустого мастера, каждый с совершенно другой файловой структурой?

+0

Эта идея выглядит странно и неожиданно – zerkms

+0

почему просто не начать новый проект, а не .. – Steve

+0

Да. Я знаю, что это довольно левая область. Я никогда не видел этого раньше, но не могу сформулировать, почему это плохая идея, кроме как «плохо пахнет» И я не хочу отдельный проект или репо только для 2-х файлов. – Jeffrey

ответ

3

Как вы упомянули, вы можете сделать это с сиротскими ветвями.

git checkout --orphan script-branch 
git reset --hard 
touch my-script.sh 
git add my-script.sh 
git commit -m 'Script commit' 

Теперь, если вы делаете git log, вы увидите только «Сценарий фиксации» в истории.

Там нет ничего плохого в таком подходе, но есть некоторые плюсы и минусы:

Плюсы:

  • Низкие накладные расходы: Ваши новые отрасли легко доступны всем, кто уже имеет доступ к вашему репо. Все, что вам нужно сделать, это проверить филиал, и вы готовы к работе.

  • Разделение: Поскольку ваши скрипты находятся в отдельной ветке, их можно поддерживать отдельно и иметь свою собственную отдельную историю git.

Минусы:

  • Необычная организация: Как правило, люди ожидают, что ветви будет модифицированная версия мастер-ветви. Вам нужно будет уточнить вашу схему для других разработчиков.

  • Недоступно для обоих одновременно: Вы не сможете получить доступ к своим скриптам, пока у вас есть мастер, и наоборот. Вы можете решить это, дважды клонируя свое репо, но это может усложнить ситуацию.

  • Heavy clone: Вы упомянули, что отдельная ветка спасет вас от клонирования всего репозитория, но вы все равно это сделаете. Если вы обычно запускаете клонировать, git будет клонировать каждую ветку, включая основную ветвь, независимо от того, какая ветка вы проверили. Вы можете использовать флаг --single-branch только для клонирования одной ветви, но это несколько свести на нет утилиту с ветвью в том же репо.

Альтернативы:

  • Включите скрипты в каталоге в вашей главной ветви. Да, это означает, что вам нужно клонировать весь репозиторий, чтобы получить скрипты. Но если сценарии связаны с кодом в вашей основной ветке, это самое простое и наиболее стандартное решение.

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

+0

Благодарим вас за такой хорошо написанный ответ. – Jeffrey

Смежные вопросы