Мастер слияния Git в ветвь объектов

допустим, у нас есть следующая ситуация в git:

  1. созданный репозиторий:

    mkdir GitTest2
cd GitTest2
git init

  2. некоторые изменения в Мастере происходят и совершаются.

    echo "On Master" > file
git commit -a -m "Initial commit"

  3. Feature1 разветвленный Мастер и некоторая работа сделана:

    git branch feature1
git checkout feature1
echo "Feature1" > featureFile
git commit -a -m "Commit for feature1"

  4. между тем, ошибка обнаружена в мастер-коде и исправление ветви установлено,

    git checkout master
git branch hotfix1
git checkout hotfix1

  5. ошибка исправлена в ветке исправления и объединена обратно в master (возможно, после запроса/проверки кода):

    echo "Bugfix" > bugfixFile
git commit -a -m "Bugfix Commit"
git checkout master
git merge --no-ff hotfix1

  6. разработка на feature1 продолжается:

    git checkout feature1

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

Я не могу сделать git merge master --ff-only: "fatal: невозможно перемотать вперед, прерывание.- но я не уверен, что это помогло мне.

622
git

5 ответов

вы должны иметь возможность перебазировать свою ветку на master:

git checkout feature1
git rebase master

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

git rebase --skip

при выполнении git log в вашей ветви функций вы увидите, что фиксация исправления появляется только один раз, а в master доля.

для более подробного обсуждения взгляните на документы git book на git rebase (https://git-scm.com/docs/git-rebase), которые охватывают этот точный случай использования.

363

как слияние ветки master в ветку? Легко:

git checkout feature1
git merge master

нет смысла заставлять быстрое слияние вперед здесь, так как это невозможно сделать. Вы совершили в отдельную ветку и в ветку master. Перемотка вперед теперь невозможна.

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

Итак, что вы сделали правильно в своем рабочем процессе? У вас есть две ветви для работы, ваша ветвь feature1 в основном является ветвью "разработка" в модели gitflow.

вы создали ветвь исправления из master и объединили ее обратно. А теперь вы застряли.

модель gitflow просит вас объединить исправление также с ветвью devel, которая в вашем случае является "feature1".

Так настоящим ответом было бы:--3--> 

git checkout feature1
git merge --no-ff hotfix1

это добавляет все изменения, внесенные внутри исправления в ветку компонента, но только эти изменения. Они могут конфликтовать с другими изменениями разработки в ветви, но они не будут конфликтовать с главной ветвью, если вы в конечном итоге объедините ветвь компонента обратно в master.

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

757

на основе в этой статье вы должны:

  • создать новую ветку, которая основана на новой версии master
  • объедините свою старую ветвь функции в новую
  • разрешить конфликт на новой ветви функции

таким образом, ваша история остается ясной, потому что вам не нужны обратные слияния. И вам не нужно быть таким супер осторожным, так как вам не нужна git rebase

45

ответ зими описывает этот процесс в целом. Вот конкретика:

1) Создайте и переключитесь на новую ветку. Убедитесь, что новая ветвь основана на master таким образом, он будет включать последние исправления.

git checkout master
git branch feature1_new
git checkout feature1_new

# Or, combined into one command:
git checkout -b feature1_new master

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

git merge feature1

3) на новой ветви, разрешите все конфликты между вашей функцией и главной ветвью.

готово! Теперь используйте новую ветку, чтобы продолжить разработку функции.

12

вы могли бы сделать "вишневый выбор", чтобы вытащить точно commit(s), которые вам нужны в вашей ветви функций.

сделать git checkout hotfix1 чтобы попасть на ветку hotfix1. Тогда сделайте git log чтобы получить хэш SHA1 (большая последовательность случайных букв и чисел, однозначно идентифицирующих фиксацию) данной фиксации. Скопировать (или первые 10 символов).

затем, git checkout feature1 вернуться обратно на свою ветку.

затем, git cherry-pick <the SHA1 hash that you just copied>

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

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

8