Когда мне нужно выполнить «git pull», до или после «git add, git commit»?

93

Какой правильный путь?

git add foo.js
git commit foo.js -m "commit"
git pull
git push

Или

git pull
git add foo.js
git commit foo.js -m "commit"
git push

Или

git add foo.js
git pull
git commit foo.js -m "commit"
git push

UPD:

Я забыл упомянуть, что в этом случае я использую git addдля обработки отслеживаемый и измененный файл. Не включать новый файл в репозиторий. Это меняет порядок команд?

git

— Зеленый
источник

Связанный вопрос: stackoverflow.com/questions/813822/…

— leo9r

96

Я думаю, что лучший способ сделать это:

Сохраните свои локальные изменения:

git stash

Обновите ветку до последней версии кода

git pull

Объедините ваши локальные изменения с последним кодом:

git stash apply

Добавляйте, фиксируйте и отправляйте свои изменения

git add
git commit
git push

По моему опыту, это путь к наименьшему сопротивлению с помощью Git (по крайней мере, в командной строке).

— Джонджо
источник

4

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

— Даллин

7

Возможно, это было слишком анекдотично, но мне всегда казалось, что этот подход (в командной строке, а не с чем-то вроде sourcetree) намного проще. Выполнение фиксации с последующим извлечением при работе в большой команде всегда приводит к большим конфликтам слияния, поскольку git не очень хорошо справлялся с объединением моих изменений в файл с входящими. Благодаря этому я получил новые изменения, а затем использовал обновленный код как основу для добавления своих изменений. Разобраться с конфликтами было проще, поскольку они были для меня яснее (поскольку мои изменения теперь были конфликтами). Оглядываясь назад, может быть, в моей ситуации было проще.

— johnjo

1

Так что это звучит как что-то вроде «Как съесть слона? По кусочку за раз». т.е. разбиение процесса на еще несколько шагов, чтобы упростить слияния, чтобы было меньше и, возможно, более четких изменений. Имеет смысл.

— dallin

Здесь нужен git add? Если все файлы уже добавлены в постановку!

— Sharp Edge

Что делать, если вы не используете git stash?

— Аарон Франке

76

тянуть = выборка + слияние.

Вам нужно зафиксировать то, что вы сделали, перед слиянием.

Так что тяни после коммита.

— Арно Денойель
источник

8

Означает ли это, что вы в конечном итоге будете делать дополнительную фиксацию для каждой совершаемой фиксации и делать репо небрежным? Кроме того, ваше первоначальное сообщение о фиксации заканчивается каждый раз, за которым следует комментарий слияния. В таком случае я бы предпочел использовать метод stash, упомянутый ниже @johnjo.

— MondayPaper

3

@DanielM Да, для слияния есть дополнительная фиксация (с явным сообщением фиксации по умолчанию). Это неплохая вещь, потому что она позволяет вам проверить свою последнюю фиксацию, последнюю фиксацию вашего коллеги или фиксацию слияния. Если вы хотите избежать этого и хотите разместить свои коммиты после коммитов вашего коллеги, вы можете rebaseвместо merge. Вы можете сделать это с помощью git commit && git rebaseили git pull --rebase.

— Arnaud Denoyelle

Спасибо за подсказку, @Arnaud. Прочитав много разных вопросов SO, этот комментарий сделал это. Я предпочитаю, когда коллеги работают с разными файлами, - git pullпосле внесения моих изменений, поскольку я считаю это наиболее естественным. Хотя я понимаю, что работает много разных рабочих процессов (тайник тоже хорош), так что, вероятно, это дело вкуса.

— nephewtom

51

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

Сказав это, я бы выбрал первый вариант:

git add foo.js
git commit foo.js -m "commit"
git pull
git push

Зафиксируйте свои изменения перед извлечением, чтобы ваши фиксации были объединены с удаленными изменениями во время извлечения. Это может привести к конфликтам, с которыми вы можете начать разбираться, зная, что ваш код уже зафиксирован, если что-то пойдет не так, и вам придется прервать слияние по любой причине.

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

— Jasarien
источник

1

Не могли бы вы увидеть мое обновление вопроса? Я забыл объяснить, для чего git addименно используется мой пример.

— Грин

1

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

— Jasarien

7

Я думаю, что git pull --rebaseэто самый чистый способ установить ваши локальные недавние коммиты поверх удаленных коммитов, которых у вас нет в определенный момент.

Таким образом, вам не придется тянуть каждый раз, когда вы хотите начать вносить изменения.

— Мохиаддин Алаоддин
источник

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

— Люк Ашервуд

3

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

«Грязные» локальные файлы не являются проблемой, если нет конфликтов с удаленной веткой. Однако, если есть конфликты, слияние не удастся, поэтому нет риска или опасности в извлечении перед фиксацией локальных изменений.

— AlexE
источник

1

Не будет работать, как сказал Арно, извлечение требует, чтобы вы сначала зафиксировали свои изменения.

— Jasarien

Мой мерзавец, кажется, рад внести множество локальных изменений. Конечно, если одни и те же файлы изменяются в удаленной ветке, часть извлечения слияния не выполняется. Чтобы создать правильный конфликт слияния, мне, конечно, нужно сначала выполнить фиксацию. Итак, если набор файлов, измененных локально и удаленно, не пересекается, извлечение и последующая фиксация - это нормально. В противном случае git не потянет. Попытки не причинят вреда.

— AlexE

Это мой предпочтительный вариант, когда люди работают с разными файлами, и я считаю его наиболее естественным.

— nephewtom