Как работать с локальной веткой git, используя pull для обновления, но без push

Я работаю над локальной копией большого проекта на github. Большинство изменений, которые я вношу, являются модификациями для адаптации приложения к конкретному варианту использования, поэтому они не будут приняты сторонним разработчиком. Я пытаюсь выяснить, как я могу регулярно обновлять локальную ветвь с изменениями, внесенными в основную ветку, но без внесенных изменений. Например, я мог бы использовать:

git checkout my_branch git merge master

Затем нажмите mybranch на отдельный мастер проекта на github

Если это рекомендуемый способ иметь собственную копию проекта git с регулярными обновлениями из главного проекта?

2 голоса | спросил Don Smythe 3 FebruaryEurope/MoscowbFri, 03 Feb 2017 08:16:04 +0300000000amFri, 03 Feb 2017 08:16:04 +030017 2017, 08:16:04

2 ответа


5

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

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

Если вам нужно сохранить текущий рабочий процесс, лучше остановить основной ветвь от отслеживания любой ветки вверх и обработать все слияния вручную - так эффективно команды, которые вы предлагаете. A git pull upstream master почти совпадает с git fetch upstream; git merge upstream/master , Выполнение слияния вручную даст вам больше контроля. Слияние вместо перезагрузки также снижает вашу рабочую нагрузку в долгосрочной перспективе.

Однако Git не является подходящим инструментом для управления различными модификациями базы кода. Термин «контроль версий» здесь немного вводит в заблуждение. Это не потому, что Git - плохой инструмент, а потому, что это сложная проблема. Эта проблема становится намного проще, если исходная база кода достаточно конфигурируется, поэтому вам не нужно редактировать код, чтобы реализовать свои изменения - в ООП говорят, что он должен соблюдать принцип open /closed .

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

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

ответил amon 3 FebruaryEurope/MoscowbFri, 03 Feb 2017 12:46:25 +0300000000pmFri, 03 Feb 2017 12:46:25 +030017 2017, 12:46:25
1

Вы могли

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

    git stash && git pull origin master && git stash apply. 
    
  • Сделайте git pull --rebase вместо обычного слияния на основе слияния. Бабас найдет первого общего предка между удаленной главной ветвью и локальными коммитами, применит удаленные коммиты, а затем применит локальные коммиты поверх них.

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

ответил Akshat Mahajan 3 FebruaryEurope/MoscowbFri, 03 Feb 2017 09:58:31 +0300000000amFri, 03 Feb 2017 09:58:31 +030017 2017, 09:58:31

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132