Несколько субдоменов с SSL под [закрытым] IIS

Потерпи меня немного, прежде чем я отвечу на вопрос в том виде, как он задан. Один из ранних ответов правильный, но есть маркировка и другие относительно незначительные (но потенциально запутанные) проблемы, поэтому я хочу начать с чертежей ветвей и меток ветвей. Кроме того, люди, пришедшие из других систем, или, может быть, просто новички в управлении ревизиями и git, часто думают о ветвях как о «линиях развития», а не как «следах истории» (git реализует их как последние, а не как первые, поэтому коммит не обязательно находится на какой-либо конкретной «линии развития»).

Во-первых, есть небольшая проблема с тем, как вы нарисовали свой график:

  *------*---*
Master        \
               *---*--*------*
               A       \
                        *-----*-----*
                        B         (HEAD)

Вот тот же самый график, но с метками, нарисованными по-разному, и добавлены еще некоторые стрелки (и я нумеруются узлы коммитов для использования ниже):

0 <- 1 <- 2         <-------------------- master
           \
            3 <- 4 <- 5 <- 6      <------ A
                       \
                        7 <- 8 <- 9   <-- HEAD=B

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

В частности, имя ветви , например, master, A или B, указывает на один конкретный коммит . В этом случае master указывает на фиксацию 2, A указывает на фиксацию 6 и B указывает на фиксацию 9. Первые несколько коммитов с 0 по 2 содержатся во всех трех ветвях; коммиты 3, 4 и 5 содержатся как в A, так и в B; коммит 6 содержится только внутри A; и коммиты с 7 по 9 содержатся только в B. (Кстати, несколько имен могут указывать на один и тот же коммит, и это нормально, когда вы создаете новую ветвь.)

Прежде чем мы продолжим, позвольте мне перерисовать график еще одним способом:

0
 \
  1
   \
    2     <-- master
     \
      3 - 4 - 5
              |\
              | 6   <-- A
               \
                7
                 \
                  8
                   \
                    9   <-- HEAD=B       

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

Когда вы перебазируете коммиты, вы фактически копируете эти коммиты.

Git никогда не может изменить какой-либо коммит.

