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

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

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

Начнем с того, что страница руководства 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 имеет заметную кнопку «тянуть», которая не проверяет наличие грязи перед тем, как вывести «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» ответ вообще? Перебазирование может иметь своесвоя подводные камни в некоторых случаях, но до сих пор я предполагаю, что наличие грязного рабочего дерева / индекса не сделает перебазирование более проблематичным, чем могло бы быть в противном случае.

Ответы на вопрос(6)

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

Сценарий Б:

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

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

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

git fetch

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

что это на самом деле влияет на git pull (звучит так, будто он заранее определяет, возможны ли конфликты слияний и прерывается, если это возможно), но, по крайней мере, косвенно отметим, чтообъединение (то есть выполнение git merge) в грязное рабочее дерево, по-видимому, может ограничить вашу способность «отменять» ваше слияние в случае, если слияние закончится неудачей. В частности, из man-страницы 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.

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

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

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

Решение Вопроса

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

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

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

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

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

 André Caron13 апр. 2012 г., 23:16
@DarWhi:ссылка в вопросе содержит комментарий в первом разделе под названием «Избегайте git-pull!». Текст заголовка ссылки только "например" так что это довольно тонкий.
 Cascabel25 мар. 2012 г., 08:06
Это утверждение из вики странное: локальные измененияникогда привести к "артефактам" в истории коммитов.
 André Caron25 мар. 2012 г., 18:19
@Jefromi: действительно. Вот почему я акцентировал внимание на последней части (которая автоматически создает коммиты при необходимости).
 Dar Whi13 апр. 2012 г., 22:35
Я не вижу такого комментария в вики DeltaSpike.
 André Caron17 апр. 2012 г., 21:17
@DarWhi: Вы просто переписываете то, что я сказал в своем посте и моих комментариях.

Ваш ответ на вопрос