Git Merge ветка «мастер» https://bitbucket.org/xxx/yyy

Мы пришли к git после многих лет использования SVN, и иногда, должен признать, это сбивает с толку. Возьмем следующий пример -

  • User1 вносит изменения в a.java и отправляет их на удаленный сервер.
  • User2 вносит изменения в b.java. Он не может пушить сразу (отклонение от SVN, но это нормально). Ему нужно сначала получить данные с удаленного сервера, а затем отправить свои изменения на удаленный сервер. Это будет показано как отдельная фиксация слияния и прекрасно объяснено в здесь, в самом stackoverflow
  • Теперь самое интересное. Если мы экстраполируем это на несколько файлов, существует вероятность конфликта с одним из файлов, измененных пользователем 2. На этот раз git не может выполнить автоматическую фиксацию. User2 должен будет разрешить конфликты, а затем зафиксировать это слияние.

Это сбивает с толку, поскольку пользователь, который не внес изменений в такое количество файлов, скептически отнесется к их фиксации как части этой фиксации слияния (особенно с фоном SVN). Если теперь этот пользователь просто зафиксирует файлы, для которых он разрешил конфликты, и отправит их на удаленный сервер, Git перестанет предоставлять последние версии файлов, которые он не отправил. Это создает ощущение, что я потерял свою работу в остальной части команды.

Мой вопрос после этой длинной истории: почему это так? Почему GIT не должен сохранять последние версии других файлов? Должен ли git знать, что пользователь не фиксирует все файлы, которые он принес на компьютер пользователя в рамках этого автоматического слияния? Может ли существовать механизм, с помощью которого мы можем избежать этой ошибки?


git git-pull git-merge
person Nikhil Gupta    schedule 13.03.2014    source источник

Ответы (1)


arrow_upward
2
arrow_downward

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

Если эти коммиты слияния представляют для вас проблему, вам следует подумать о смене рабочего процесса. Способ взаимодействия с git не высечен на камне, и существуют большие различия в установленных рабочих процессах. Например, проект PostgreSQL полностью работает с git без коммитов слияния. С другой стороны, существует рабочий процесс, который осмысленно использует коммиты слияния. Чтобы получить поведение, немного напоминающее рабочий процесс SVN, передайте --rebase в git pull, но перед этим внимательно прочитайте man git-rebase, чтобы понять последствия. В качестве альтернативы вы можете использовать git stash для извлечения удаленных изменений перед фиксацией, но любой из этих вариантов просто помещает шаг разрешения конфликта в другое место.

Чтобы изучить ваш последний вопрос: Git рассматривает рабочее дерево как снимок вашего проекта. Если бы новые файлы смешивались со старыми, у разных файлов были бы разные версии — концепция, чуждая git. Если вам нужна такая функция, вам нужно искать, например. CVS (без шуток). Здесь приходится идти на компромисс: любая система управления версиями должна принять решение: либо иметь возможность отслеживать перемещения файлов, либо отслеживать разные файлы в разных версиях. Гит выбрал первое.

person Helmut Grohne    schedule 13.03.2014