Безопасно ли "git pull", когда мое рабочее дерево и / или индекс загрязнены?

Question

Скажем, у меня есть git-репо, рабочее дерево и / или индекс которого "грязный" (т. Е. У меня есть локальные модификации, которые еще не были зафиксированы или спрятаны), и я испытываю желание сделать "git pull" без первой фиксации или копить. (В качестве альтернативы, скажем, я представляю нового члена команды для git и они испытывают искушение запустить "git pull", когда их локальное репо "грязное".) Мне интересно Насколько это безопасно в этом случае сделать «git pull». Если это небезопасно, что может случиться хуже всего? Имеет ли значение, что я получаю информацию из надежного или ненадежного источника?

Мое расследование до сих пор наводит на мысль о том, что вопрос о том, что я предполагал, был бы довольно простым вопросом.

Начнем с того, что man-страница git-stash звучит так, как будто git pull довольно безопасен, и прервет работу, если что-то может пойти не так:

   Pulling into a dirty tree
       When you are in the middle of something, you learn that there are
       upstream changes that are possibly relevant to what you are doing.
       When your local changes do not conflict with the changes in the
       upstream, a simple git pull will let you move forward.

       However, there are cases in which your local changes do conflict
       with the upstream changes, and git pull refuses to overwrite your
       changes. In such a case, you can stash your changes away, perform a
       pull, and then unstash, like this...

Похоже, что так и происходит в моих простых тестах.

Также возможно подразумевает, что «git pull» довольно безопасен, на панели инструментов Git Extensions для Visual Studio есть заметная кнопка «pull», которая не выполняет проверку на грязность перед тем, как вывести «git pull». (Если бы я проектировал панель инструментов Visual Studio, я бы старался не делать так, чтобы в ногу было особенно легко стрелять.)

Страница руководства git-pull не делает мой "git pull" звучащим опасно, хотя предполагает, что это не лучшая практика:

   If any of the remote changes overlap with local uncommitted changes,
   the merge will be automatically cancelled and the work tree untouched.
   It is generally best to get any local changes in working order before
   pulling or stash them away with git-stash(1).

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

Avoid git-pull!
git-pull should never get invoked if you have dirty files lying around or if your branch is ahead of master.
This will always lead to some dirty artifacts in the commit history

Есть простой ответ, какая перспектива лучше, или это как-то индивидуально?

Продолжение : Изменит ли ответ "git pull --rebase" вместо простого "git pull"? В некоторых случаях ребазинг может иметь свои собственные ловушки , но до сих пор я предполагаю, что наличие грязного рабочего дерева / индекса не сделало бы перебазировку более проблематичной, чем в противном случае.

Answer 1

Не в обиду людям, поддерживающим проект Apache DeltaSpike, но я бы поверил тому, что на страницах руководства Git говорится о Git в отношении содержимого вики Delta Spike.

Также обратите внимание, что в цитируемом тексте (выделено мое):

git-pull никогда не должен вызываться, если у вас грязные файлы, лежащие около или если ваша ветвь впереди мастера . Это всегда приведет к появлению грязных артефактов в истории коммитов.

"Грязные артефакты в истории коммитов" - это коммиты Git merge. Это происходит каждый раз, когда вы объединяете ветви вместо того, чтобы перебрасывать содержимое одной ветви на другую. Являются ли эти коммиты слияния "грязными", зависит от вашего проекта, вашей организации, ее мнения и политики.

В любом случае, git-pull никогда не бывает опасной операцией. Как задокументировано, это не разрушит вашу историю или работу.

Answer 2

По моему опыту, это абсолютно безопасно (я использую git около 4 лет).Если у вас есть незафиксированные изменения, обычно вам просто не сообщают о наличии грязной рабочей копии.

Answer 3

Пока что я не уверен, что это на самом деле влияет на git pull (звучит так, как будто он заранее определяет, возможны ли конфликты слияний и прерывается, если это возможно), но, по крайней мере, косвенно отметьте, что слияние (т. е. выполнение git merge) в грязное рабочее дерево, по-видимому, может ограничить вашу способность «отменять» ваше слияние в случае, если слияние идет плохо.В частности, из справочной страницы git-merge:

   [merge] --abort
       Abort the current conflict resolution process, and try to
       reconstruct the pre-merge state.

       If there were uncommitted worktree changes present when the merge
       started, git merge --abort will in some cases be unable to
       reconstruct these changes. It is therefore recommended to always
       commit or stash your changes before running git merge.

Answer 4

git pull - это просто git fetch + или rease / merge, автоматическое объединение может создать шум или непредвиденные результаты. (Пример шума: вам не нужно 10 фиксаций слияния, когда все, что вы сделали, это добавили одну строку в один и тот же файл 10 раз.) Если непосвященный просто делает git pull и откатывается назад без проверки , шум будет проверен.

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

Answer 5

Сценарий A:

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

Сценарий B:

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

Сценарий Б иногда появляется у меня после представления новых членов команды в Git.Распространенной ошибкой новых членов моей команды является случайное / небрежное изменение файлов в наших репозиториях сетевых дисков, а не на их локальных клонах, как они должны, и они также забывают зафиксировать эти изменения!

КакКроме того, один из способов защитить себя от ошибок, допущенных вашей командой, - это всегда сначала обращаться к чистому локальному репо, решать локальные конфликты, а затем вытягивать из локального репо в репо, которым вы делитесь с вашей командой.Этот дополнительный шаг предотвращает сценарий B и делает прозрачное «грязное» дерево прозрачным для вас, или, в худшем случае, представляет сценарий A. К счастью, сценарий A можно рассматривать как обычный конфликт без головной боли в сценарии B.

Answer 6

git fetch

А затем объединить, перебазировать или сбросить в зависимости от того, что было получено с сервера.Вы можете использовать тягу, и это не разрушит незавершенную работу.Однако первый метод является предпочтительным.