Есть одно «истинное имя» для любого коммита (или даже любого объекта в репозитории git), которое является его SHA-1: эта строка из 40 шестнадцатеричных цифр, такая как 9f317ce..., который вы видите в git log, например. SHA-1 представляет собой криптографическую ^{1 sup> контрольную сумму содержимого объекта. Содержимое содержит информацию об авторе и коммиттере (имя и адрес электронной почты), метки времени, исходное дерево и список родительских коммитов. Родителем коммита №7 всегда является коммит №5. Если вы делаете в основном точную копию коммита # 7, но устанавливаете его родительский коммит # 2 вместо коммита # 5, вы получаете другой коммит с другим идентификатором. (У меня заканчиваются однозначные цифры - обычно я использую заглавные буквы для представления идентификаторов фиксации, но с ветвями с именами A и B я подумал, что это сбивает с толку. Поэтому я назову копию # 7, # 7a, ниже.)}

Что git rebase делает

Когда вы просите git перебазировать цепочку коммитов - например, коммиты # 7-8-9 выше - он имеет скопировать их , по крайней мере, если они собираются куда-то двигаться (если они не двигаются, они могут просто оставить оригиналы на месте). По умолчанию он копирует коммиты из проверенной в данный момент ветки, поэтому git rebase требуется только две дополнительные части информации:

• Какие коммиты следует скопировать?
• Где должен копирует землю? То есть, каков целевой родительский идентификатор для первого скопированного коммита? (Дополнительные коммиты просто указывают на первое скопированное, второе скопированное и т. Д.)

Когда вы запускаете git rebase , вы позволяете git вычислять обе части из одного фрагмента информации. , Когда вы используете --onto, вы получаете возможность рассказать git отдельно об обеих частях: вы все еще предоставляете upstream, но он не вычисляет цель из , он только вычисляет коммиты для копирования из . (Между прочим, я думаю, что не является хорошим именем, но это то, что использует rebase, и у меня нет ничего лучше, поэтому давайте придерживаться этого здесь. Rebase вызывает target , но Я думаю, что target - гораздо лучшее имя.)

Давайте сначала рассмотрим эти два варианта. Оба предполагают, что вы находитесь на ветке B в первую очередь:

1. git rebase master
2. git rebase --onto master A
[11127]

С первой командой аргументом для rebase является master. Со вторым это A.

Вот как git вычисляет, который выполняет копирование: он передает текущую ветвь в git rev-list , а также передает в git rev-list, но с использованием --not - или, точнее, с эквивалентом двухточечной нотации exclude..include. Это означает, что нам нужно знать, как работает git rev-list.

Хотя git rev-list чрезвычайно сложно - большинство команд git заканчивают тем, что используют его; это движок для git log, git bisect, rebase, filter-branch и т. д. - этот конкретный случай не слишком сложен: в двухточечной нотации rev-list перечислены все коммиты, достижимые справа. со стороны (включая этот коммит), исключая каждый коммит, достижимый с левой стороны.

В этом случае git rev-list HEAD находит все коммиты, достижимые из HEAD, то есть почти все коммиты: коммиты 0-5 и 7-9, а git rev-list master находит все коммиты, достижимые из master, который Фиксация # 0, 1 и 2. Вычитание 0-через-2 из 0-5,7-9 оставляет 3-5,7-9. Это кандидат обязуется скопировать, как указано в git rev-list master..HEAD.

Для нашей второй команды у нас есть A..HEAD вместо master..HEAD, поэтому коммиты для вычитания равны 0-6. Коммит № 6 не появляется в наборе HEAD, но это нормально: вычитая что-то, чего нет, оставляет его там. Таким образом, число получаемых кандидатов на копирование равно 7-9.

Это все еще оставляет нас с определением цели перебазирования, то есть, где должен быть скопирован коммит земли? Для второй команды ответом является «фиксация, определенная аргументом --onto». Поскольку мы сказали --onto master, это означает, что целью является коммит №2.

rebase # 1

git rebase master

Однако с помощью первой команды мы не указали цель напрямую, поэтому git использует фиксацию, идентифицированную . , которое мы дали, было master, которое указывает на коммит №2, поэтому целью является коммит №2.

Поэтому первая команда будет начинаться с копирования коммита # 3 с любыми минимальными изменениями, необходимыми для того, чтобы его родитель был коммитом № 2. Его родителем является уже коммит # 2. Ничего не должно меняться, поэтому ничего не меняется, и rebase просто повторно использует существующий коммит # 3. Затем он должен скопировать # 4, чтобы его родитель # 3, но родитель уже # 3, поэтому он просто повторно использует # 4. Точно так же # 5 это уже хорошо. Он полностью игнорирует # 6 (это не входит в набор коммитов для копирования); он проверяет # 7-9, но все они тоже хороши, так что вся перебазировка заканчивается просто повторным использованием всех оригинальных коммитов. В любом случае вы можете принудительно копировать копии с -f, но вы этого не сделали, поэтому весь этот перебаз в конечном итоге ничего не делает.

rebase # 2

git rebase --onto master A

Вторая команда rebase использовала --onto для выбора # 2 в качестве своей цели, но сказала git для копирования только что зафиксировала 7-9. Родителем коммита # 7 является коммит №5, поэтому эта копия действительно должна что-то делать. ^{2 sup> Таким образом, git делает новый коммит - давайте назовем это # ​​7a - который имеет коммит № 2 в качестве родителя. Перебазировка переходит к фиксации # 8: копии теперь требуется # 7a в качестве ее родителя. Наконец, rebase переходит к коммиту # 9, которому нужен # 8a в качестве родителя. Со всеми скопированными коммитами последнее, что делает rebase, это перемещает метку (помните, метки перемещаются и меняются!). Это дает график, подобный следующему:}

          7a - 8a - 9a       <-- HEAD=B
         /
0 - 1 - 2                    <-- master
         \
          3 - 4 - 5 - 6      <-- A
                    \
                     7 - 8 - 9   [abandoned]

Хорошо, но как насчет git rebase --onto master A B?

Это почти то же самое, что и git rebase --onto master A. Разница в том, что дополнительные B в конце. К счастью, эта разница очень проста: если вы дадите git rebase один дополнительный аргумент, сначала он запускает git checkout для этого аргумента. ^{3 sup>}

Ваши исходные команды

В своем первом наборе команд вы выполнили git rebase master, находясь на ветке B ]. Как отмечалось выше, это большой запрет: так как ничего не нужно перемещать, git вообще ничего не копирует (если вы не используете -f / --force, чего вы не делали). Затем вы проверили master и использовали git merge B, который - если это сказано ^{4 sup> - создает новый коммит с слиянием. Поэтому Ответ Дерика , по крайней мере, на тот момент, когда я его видел, является правильным: коммит слияния имеет двух родителей, один из которых является вершиной ветви B, и эта ветвь проходит через три коммиты, которые находятся на ветке A и, следовательно, некоторые из того, что на A, в конечном итоге объединяются в master.}

