Перемещение файлов в разные папки с использованием git

Это было предложено в комментарии, но это стоит ответа. Вы не можете редактировать каталог прошлых коммитов, обычно в этой ситуации вы предпочитаете изменить каталог и зафиксировать изменение. если вы действительно не хотите делать это в прошлом коммите, который затем вам нужно будет вернуть к первому коммиту, который вы хотите изменить, и начните изменять его, повторяя все.

Чтобы вернуться к коммиту, вы можете сделать git reset --hard <commit sha1> или вместо sha1 использовать HEAD~3 для третьего коммита из текущего. Затем подтвердите ваши изменения.

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

git revert HEAD~3 сменить каталог. git commit -a -f "directory fix1"

git revert HEAD~2 изменить каталог. git commit -a -f "directory fix2"

git revert HEAD~1 изменить каталог. git commit -a -f "directory fix3"

Вы не можете изменить любой существующий коммит. Но вы можете остановить , используя существующие коммиты.

Поскольку коммиты сохраняют полное состояние всего (ну, в общем, все зафиксированные), вы также можете «вернуться назад во времени», проверив старый коммит.

Если вы присваиваете каждому коммиту уникальный идентификатор и выводите их в последовательности, вы получаете что-то вроде этого:

A <-B <-C <-D   <--master

То есть последний коммит, D, запоминает идентификатор его предыдущий - или родитель - коммит C. Между тем C помнит своего родителя, B, который помнит своего родителя A. (Если A является самым первым коммитом в репозитории, у него нет родителя, поскольку он не может иметь его. В противном случае A запоминает, какой коммит был до A.)

Способ Git находит это то, что имя master записывает идентификатор хэша последнего коммита . Так как это было D, master находит D. Поскольку D записывает идентификатор C, сам D находит C, который находит B и т. Д.

Итак, учитывая все это, предположим, что вы:

1. Проверьте коммит A. Теперь A является текущим коммитом, и у вас есть все файлы такими, какими они были, когда вы делали A. ​​

2. Выполните , скопировав все файлы из B, но затем переместите один из них. Затем вы делаете новый коммит, который точно так же, как B, за исключением того, что файл перемещен (и внутренняя сохраненная дата для нового улучшенного - B сделана «сейчас», а не «тогда»). «). Вы получите новый коммит, который мы можем назвать B':

   A--B--C--D
    \
     B'
   

   Родителем B' является A: стрелка, указывающая назад, которую Git использует для обратной работы от каждого коммита до тот, что был раньше, указывает на фиксацию A, так же как и B указывает на фиксацию A. Разница между B и B' заключается в том, что вы переместили файл (и, конечно, у B' другой хэш-идентификатор Git - наши буквы здесь означают реальные большие уродливые хеш-идентификаторы, которые Git компенсирует каждый новый коммит).

   Однако в этой диаграмме чего-то не хватает: какое имя указывает на B'? Ну, давайте пока не будем об этом беспокоиться. Вместо этого давайте перейдем к ...

3. Теперь скопируйте C в C', переименовывая один файл в процессе, как вы это делали при создании B'. Родителем для C' будет B':

   A--B--C--D
    \
     B'-C'
   

4. Повторите для D, чтобы сделать D':

   A--B--C--D
    \
     B'-C'-D'
   

5. Пусть Git запишет хэш-идентификатор D' в имя master. Это особенно хитрая часть: теперь у вас есть:

   A--B--C--D   [abandoned]
    \
     B'-C'-D'  <-- master (HEAD)
   

   То есть, теперь имя master идентифицирует этот новый и улучшенный D' вместо старого D.

Единственная проблема, связанная с выполнением всего этого, состоит в том, что, если у любого другого пользователя Git есть копия репозитория, в котором есть последовательность фиксации A-B-C-D. Они могут создавать свои собственные коммиты поверх D, а не поверх вашего нового D'. Этот тип процесса сделает их жизни трудными, если они не готовы к этому. Поэтому, если у вас есть кто-то еще, использующий клон этого репозитория, и у них есть эти три коммита, рассмотрите , а не , делающего что-либо из этого. Но если ни у кого больше нет цепочки B-C-D, вы можете заменить их новой и улучшенной цепочкой B'-C'-D'. Или, если все остальные участники этого проекта ожидают такого рода переписывания, вы все равно можете это сделать. (Если никто не вовлечен, легко увидеть, что из всех других вовлеченных людей никто не будет возражать.)

Хорошо, так, как мы можем добиться этого переписать?

Самый простой способ - использовать git rebase -i. Эта интерактивная перебазировка позволяет вам остановить и изменить то, что будет входить в каждый новый коммит, прежде чем он фактически сделает коммит. Вы просто находите фактический хеш-идентификатор коммита, который вы хотите сохранить - в этом случае, коммит A - и, находясь на ветке master, выполните:

git rebase -i <hash>

Это вызывает ваш любимый редактор - или, по крайней мере, тот, который вы сказали Git, ваш любимый, установив core.editor - для файла с тремя командами pick. Измените каждый на edit, сохраните файл инструкций и выйдите из редактора.

Теперь Git начнет делать B' поверх A, но затем остановится и позволит вам отредактировать коммит. Выполните:

git mv file1 sample/file1

(сначала создайте каталог sample, если необходимо), затем:

git commit --amend --no-edit

, чтобы установить B' в качестве желаемого результата, затем:

Это будет плохо закрепить B' на месте и начать процесс копирования C, затем остановиться, так что теперь вы git mv file2 sample/file2 и git commit --amend --no-edit и git rebase --continue перейдете к шагу копирования -D. Повторите, как и раньше.

После того, как обновленные коммиты все будут сделаны и на месте, git rebase сделает последний шаг, вернув имя ветви master, чтобы указать на D' вместо D.

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

Пока Git строит эту новую цепочку замены B'-C'-D', имя, которое находит , каждый из этих коммитов просто HEAD сам. При этом используется режим, который Git вызывает отсоединенный HEAD . Хотя это звучит страшно, это просто означает, что специальное имя HEAD, которое Git всегда требует, не привязано ни к какому имени ветви вообще.

Например, в середине перебазирования у вас есть:

A--B--C--D  <-- master
 \
  B'  <-- HEAD

По мере добавления новых коммитов вы получаете:

A--B--C--D  <-- master
 \
  B'-C'  <-- HEAD

и так далее. Когда в git rebase -i заканчиваются инструкции - pick, которые вы изменили на edit, - это инструкции, - перебазирование выполнено, и Git возвращает имя master на место, повторно присоединяя к нему HEAD и получить нам диаграмму, показанную в шаге 5.