Как мне обработать две отдельные, но очень похожие базы кода с помощью git / github?

Question

Каков наилучший метод для работы с двумя отдельными, но очень похожими базами кода в git и git-hub?

Справочная информация

У меня есть репозиторий git для небольшого проекта сценария оболочки,В нем всего 2 или 3 файла кода, и я часто работаю в одном файле.Хотя я изначально создал проект для достижения определенной цели, я пишу его, чтобы он был более полезным для других.Я пишу общую версию варианта использования, а затем изменяю ее, чтобы она соответствовала моей конкретной цели.В конкретной версии я мог бы изменять переменные, вводить пароль, переключать порядок части кода, извлекать цикл for ... что угодно.

Что я пробовал

Я пробовал два разных метода, и ни один из них не работал так оптимально, как я мог бы подумать:

1. Два отдельных репо
   • Проблема: код, измененный в одном, не может быть легко и выборочно объединенк другому
2. Две ветви в одном репо
   • Проблема: ветви должны в конечном итоге объединиться.Я не хочу когда-либо полностью объединять их вместе, но выборочно объединять части кода.
   • Проблема: я обнаружил, что при попытке использовать команды слияния между ветвями было очень легко запутаться относительно того, чтокод в какую ветку сливался.Я как-то слил код между двумя из них, который был совершенно непреднамеренным, и не было никаких указаний относительно неправильного слияния, пока я не просмотрел содержимое файлов в обеих ветвях

Я также видел Как объединить две отдельные - но похожие - кодовые базы в один представитель SVN? , что касается SVN.Мне трудно следовать, так как я не знаю SVN.Я думаю, что это другой вопрос, потому что он не пытается сделать одну версию этого кода общедоступной.

Варианты использования, которые я хочу решить

В частности, проблема обнаруживается, когда:

• Синхронизация комментариев - я готовлю свою специализированную версию и замечаю, что могу добавить пояснительный комментарий в конце строки.Я добавляю его, но комментарий теперь не в обобщенной версии.
• Вещи, которыми я не хочу делиться - я готовлю свою специализированную версию и добавляю пароль или изменяю порядок выполнения операций.Я НЕ ХОЧУ, чтобы эти изменения были перенесены в обобщенную версию.
• Один и тот же файл - два вышеупомянутых изменения часто находятся в одном файле, что затрудняет объединение данных.Существуют интерактивные слияния, но я не знаю, можно ли взаимодействовать в одном файле.
• Общие -> Специализированные - я или кто-то другой может обновить обобщенную версию, чтобы иметь новый контент или комментарии, которые будутПолезно также иметь в моей специализированной версии.Я хочу перенести их из общего -> специализированного, не вмешиваясь в другие различия кода в специализированной версии.

Git vs Github

В основном мой вопрос состоит в том, как это сделатьэто внутри границ мерзавца.Тем не менее, это может повлиять и на взаимодействие с github.Моя обобщенная версия на github.Специализированная версия НЕ должна быть на github.Я думаю , что мой метод ветвления, описанный выше, не давил обе ветки, если я был осторожен ... но я всегда был неуверен.В любом случае, решение должно предусматривать наличие одной версии, которая является общедоступной, и одной версии, которая хранится локально ... даже если она немного сложна или требует осторожности.

Answer 1

Это легко сделать двумя ветками.Я не уверен, почему вы говорите «код, измененный в одном, не может быть легко и выборочно объединен с другим», потому что объединение в Git довольно просто.

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

Другими словами, все в порядке ...

git checkout personal
git merge general

Этого вам никогда не следует делать ...

git checkout general
git merge personal

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

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

Лично я бы пошел с двумя ветками в одном репо.

Answer 2

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

Это действительно хорошая практика - всегда вносить общие изменения в общую ветку, а затем делать

git checkout personal
git merge general

Теперь вы можете с пользой использовать, кроме того, git stash; давайте рассмотрим сценарий, в котором вы обновляете специализированную версию и думаете об общем изменении:

1. Вы сохраняете текущие изменения в специализированной версии:

   git stash
   

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

2. Вы идете в общую ветку, чтобы внести общее изменение, о котором вы думали:

   git checkout general  # or master, or whatever name your general branch has
   

   Затем вы можете реализовать ваши общие изменения и зафиксировать их как обычно.

3. Прежде чем возобновить работу над специализированной версией, вы импортируете общее изменение:

   git checkout personal
   git merge general
   

   git достаточно умен, чтобы делать это красиво: в ваш код следует вносить только последние, как правило, полезные обновления.

4. Вы возобновляете свою работу в специализированной отрасли, импортируя свою незавершенную работу:

   git stash pop
   

Вот и все! Ключ заключается в том, чтобы использовать git stash, чтобы сохранить изменения в середине вашей работы, не создавая фиксацию только для этого, а затем применить назад ваши изменения с помощью git stash pop.

Answer 3

Чтобы не выдвигать вашу специализированную версию на github, установите push.default config на tracking (или upstream для git> = 1.7.4.2).Подробности смотрите в http://longair.net/blog/2011/02/27/an-asymmetry-between-git-pull-and-git-push/.

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

Answer 4

Использовать подмодули git .Если вы хотите сохранить отдельную ветвь подмодуля, сделайте ветвь в репо этого проекта и сохраните все изменения локально для этой ветки, и используйте только эту ветвь в проверке подмодуля.это то, что вам нужно сделать наполовину вручную.Git имеет отличную поддержку слияния, и если вы не будете держать эти две ветви слишком далеко друг от друга, вы сможете получить минимальное ручное вмешательство.GitHub (или любой другой хостинг-провайдер) на самом деле не имеет ничего общего с этим.Если вы хотите сохранить закрытую ветку, не передавайте ее в публичный репозиторий.Все просто.