Подтвердить что ты не робот

Рекомендации по репозиториям git в проектах с открытым исходным кодом

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

В некоторых ситуациях, с которыми я столкнулся, есть:

  • Я совершаю код, который позже принят в основной репозиторий. Когда я тяну из этого хранилища в будущем, моя фиксация дублируется в моем хранилище.
  • Я фиксирую код, который никогда не принимается в основной репозиторий. Когда я выйду из этого хранилища в будущем, эти два дерева расходятся, и это трудно.
  • Другой человек приходит и основывает свою работу на моем репозитории. Таким образом, я должен, если это вообще возможно, избежать изменения коммитов, которые я нажал, например, используя git rebase.
  • Я хочу отправить код в главный репозиторий. В идеале, мои изменения легко могут быть преобразованы в патчи (в идеале с использованием git format-patch), которые могут напрямую и чисто применяться к главному репозиторию.

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

  • Часто запускайте git rebase, чтобы мои изменения основывались на заголовке восходящего репозитория. Таким образом, я могу устранить дублированные коммиты, но часто приходится переписывать историю, вызывая проблемы для людей, желающих получить свою работу от моих.
  • Частое слияние изменений хранилища вверх по потоку в мой. Это работает нормально с моей стороны, но, похоже, не упрощает отправку моего кода в восходящий репозиторий.
  • Используйте некоторую комбинацию из них и, возможно, git вишневый выбор, чтобы все было в порядке.

Что сделали другие люди в этой ситуации? Я знаю, что моя ситуация аналогична взаимосвязи между различными вкладчиками ядра и основным хранилищем Linus, поэтому, надеюсь, есть хорошие способы справиться с этим. Я новичок в git, хотя и не освоил все его нюансы. Наконец, особенно из-за Гитуба, моя терминология может быть не совсем последовательной или правильной. Не стесняйтесь меня исправлять.

4b9b3361

Ответ 1

Некоторые советы, которые я узнал из аналогичной ситуации:

  • У вас есть ветвь удаленного отслеживания для работы автора восходящего потока.
  • Выбрасывайте изменения из этой ветки отслеживания в свою основную ветвь так часто.
  • Создайте новую ветку для каждой из тем, над которыми вы работаете. Эти ветки обычно должны быть локальными. Когда вы получаете изменения от восходящего потока к главному, переустановите свои ветки тем, чтобы отразить эти изменения.
  • Когда вы закончите работу над некоторыми темами, объединитесь в мастер. Таким образом, люди, которые производят работу от вас, не будут видеть слишком много переписанной истории, так как перезагрузка произошла в ваших локальных ветках темы.
  • Отправка изменений: ваша основная ветка будет в основном представлять собой ряд коммитов, некоторые из которых такие же, как и вверх по течению, остальные - ваши. Последний может быть отправлен как патчи, если вы хотите.

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