Со своей второй последовательностью команд вы сначала извлекли B (вы уже были на B, так что это было избыточно, но было частью git rebase). Затем вам пришлось перебазировать копию трех коммитов, получая последний график выше, с коммитами 7a, 8a и 9a. Затем вы проверили master и сделали коммит слияния с B (снова см. Сноску 4). Опять же, ответ Дерика правильный: единственное, чего не хватает, так это того, что исходные, оставленные коммиты не затянуты, и не так очевидно, что новые объединенные коммиты являются копиями.

---

^{1 sup> Это имеет значение только в том смысле, что чрезвычайно сложно нацелиться на конкретную контрольную сумму. То есть, если кто-то , которому вы доверяете, скажет вам: «Я доверяю коммиту с идентификатором 1234567 ...», для кого-то еще - кого-то, кому вы не так доверяете, почти невозможно придумать коммит, который имеет тот же идентификатор, но имеет другое содержимое. Вероятность того, что это произойдет случайно, составляет 1 к 2 160 sup>, что намного меньше вероятности того, что у вас случится сердечный приступ при ударе молнии при утоплении в цунами при похищении космическими инопланетянами. : -)}

^{2 sup> Фактическая копия сделана с использованием эквивалента git cherry-pick : git сравнивает дерево коммита с деревом его родителя, чтобы получить diff, затем применяет diff к дереву нового родителя.}

^{3 sup> Это на самом деле, на самом деле, в настоящий момент буквально верно: git rebase - это сценарий оболочки, который анализирует ваши параметры, а затем решает, какой тип внутренней перебазировки выполнить: неинтерактивный git-rebase--am или интерактивный git-rebase--interactive. После выяснения всех аргументов, если есть один оставшийся аргумент имени ветви, скрипт выполняет git checkout перед началом внутренней ребазировки.}

^{4 sup> Поскольку master указывает на коммит 2, а коммит 2 является прародителем коммита 9, он обычно не делает коммит слияния в конце концов, а вместо этого делает то, что Git называет перемотка вперед . Вы можете указать Git не выполнять эти перемотки вперед, используя git merge --no-ff. Некоторые интерфейсы, такие как веб-интерфейс GitHub и, возможно, некоторые графические интерфейсы, могут разделять различные виды операций, так что их «объединение» вызывает истинное слияние, подобное этому.}

При слиянии в ускоренном режиме последний граф для первого случая выглядит следующим образом:

0 <- 1 <- 2         [master used to be here]
           \
            3 <- 4 <- 5 <- 6      <------ A
                       \
                        7 <- 8 <- 9   <-- master, HEAD=B

В любом случае коммиты с 1 по 9 теперь находятся на обеих ветвях , master и B. Разница по сравнению с истинным слиянием заключается в том, что на графике вы можете увидеть историю, которая включает слияние.

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