Основная ветвь и «происхождение / мастер» разошлись, как «отклонить» ветки?
Это форвардная декларация класса 'foo'. Он позволяет объявлять указатели и ссылки на класс, но не использовать его (например, члены вызова или определить его размер), потому что он еще не определен! Это должно быть продолжено с полным нормальным объявлением (class foo { ... };).
Это полезно для таких вещей, как объявление двух классов, содержащих указатели друг на друга, которые иначе было бы невозможно настроить.
2 ответа
Вы можете просмотрите различия с помощью:
git log HEAD..origin/master
перед его извлечением (выборка + слияние) (см. также «Как заставить git всегда извлекать данные из определенной ветки?» )
Когда у вас есть сообщение вроде:
«Ваша ветка и 'origin / master' разошлись, # и имеют 1 и 1 разные коммиты, соответственно.»
проверьте, если вы необходимо обновить origin . Если origin актуален, то некоторые коммиты были перенесены в origin из другого репо, в то время как вы сделали свои локальные коммиты.
... o ---- o ---- A ---- B origin/master (upstream work)
\
C master (your work)
Вы основали коммит C на коммите A, потому что это была последняя работа, которую вы в то время получили из апстрима.
Однако, прежде чем вы попытались вернуться в исходную точку, кто-то еще нажал фиксацию B.
История разработки разошлась по разным направлениям.
Затем вы можете объединить или перебазировать. См. Pro Git: Git Branch - Rebasing для подробностей.
Merge
Используйте команду git merge:
$ git merge origin/master
Это указывает Git интегрировать изменения из origin / master в вашу работу и создать коммит слияния.
График истории теперь выглядит следующим образом:
... o ---- o ---- A ---- B origin/master (upstream work)
\ \
C ---- M master (your work)
Новое слияние, фиксация M, имеет двух родителей, каждый из которых представляет один путь развития, который привел к содержимому, хранящемуся в этой фиксации.
Обратите внимание, что история M теперь нелинейна.
Rebase
Используйте команду git rebase:
$ git rebase origin/master
Это указывает Git воспроизвести фиксацию C (вашу работу), как если бы вы основывали ее на фиксации B вместо A.
Пользователи CVS и Subversion обычно переустанавливают свои локальные изменения поверх основной работы, когда они обновляются перед фиксацией.
Git просто добавляет явное разделение между этапами фиксации и перебазирования.
График истории теперь выглядит следующим образом:
... o ---- o ---- A ---- B origin/master (upstream work)
\
C' master (your work)
Коммит C '- это новый коммит, созданный командой git rebase.
Он отличается от C двумя способами:
- Он имеет другую историю: B вместо A.
- Его содержание учитывает изменения как в B, так и в C; это то же самое, что и M из примера слияния.
Обратите внимание, что история C 'по-прежнему линейна.
Мы решили (на данный момент) разрешить только линейную историю в cmake.org/cmake.git .
Этот подход сохраняет рабочий процесс на основе CVS, который использовался ранее, и может облегчить переход.
Попытка отправить C 'в наш репозиторий будет работать (при условии, что у вас есть разрешения, и никто не отправил его, пока вы выполняли перебазирование).
Команда git pull предоставляет сокращенный способ получения данных из источника и переназначения локальной работы над ним:
$ git pull --rebase
Эта команда объединяет вышеупомянутые шаги выборки и перенастройки в одну команду.
Встреченный эта проблема, когда я создал ответвление на основе ответвления A на
git checkout -b a
и затем я установил вверх по течению ответвления к ответвлению источника B на
git branch -u origin/B
Затем, я получил сообщение об ошибке выше.
Один способ решить эту проблему для меня был,
- Удаляют ответвление
- , Создают новое ответвление b на
git checkout -b b origin/B