Как создать git-ветку с пользовательским diff для master-ветки?

Question

Извините за смутное название вопроса, я не знаю, как его лучше сформулировать. В основном у меня есть ветка master с двумя коммитами c1 и c2:

    +-----> dummy1   +-----> dummy2
    |                |
    |                |
    |                |
    |                |
  c1+              c2+
   .                 .
   └── a.txt +       ├── a.txt
                     ├── b.txt +
                     ├── not-wanted.txt +
                     └── c.txt +

c1 добавил a.txt файл. c2 добавил еще три файла, как вы видите. Теперь я хочу иметь две фиктивные ветви, одну из c1 и другую из c2, чтобы, когда я делаю git diff dummy1..dummy2, я видел только файлы b.txt и c.txt в diff. Таким образом, полученный PR между dummy1<-dummy2 показывает только b.txt и c.txt, но не not-wanted.txt.

Возможно ли это?

Answer 1

Поскольку вы не хотите, чтобы not-wanted.txt отображался, похоже, вам нужно создать новый коммит после удаления not-wanted.txt.

Delete not-wanted.txt
git commit -m "c3"

Теперь создайте две ветвииз c1 и c3

git branch dummy-1 c1
git branch dummy-2 c3

Если вы также хотите, чтобы файл not-wanted.txt был сохранен в какой-либо ветке, вы можете создать ветку в c2:

git branch backup-branch c2

Answer 2

TL; DR: вам понадобятся некоторые новые коммиты.Вы не можете получить то, что вы хотите с вашими существующими коммитами.

Long

Git - это не ветки или файлы: Git - это всего лишь коммитов .Запросы Pull ² используют имена веток, но только для того, чтобы Git мог найти commits .

Другими словами, все всегда касается коммитов.Имена - имена ветвей, такие как master или develop, или имена тегов, такие как v2.1, или имена удаленного отслеживания, такие как origin/master, или даже запросы на извлечение GitHub - на самом деле просто идентифицируют один конкретный коммит ,Каждый коммит содержит файлы - фактически полный снимок всех файлов, а также метаданные, например, кто его сделал (имя пользователя и адрес электронной почты), когда (дата и время -штамп) и почему (сообщение журнала).

Тот факт, что существует более одного коммита в ветви или в запросе на получение, происходит потому, что каждый коммит записывает своего родителя коммит, по хэш-идентификатору.Каждый коммит имеет свой уникальный хэш-идентификатор, и каждый коммит ¹ говорит ... и, если вы хотите узнать, что стоит передо мной, посмотрите коммит XXXXXX , где Xs - это хэш-идентификатор предыдущего коммита.

Итак, в вашей настройке у вас есть серия коммитов на вашем мастере, которая либо заканчивается на c2, либо продолжается далее:

...--B--c1--c2--D--E--F--G   <--master

У кого-то еще может быть серия коммитов в их хранилище, заканчивающаяся на B.Если это так, вы можете сделать имя, которое будет указывать на c1, давая вам:

...--B--c1   <-- name1
          \
           c2--D--...--G   <-- master

Если вы сейчас отправляете запрос на извлечение кому-либо еще, используя name1, вы спрашиваете кого-то еще -чья цепочка коммитов оканчивается на B - скопировать ваш коммит c1 в их хранилище и установить какое-нибудь имя их , указав c1.

Вы также можете сделатьимя, указывающее на c2:

...--B--c1   <-- name1
          \
           c2   <-- name2
             \
              D--...--G   <-- master

и сделайте запрос на получение, используя ваш name2, который просит, чтобы кто-то включил и c1 и c2 в своихранилище и установите одно из их имен, чтобы указать c2.

Независимо от того, что вы делаете, вы всегда будете просить их - кем бы они ни были - взять их имя филиала, которое указывает на существующиеshared commit B, который уже есть в их хранилище, а также в вашем, и добавляет новые коммиты в конец их коммита B.Вы контролируете, какой конкретный коммит вы просите их использовать.Они будут принимать каждый коммит со своего конца - свою копию B - до этого нового коммита.Таким образом, вы можете сделать новый коммит, назовем его c3, который идет после c1, который вы помните по имени ветки name3:

           c3   <-- name3
          /
...--B--c1--c2--D--E--F--G   <--master

Этот коммит c3 содержит то содержимое, которое вылайк.Затем вы отправляете им запрос на выборку с просьбой установить их master (или любое другое имя ветви), чтобы вместо указания на общий коммит B они копировали коммиты c1 и c3в свой репозиторий и затем установите для их имени значение c3.

. Для этого:

$ git checkout -b name3 <hash-of-c1>
... make whatever changes you like, e.g., git cherry-pick -n <hash-of-c2>
... fix things up, git add files as needed ...
$ git commit

для создания нового коммита c3, к которому будет добавлено имя вашей ветви name3точка.Затем вы можете сделать запрос на получение, используя это имя name3 и новый c3 коммит.

---

¹ Как минимум один коммит в каждом непустом репозитории имеет no parent: это самый первый коммит, который не имеет предыдущего коммита, потому что не может.У некоторых коммитов есть два или, возможно, даже больше родителей: это коммиты merge .Большинство коммитов имеют только одного родителя.История Git - это коммиты, связанные друг с другом с использованием обратной цепочки, сформированной путем обратной работы с последним коммитом, найденным по какому-либо имени ветви, по одному коммиту за раз (или два илибольше при достижении слияния).

² PВсе запросы на самом деле не являются частью самого Git: это надстройки, предоставляемые такими местами, как GitHub и Bitbucket. Git предоставляет сами коммиты и методы - git fetch и git push - для получения и отправки коммитов между одноранговыми репозиториями. До GitHub люди клонировали репозиторий Linux, делали новые коммиты, а затем отправляли исправления по электронной почте для проверки и ревизии ... и на самом деле они все еще делают это.

Answer 3

Нет необходимости создавать отдельные ветви. Вы можете различать коммиты в вашей текущей ветке:

git diff c1 c2

Затем, при необходимости, используйте diff для создания патча: Как увидеть изменения между двумя коммитами без промежуточных коммитов?