Visual Studio rebase в git rebase - PullRequest
Новая
       30

Visual Studio rebase в git rebase

0 голосов
/ 23 мая 2019

Мы обнаруживаем, что мы получаем разные результаты, когда мы делаем ребаз, в отличие от Visual Studio (2019, Enterprise). Обратите внимание, что мы новичок в Git в целом

У нас есть ветка, которая называется (например) SomeFeature, а затем у нас работают люди, которые имеют свои собственные ветки:

  • SomeFeature_mike
  • SomeFeature_tony

Майк работает над SomeFeature_mike, вносит изменения, выполняет запрос на извлечение и переводит свою работу в SomeFeature. Тони теперь хочет отменить SomeFeature, чтобы он получил изменения Майка

Используя Visual Studio, мы иногда получаем ошибки слияния, но мы не уверены, почему. Если вместо этого мы сделаем это 

git checkout SomeFeature_tony
git rebase origin/SomeFeature

Тогда, кажется, работает

Подозрение в том, что после перебазирования и синхронизации нам не пришлось принудительно толкать ветку SomeFeature_tony, однако это не отвечает на основной вопрос, почему Visual Studio делает что-то отличное от git?

Ответы [ 2 ]

0 голосов
/ 24 мая 2019

В моем познании, я не думаю, что он отличается от опции «rebase» в Visual Studio и «git rebase». Но «слияние» отличается от «rebase».

Когда вы объединяете SomeFeature_tony с SomeFeature, он объединяет ветвь SomeFeature с вашим текущим коммитом в SomeFeature_tony и формирует новый коммит. Как показано на следующем рисунке: введите описание изображения здесь

Когда вы перебазируете, он сделает коммит SomeFeature_tony за SomeFeature. Так же, как на следующем рисунке: введите описание изображения здесь

Когда вы объединяете одну ветку в другую, изменения в файлах от коммитов в одной ветке могут конфликтовать с изменениями другой. Вы можете разрешить это так же, как вы разрешаете конфликты слияния в Visual Studio. Также вы можете сделать 'git add' для создания объединенных изменений, затем продолжите ребазирование с помощью 'git rebase --continue'.

Надеюсь, что эта помощь и хорошего дня :) 1015 *

0 голосов
/ 23 мая 2019

Выполнение «git rebase» перед выполнением «git merge» не совсем похоже на непосредственное «git merge».Особенно, если вы сливаетесь с ускоренной перемоткой вперед (это сделает вашу ветку слияния [master] чистой и прямой :)). 

a-b-c-d [master]
  \x-y-z [feature]

прямое слияние 

a-b-c-d--m   [master]
  \x-y-z/    [feature]

rebase + merge 

1) rebase
    a-b-c-d [master]
           \x-y-z [feature]
2) merge
    a-b-c-d-x-y-z [master & feature]

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

Я бы порекомендовал это последнее решение, так как оно позволяет после повторной проверки проверить, как это будет после слияния.

Я предлагаю вампрочитайте https://www.atlassian.com/git/tutorials/comparing-workflows

Так что даже с вашей IDE перебазируйте перед объединением, чтобы получить тот же результат, что и ваша строка cmd.Обратите внимание, что в вашей IDE может быть множество параметров, которые могут повлиять на команды git.

...