Почему & ldquo; Mine & rdquo; является их и & ldquo; их & rdquo; мой (конфликт git) [дубликат]
Я бы нарисовал два прямоугольника:
canvas.drawRect(new RectF(0, 110, 100, 290), paint);
canvas.drawRoundRect(new RectF(0, 100, 100, 200), 6, 6, paint);
Или что-то в этом роде, вы просто перекрываете их, чтобы верхние углы были круглыми. Предпочтительно вы должны написать метод для этого
5 ответов
Я подозреваю, что вы здесь смущены, потому что это принципиально сбивает с толку. Чтобы ухудшить ситуацию, весь наш / их материал переключает роли (становится обратным), когда вы делаете rebase.
В конечном счете, во время git merge, ветка «наш» относится к ветви, re слияние в :
git checkout merge-into-ours
, а ветка «их» относится к единственной ветви, которую вы объединяете:
git merge from-theirs
и здесь «наши» и «их» имеют какой-то смысл, так как даже если их «ваши», вероятно, ваши, «их» не тот, кем вы были на , когда вы бежали git merge.
Хотя использование фактического имени ветки может быть довольно круто, оно разваливается в более сложных случаях. Например, вместо вышесказанного вы можете сделать:
git checkout ours
git merge 1234567
, где вы объединяетесь с помощью raw commit-ID. Хуже того, вы даже можете это сделать:
git checkout 7777777 # detach HEAD
git merge 1234567 # do a test merge
, и в этом случае есть no имена ветвей!
Я думаю, что здесь немного помочь, но на самом деле, в синтаксисе gitrevisions вы можете ссылаться на отдельный путь в индексе по номеру, во время конфликта слияния
git show :1:README
git show :2:README
git show :3:README
Этап # 1 является общим предком из файлов, этап №2 является версией целевой ветви, а этап №3 - это версия, из которой вы сливаетесь.
Причина, по которой понятия «наш» и «их» меняются местами во время rebase, что rebase работает, выполняя серию вишневых кирков, в анонимную ветку (отдельный режим HEAD). Целевая ветка - анонимная ветвь, а ветка слияния - это ваш исходный (pre-rebase) ветвь: так что «--ours» означает, что анонимная rebase строится, а «- theirs» означает «наша ветка переустанавливается», .
Что касается записи gitattributes: она может иметь эффект: «наш» действительно означает «использовать этап №2» внутри. Но, как вы заметили, на данный момент это фактически не на месте, поэтому не должно иметь эффекта здесь ... ну, если вы не скопируете его в дерево работы до начала работы.
Также, кстати, это относится ко всем видам использования наших и их, но некоторые из них находятся на уровне всего файла (-s ours для стратегии слияния git checkout --ours во время конфликта слиянием), а некоторые из них находятся на (-X ours или -X theirs во время слияния -s recursive). Который, вероятно, не помогает с какой-либо путаницей.
Я никогда не придумывал лучшего имени для них. И: см. ответ VonC на другой вопрос, где git mergetool вводит еще больше имен для них, называя их «локальными» и «удаленными»!
-
1+1. О наших и их изменениях во время rebase см. Также: stackoverflow.com/a/2960751/6309 и stackoverflow.com/a/3052118/6309 – VonC 29 August 2014 в 23:01
-
2Две вещи "сливаются с" друг друга. Когда происходит слияние, обе стороны сливаются "в" друг друга. Я считаю, что было бы неправильно говорить, что одна из двух сторон «не сливается ни с чем». Если в списке нет имен ветвей (как вы указываете), тогда присутствуют имена фиксации (вы можете сказать «7777777's» и «1234567's» вместо «ours» и «theirs»). Я понимаю, что происходит во время перебазы, и я не считаю, что это путают. Я думаю, что "HEAD's & quot; и "входящие" будет работать лучше, чем «наш». и "их" потому что всегда есть «ГОЛОВА». (независимо от того, отсоединен он или нет). – CommaToast 29 August 2014 в 23:18
-
3Думаю, поскольку голова - это место разума, которое является источником идентичности, которое является источником «я», имеет смысл подумать о том, что HEAD указывает на то, что он «мой», («наш», так как я предполагаю, что я и HEAD делают два). Если не более того, это будет просто неплохое мнемоническое устройство. – CommaToast 29 August 2014 в 23:20
-
4Мне нравится эта мнемоника, придется повторить ее. Благодаря! – torek 29 August 2014 в 23:35
-
5Тем не менее, мне все же нравится делать физическую копию всего репо, прежде чем делать что-то вроде перезагрузки ...: D – CommaToast 17 November 2015 в 07:11
«Наш» в Git относится к исходной рабочей ветке, которая имеет авторитетную / каноническую часть истории git.
«Их» относится к версии, которая содержит работу, чтобы быть rebased (изменения будут воспроизведены в текущей ветке).
Возможно, это может быть заменено на людей, которые не знают, что выполнение переустановки (например, git rebase) на самом деле принимает ваш (т. е. их ), чтобы воспроизвести каноническую / основную историю, которая является нашей , потому что мы перестраиваем наши изменения как работу сторонних разработчиков
Документация для git-checkout была дополнительно уточнена в Git> = 2.5.1 в соответствии с f303016 commit :
--ours--theirsПри проверке путей из индекса проверьте этап # 2 ('ours') или # 3 ('theirs') для несвязанных путей.
Обратите внимание, что во время
git rebaseиgit pull --rebase, 'ours' и 'theirs' могут поменяться местами;--oursдает версию из ветви, на которую переупорядочиваются изменения, а--theirsдает версию из ветки, которая хранит вашу работу, которая перестраивается.Это связано с тем, что
rebaseиспользуется в рабочий процесс, который рассматривает историю на удаленном компьютере как общую каноническую, и рассматривает работу, проделанную в ветви, которую вы перестраиваете, в качестве сторонней работы, которая должна быть интегрирована, и вы временно принимаете на себя роль хранителя канонической истории во время rebase. Как хранитель канонической истории, вам нужно просмотреть историю с удаленного какours(т. Е. «Наша общая каноническая история»), а то, что вы делали на своей боковой ветви какtheirs(т. Е. «Работа одного автораДля
git-mergeэто объясняется следующим образом:ours
Этот параметр заставляет конфликтующие куски быть автоматически разрешенными, предпочитая нашу версию. Изменения от другого дерева, которые не конфликтуют с нашей стороной, отражаются на результате слияния. Для двоичного файла все содержимое взято с нашей стороны.
Это не следует путать с нашей стратегией слияния, которая даже не смотрит на то, что содержит другое дерево. Он отбрасывает все, что делал другое дерево, заявляя, что наша история содержит все, что в нем было.
их
Это противоположность нашей.
Далее, здесь объясняется, как их использовать:
Механизм слияния (команды
git mergeиgit pull) позволяет выбирать стратегии слияния бэкэнда с помощью опции-s. Некоторые стратегии также могут принимать свои собственные параметры, которые могут быть переданы с помощью аргументов-X<option>вgit mergeи / илиgit pull.
Поэтому иногда это может запутать , например:
git pull origin master, где-Xoursявляется нашей локальной,-Xtheirsявляется их (удаленной) ветвьюgit pull origin master -r, где-Xoursявляется их (удаленный),-Xtheirsявляется нашимИтак, второй пример противоположный первому, потому что мы перезагружаем нашу ветку поверх удаленного, поэтому наша отправная точка
Аналогично для стратегий
git merge(-X oursи-X theirs).
-
1этот ответ кажется устаревшим = & gt; & quot; git merge -ours & quot; не является допустимым вариантом – Alexander Mills 23 October 2016 в 05:21
-
2@AlexanderMills Ответ не говорил о
git merge, ноgit pullиgit checkoutв качестве примера. Если вы хотите использовать этот параметр сgit merge, вы должны использовать-X ours. Вы можете использовать синтаксис--oursдляgit checkout. Я уточнил ответ еще больше. – kenorb 23 October 2016 в 12:59
- Ours : Это ветка, в которой вы сейчас находитесь.
- Их : Это другая ветка, которая используется в вашем
Итак, если вы находитесь на ветке release / 2.5 , и вы объединяете в нее функцию / новые кнопки , затем содержание, найденное в release / 2.5 , относится к ours , и содержимое, найденное на feature / new-buttons , является тем, что относится к. Во время действия слияния это довольно прямолинейно.
Единственная проблема, с которой приходится сталкиваться большинству людей, - это случай переустановки. Если вы делаете повторную базу вместо обычного слияния, роли меняются местами. Как это? Ну, это вызвано исключительно тем, что происходит с перезагрузкой. Подумайте о том, что нужно выполнить эту операцию:
- Все ваши действия, сделанные вами после того, как ваше последнее нажатие переместилось на собственную ветвь, назовем ее BranchX .
- Вы проверяете головку своей текущей ветви, отбрасывая любые локальные изменения, которые у вас были, но таким образом извлекаете все изменения, которые другие нажали для этой ветви.
- Теперь каждая фиксация на BranchX выбрана вишня в порядке от старой до вашей текущей ветви.
- BranchX снова удаляется и, следовательно, никогда не появится в любой истории.
Конечно, это не совсем то, что происходит, но для меня это приятная модель ума. И если вы посмотрите на 2 и 3, вы поймете, почему роли теперь меняются местами. Начиная с 2, ваша текущая ветка теперь является ветвью с сервера без каких-либо изменений, поэтому это ours (ветка, в которой вы находитесь). Изменения, которые вы внесли, теперь находятся на другой ветке, которая не является вашей текущей ( BranchX ), и поэтому эти изменения (несмотря на сделанные вами изменения) являются их (другие ветвь, используемая в вашем действии).
Это означает, что если вы слились, и вы хотите, чтобы ваши изменения всегда побеждали, вы бы сказали git, чтобы всегда выбирать «наш», но если вы перебалансируете и хотите, чтобы все ваши изменения всегда выигрывайте, вы говорите git, чтобы всегда выбирать «их».
Я знаю, что на это был дан ответ, но эта проблема несколько раз путала меня. Я разместил небольшой справочный сайт, чтобы помочь мне запомнить: https://nitaym.github.io/ourstheirs/
Вот основные сведения:
Слияния:
$ git checkout master
$ git merge feature
Если вы хотите выбрать версию в master:
$ git checkout --ours codefile.js
Если вы хотите выбрать версию в feature:
$ git checkout --theirs codefile.js
Rebases:
$ git checkout feature
$ git rebase master
Если вы хотите выбрать версию в master:
$ git checkout --ours codefile.js
Если вы хотите выбрать версию в feature:
$ git checkout --theirs codefile.js
(конечно, для полных файлов)