Как обрабатывать пул-запросы с помощью Git Extensions? - PullRequest
Новая
       3

Как обрабатывать пул-запросы с помощью Git Extensions?

8 голосов
/ 22 октября 2010

У меня есть публичный репозиторий на github , с которым у меня возникают проблемы при обработке запросов извлечения внутри GitExtensions.Я сделал 3 до сих пор, и я не думаю, что кто-то из них работал должным образом или работал там, где я хочу.

  1. 19-го я пытался справиться с тягойпросить, чтобы И Цзян создал.В GitExtensions я выполнял извлечение в GitExtensions, помещая в удаленный репозиторий, выбирая master в качестве удаленной ветви, и оставляя Merge удаленную ветку в текущей ветви по умолчанию.Я нажал Pull, и он завершился без ошибок.Было несколько вещей, которые я очистил, а затем я сделал толчок в GitExtensions.Он не заполнил сообщение о коммите, что удивило меня, поэтому я просто добавил URL-адрес коммита И Цзяна, потому что я не знал, что еще делать.В результате он оказался парой коммитов: один от И Цзяна как автора и один от меня как автора.

  2. Позже, 19-го, я попытался обработатьтянуть запрос, который создал Майкл.Так как мне показалось довольно ясным, что я первый ошибся, я искал другой вариант.Я выполнил первый набор команд, найденных здесь , и это, похоже, отлично сработало.Единственная проблема заключается в том, что я должен был сделать это через командную строку, а не в GitExtensions.

  3. Еще один запрос от Yi Jiang.Так как в прошлый раз казалось, что это делается с помощью GitBash, а не GitExtensions, я попробовал это снова.На этот раз, однако, он не завершится, потому что были конфликты слияния.Итак, я иду в GitExtensions и делаю слияние, потому что я знаю, что это позволит мне разрешить конфликты.Итак, я открываю диалог Слияние ветвей и выбираю Merge with и выбираю основную ветку И Цзяна, оставляя Keep a single branch line if possible (fast forward).Я разрешаю конфликты и делаю толчок.Он автоматически вставляет сообщение о коммите для меня.Это показывает как 4 записи, 3 от Yi Jiang как автора и 1 от меня как автора.Не кажется правильным.

Итак, мой вопрос, как я должен делать это правильно?У меня есть еще один запрос на удаление, и я хочу убедиться, что я правильно его обрабатываю.Очередь ветвлений говорит, что она не будет применяться корректно, поэтому я предвижу, что мне нужно сделать слияние.Я хочу убедиться, что я сливаюсь правильно и что ветви и коммиты приписываются людям, которые сделали работу.Если есть какие-то правки, которые нужно сделать, я должен сначала выполнить слияние / толчок, а затем выполнить 2-й коммит только с одной ветвью?Как это влияет на необходимость разрешения слияний?

Может ли кто-нибудь пройти точный процесс правильной обработки запроса на удаление в GitExtensions?

1 Ответ

6 голосов
/ 22 октября 2010

# 1 звучит нормально - во-первых, это коммит из ветки, которую вы вытащили, во-вторых, это коммит слияния (который фактически объединяет ветви). Фиксация слияния выполняется тем, кто делает git pull, но если вы посмотрите на файлы в git blame, вы увидите, что все строки обвинений относятся к первоначальному автору (коммиты слияния фактически не добавляют строки обвинений, если вы разрешать конфликты).

# 3 также кажется нормальным по той же причине - слияние добавляет один коммит, который фактически объединяет ветви.

Я полагаю, что с помощью # 2 запрос на получение данных там на самом деле был ускоренной перемоткой вперед, и, следовательно, фиксация слияния не требовалась, тогда как # 1 и # 3 не были перемотаны вперед (даже если слились без конфликтов, они не были прямыми потомками вашего HEAD).

По сути, я думаю, что вы на самом деле все делаете правильно, даже если это кажется немного странным. :)

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

о слияниях и "быстрой перемотке вперед"

Вы заметите, что мы видели фразу «перемотка вперед» несколько раз. Это особая операция, выполняемая «git merge», где ветвь может продвигаться по линейной последовательности. Это происходит всякий раз, когда вы извлекаете изменения, которые строятся прямо на том же коммите, что и у самого последнего. Другими словами, никогда не было дивергенций или одновременных коммитов, созданных параллельно в нескольких репозиториях. Если бы были параллельные коммиты, то «git merge» фактически ввел бы новый коммит слияния, чтобы связать два коммита вместе.

Когда происходит слияние без ускоренной перемотки вперед, всегда существует вероятность возникновения конфликта. В этом случае «git merge» оставит маркеры конфликта в файлах и даст вам указание разрешить конфликты. Когда вы закончите, вы создадите git commit -a, чтобы создать коммит слияния.

(с http://cworth.org/hgbook-git/tour/)

Редактировать

Я пошел и посмотрел на настоящий репозиторий на Github. Последние два извлечения (# 2 и # 3), кажется, работали должным образом и сделали то, что должны были быть сделаны - быстрая перемотка вперед в случае # 2 и слияние (с добавленной фиксацией слияния) в # 3.

Я не совсем уверен, что случилось с # 1 - как-то, кажется, часть изменений была помещена вами в отдельный коммит? Не мог бы сказать лучше, не имея возможности посмотреть, что на самом деле было сделано в то время. Возможно, вы зафиксировали изменения и зафиксировали их, не заметив?

...