Начать с нуля в мерзавце? - PullRequest
       29

Начать с нуля в мерзавце?

0 голосов
/ 22 августа 2011

Я работал над решением Visual Studio, которое содержит около 40 или 50 проектов.

Я добавил еще 10 проектов в файл .sln, но в то же время кто-то еще добавил проект в файл .sln.

Так эффективно был файл - V1, над которым два человека независимо работали над созданием двух отдельных V2.

Я считаю слияние изменений кошмаром. На машине, на которой я работаю, установлен BeyondCompare, и он показывает мне слияние трех столбцов. Я не мог понять это, поэтому я решил просто перезаписать свой локальный файл тем, что git считает удаленной версией. Но тогда у меня проблема с повторным добавлением новых проектов обратно.

Итак. Перед тем, как сделать 90-е нажатие + перебазирование / принятие, есть ли простой способ решить эту проблему? Мол, перезаписать текущую локальную копию всего, что находится на удаленной стороне. Затем повторно добавьте в мои недавно добавленные проекты. Тогда совершай. Сборка + тест. Затем нажмите. Может быть?

* edit: FWIW, на машине также установлен git черепахи, и сейчас все отображается с зелеными галочками ... так что это довольно хорошо, верно?

Ответы [ 3 ]

1 голос
/ 23 августа 2011

Во-первых, давайте вернем вас в известное состояние.Сделайте git reflog и найдите коммит, который находится на определенном этапе, прежде чем вы попытаетесь сделать все это вытягивание и перебазирование.Выполните git checkout -b my-feature <commit-id>, чтобы создать ветку с именем my-feature, которая указывает на этот коммит.Убедитесь, что он работает, как и ожидалось, без всех последних изменений с сервера.

Теперь сделайте так, чтобы ваша ветка master соответствовала тому, что находится на сервере, выполнив git branch -f master origin/master.

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

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

Чтобы изменить просто файл sln , чтобы он соответствовал тому, что находится на сервере, выполните:

git checkout master -- filename.sln
git commit -am "Reset solution file to match origin"

Затем добавьте свои проекты и зафиксируйте файл снова как обычно.Теперь вы хотите внести эти изменения в основную ветку.Do:

git rebase master
# resolve any merge conflicts, then git rebase --continue after each one
git checkout master
git merge my-feature
# test to make sure everything works
git push
1 голос
/ 22 августа 2011

Если вы просите Git / какой-либо другой инструмент узнать, что в удаленном файле sln есть проекты, добавьте их, а затем добавьте те, которые я добавил, - нет, это не должно быть вашим подходом.

Просто исправьте конфликты слияния так, чтобы все проекты, которые были добавлены на удаленном компьютере, и те, которые вы добавили, были там.

0 голосов
/ 22 августа 2011

Я в «такой же, но другой» ситуации. Я разложил проблему на две части. Одним из них является просто захватить то, что я могу, и поместить это в номинальную последовательность снимков / коммитов. Я мог бы определить несколько отдельных подпроектов и фаз, поэтому каждый из них получил свое собственное репо на этапе захвата. Затем я могу graft собрать их вместе и использовать git filter-branch, чтобы объединить все это в одну большую историю.

Для текущей работы я начинаю новое git-репо с подходящей точки «сейчас», а также продолжаю с установленными методами слияния , с дампами в git-репо до мы можем полностью объединить два процесса вместе. Некоторым людям потребуется некоторое убедительное и (само) управление, что означает, что мы не осмеливаемся отказаться от нынешней практики, пока новая не будет доказана, чтобы работать.

Требуется некоторое время, чтобы «понять» философию git и отказаться от старых укоренившихся, но неправильных методов.

...