Ответ 1
Насколько я могу судить, лучшее, что вы можете сделать, это то, что у вас уже есть с git stash. Мне тоже кажется странным, что слияние хочет иметь дело только с чистыми деревьями.
Как сделать git merge handle uncommitted изменениями в моем рабочем дереве?
Сотрудник и я оба сейчас работаем над ведущей отраслью. У меня есть код в моем рабочем дереве, который я не хочу фиксировать (отладочные операторы и т.п.). Теперь, если он вносит изменения в некоторые из тех же файлов, я не могу их слить:
$ git merge origin/master
Updating 1b8c5c6..eb44c23
error: Entry 'blah.java' not uptodate. Cannot merge.
Исходя из фона subversion, я привык к тому, что мое рабочее дерево автоматически объединяется, когда я извлекаю изменения из репозитория, и если есть конфликты, я разрешаю их вручную.
Самый быстрый способ, который я нашел для этого в git, это:
$ git stash
$ git merge origin/master
$ git stash pop
По существу, удаление моих незафиксированных изменений, выполнение слияния, а затем повторное применение изменений. Как я могу сообщить о слиянии для автоматического слияния моего рабочего дерева с изменениями, которые я пытаюсь втянуть?
Ответы
Ответ 2
Забудьте все, что вы узнали из подрывной деятельности.
Обязательно зафиксируйте перед внесением внешних изменений.
Представьте, что у вас было дерево, в основном работающее, возможно, не идеальное, но вы добиваетесь определенного прогресса. Затем вы переходите к слиянию и коду, который вы вводите, только что вызвавший хаос (сам был глючит, слишком много конфликтов для борьбы и т.д.). Было бы неплохо, если бы вы могли просто отменить это?
Если вы зафиксируете, вы можете. Если вы этого не сделаете, вы просто будете страдать.
Помните: то, что вы совершаете, не обязательно должно быть тем, что вы нажимаете, но то, что вы не совершаете, вы можете легко потерять.
Просто делайте безопасную и легкую вещь и совершайте раннее и часто совершайте.
Ответ 3
Вы не можете сообщить git merge о слиянии изменений в файлах, имеющих изменения в отношении вашего локального репозитория. Это защитит вас от потери ваших изменений в те моменты, когда слияние идет плохо.
С помощью подхода CVS и SVN к объединению, если вы не вручную копировали файлы перед обновлением, а затем скремблировали их при слиянии, вам нужно вручную переделать, чтобы вернуться в хорошее состояние.
Если вы либо совершаете свои изменения, либо ставите их перед выполнением слияния, все обратимо. Если слияние не идет хорошо, вы можете попробовать несколько способов заставить его работать и идти с тем, который работает лучше всего.
Если вы выполняете экспериментальные или отладочные изменения, вы можете использовать git rebase, чтобы переместить их после совершения транзакций через git merge, чтобы облегчить их устранение или избежать случайного нажатия их в репозиторий.
Обратите внимание, что использование git rebase на ветке, которую вы нажали в общий репозиторий, вызовет горе для всех, кто вытаскивает из этого репозитория.
Я предпочитаю использовать git stash в этих случаях, но я использую его только в том случае, если слияние меняет файлы, которые я редактировал и не фиксировал.