Как go вернуться к коммиту для исправления / патча, но не изменить ничего после?

Question

Я хочу go вернуться к старой версии кода и исправить только эту версию. Я не хочу, чтобы исправление было интегрировано в мастер, потому что любые версии, которые идут после той, которая нуждается в исправлении, не страдают от проблемы. Взяв в качестве примера приведенную ниже диаграмму, я хотел бы перейти к C3 , внести исправления, зафиксировать изменения, но not объединить эти изменения с любым из коммитов, которые ниже это ( C4 и C5 ).

Я думал о том, чтобы сделать

1. git checkout C3
2. git checkout -b patch
3. Применить исправление
4. git commit -m "Fix for an old version of the software"
5. git checkout C3
6. git merge patch

И оставьте его для последующей компиляции программного обеспечения. Не применять исправление к C4 или C5, потому что они не страдают от проблемы. Я бы так и сделал, но я не уверен, что это правильно. Отсюда вопрос: есть ли способ go вернуться к фиксации для исправления / патча, но не изменить что-либо после того, как исправление или исправление сделано? Или, другими словами, не объединять изменения во что-либо после фиксации интереса? Любые изменения, которые я делаю в C3 , чтобы исправить эту версию программного обеспечения, я хочу, чтобы они оставались там, а затем HEAD и master по-прежнему указывают на C5 после того, как C3 скомпилирован и выпущен с исправлением, так что другие могут продолжать работать на C5 , как будто ничего не произошло.

Answer 1

Физически невозможно изменить любой коммит. Поэтому то, что вы предлагаете здесь, легко и просто работает: commit C3 остается commit C3 навсегда. Однако вам потребуется выпустить исправленную версию version 1.0.4, потому что это коммит C3, который не изменился.

Вы не можете объединить свой коммит с исправлением ошибки в коммит C3, но нет нужно сделать это. Это ветвь . Вы нарисовали свои коммиты с более новыми в нижней части; Мне нравится рисовать мои с новыми коммитами вправо. Итак, я бы нарисовал вашу ситуацию следующим образом:

     tag:v1.0.4
         |
         v
C1--C2--C3
          \
           C4 <-- tag:v1.0.5
             \
              C5   <-- master (HEAD)
               ^
               |
           tag:v1.0.6

Когда вы go вернетесь к C3 и добавите там имя ветви (и сделаете его HEAD), вы получите:

     tag:v1.0.4
         |
         v
C1--C2--C3   <-- patch (HEAD)
          \
           C4 <-- tag:v1.0.5
             \
              C5   <-- master
               ^
               |
           tag:v1.0.6

Когда вы делаете новый коммит, родитель нового коммита C3, а имя patch указывает на новый коммит:

     tag:v1.0.4
         |
         v
C1--C2--C3--C7   <-- patch (HEAD)
          \
           C4 <-- tag:v1.0.5
             \
              C5   <-- master
               ^
               |
           tag:v1.0.6

Если с коммитом все в порядке C7 (Я пропустил здесь C6 по ошибке, но мог бы и оставить его - каждый коммит в любом случае имеет уникальный, но большой и некрасивый идентификатор ha sh, поэтому они просто заменяют собой идентификаторы реального коммита ha sh), вы можете пометить его как v1.0.4.1 или любой другой тег, который вы бы использовали, чтобы позволить людям обновиться с версии 1.0.4, не переходя до 1.0.5. (Возможно, вам следовало оставить какое-то пространство между 1.0.4 и 1.0.5. :-))

Если для версии 1.0.5 или 1.0.6 не требуется патч, делать больше нечего.