Bitbucket: конфликт в удаленном репо, не могу понять, как разрешить

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

Проблема, с которой я сталкиваюсь, заключается в том, что в Bitbucket говорится, что у меня есть конфликты слияния, но я понятия не имею, как их разрешить. Локально у меня нет конфликтов. Когда я захожу в Bitbucket, он говорит мне, что я на 2 коммита позади основного репо, поэтому я нажимаю синхронизацию. Он говорит, что есть конфликты слияния, и мне нужно их разрешить. Тогда я не вижу способа разрешить эти конфликты. Если я делаю запрос на рабочий сервер, он говорит, что есть конфликты, и мне нужно их разрешить, что я и делаю. Я использую nano (поскольку я НЕНАВИЖУ VIM), очищаю то, что мне нужно, и занимаюсь своими делами. Но все же разветвленное репо, похоже, все еще находится в конфликте. Я понятия не имею, что мне нужно сделать, чтобы разрешить эту ситуацию. Тем не менее, это ставит меня в тупик, потому что я не могу больше вносить изменения в форк, пока конфликты не будут разрешены.


person Siraris    schedule 08.01.2014    source источник
comment
У вас есть локальная копия каждого репозитория? Проще всего разрешать конфликты слияния локально, а затем выталкивать их оттуда.   -  person Chris    schedule 08.01.2014
comment
У меня есть локальная копия, да. Но я не вижу конфликтов в моем локальном репо. Как мне получить локальное представление конфликта слияния, чтобы я мог разрешить его и вернуть обратно?   -  person Siraris    schedule 08.01.2014
comment
Когда вы говорите, что разветвили репозиторий, это настоящая вилка (отдельный репозиторий) или ветка в основном репозитории? Если у вас несколько репозиториев, есть ли у вас локальная копия каждого из них?   -  person Chris    schedule 08.01.2014
comment
Это разветвленное репо. Итак, если у меня есть Master Repo, я затем разветвляю Client A Repo. Когда я пытаюсь синхронизировать клиент A внутри Bitbucket (также известный как синхронизация клиента A с Master Repo), он говорит, что есть конфликты слияния, но внутри битбакета, который я вижу, нет инструмента, который позволил бы мне разрешать конфликты.   -  person Siraris    schedule 08.01.2014


Ответы (1)


При работе с вилкой часто бывает полезно настроить основной репозиторий (ваш основной репозиторий) как удаленный, а также вилку (ваш репозиторий клиента А). Например, у вас, вероятно, уже есть origin, представляющий вилку.

Добавьте новый удаленный upstream для представления репозитория «Master»:

git remote add upstream [email protected]:user/master-repo.git
git fetch upstream

Теперь вы должны увидеть все соответствующие ветки. Например, если вы пытаетесь объединить ветку master, это будет актуально:

  • master (местный)
  • origin/master (Клиент А)
  • upstream/master (основной репозиторий)

Если вы визуализируете эти ветви с помощью gitk или git log --all --graph --decorate, вы, вероятно, сможете увидеть, откуда исходит конфликт. Скорее всего, вы захотите объединить изменения с обоих пультов в свою локальную ветку master:

git checkout master
git merge upstream/master  # (Merge changes from the "Master" repo)
# Fix any merge conflicts that may arise
git merge origin/master    # (Merge changes from the Client A repo)
# Fix any merge conflicts that may arise

Сделав это, вы сможете push четко выполнить origin:

git push origin master
person Chris    schedule 08.01.2014
comment
Не лучше ли было бы использовать перебазирование в восходящий поток и исправлять любые конфликты локально? - person Siraris; 09.01.2014
comment
@Siraris, фактическое решение будет зависеть от того, что у вас есть, и от того, каковы ваши принципы проекта. Слияние upstream/master, а затем origin/master в master — это всего лишь предложение. Вы можете захотеть rebase на upstream/master. Но настоятельно не рекомендуется rebase публиковать коммиты< /а>. Я бы избегал rebase, если это изменит что-то, что вы уже pushed. - person Chris; 09.01.2014
comment
Хорошо, перечитывая то, что вы написали, я думаю, что вы предлагаете то, что я хочу. Однако один вопрос: если я выполню git merge upstream/master, а затем git merge origin/master, сольет ли мой форк в мастер или только мастер в форк? Я хочу слить изменения с мастера, но не хочу помещать изменения с форка в мастер. - person Siraris; 09.01.2014
comment
Ничто в этом процессе не меняет того, что находится на upstream/master. Вы обновите master изменениями из upstream/master, затем origin/master, так что master будет содержать изменения как из вашего главного репозитория, так и из вашего форка. На этом этапе рекомендуется протестировать master и убедиться, что все работает так, как вы ожидаете. Затем вы нажмете на origin (ваш форк). Это приведет к тому, что ваша вилка будет обновлена ​​​​с изменениями от upstream/master. - person Chris; 09.01.2014
comment
Я полагаю, у вас есть отдельная локальная копия вашего главного репозитория для основных изменений? Это то, что вы должны использовать для обновления основного репозитория. - person Chris; 09.01.2014
comment
Ага! У меня есть репозитории для основного репо, а затем для детей-клиентов. Таким образом, любые изменения в Master будут проходить через локальную копию, и я просто объединяю изменения локально, используя ваш метод здесь. Я собираюсь попробовать это. Если это сработает... Я должен тебе моего первенца. - person Siraris; 09.01.2014
comment
О, еще одна вещь ... мне нужно получать восходящий поток каждый раз, когда я делаю слияние? Или я просто делаю заказ -> слияние -> слияние -> push? - person Siraris; 09.01.2014
comment
@Siraris, вам следует fetch каждый раз, когда вы хотите внести изменения с пульта. Это то, что обновляет ваши удаленные ссылки, например. upstream/master и origin/master. Без fetching ваша локальная копия не увидит новые коммиты. - person Chris; 09.01.2014