Каков наиболее эффективный способ объединить исходные изменения в рабочую копию с помощью Git?

Я думаю, что отказ от слияния — плохая идея:

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

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

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

Я лично использую вариант 1, даже если у меня есть много ожидающих исправлений. Это позволяет мне перепроверять каждый патч при выполнении перебазирования, а также предотвращает «злые слияния», которые мне не нравятся (имхо, сделать git виноватым).

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

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

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

Вы упоминаете начальный сценарий, для которого у меня есть рабочий шаблон, который я считаю полезным:

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

Допустим, вы работаете над feature-X, который в итоге будет помещен в dev (ветвь разработки). Другие разработчики работали над функциями Y и Z, и одна из них завершена, а dev теперь обновлена, поэтому вы запускаете:

$ git fetch

и видим, что ваш dev теперь позади origin/dev. То есть теперь у вас есть:

...--C--D--H   <-- master
         \
          \         I--J   <-- origin/dev
           \       /
            E--F--G   <-- dev, feature-X (HEAD)

в вашем репозитории. У вас также есть некоторые вещи в вашем рабочем дереве, которые отличаются от файлов в коммите G. (Возможно, у вас еще нет ветки с именем feature-X, и вместо этого HEAD присоединена к dev. В этом случае вы можете просто создать ее сейчас с git checkout -b feature-X, и теперь вы соответствуете картинке.)

Что нужно сделать на этом этапе, так это зафиксировать материал, над которым вы работаете в любом случае. Это делает один новый коммит K:

...--C--D--H   <-- master
         \
          \         I--J   <-- origin/dev
           \       /
            E--F--G   <-- dev
                   \
                    K feature-X (HEAD)

Теперь вы можете перемотать свои собственные файлы с dev на origin/dev. Основной метод команды:

$ git checkout dev                 # safe, since your work is committed
$ git merge --ff-only origin/dev   # or `git pull` if you really insist

Теперь рисунок выглядит так:

...--C--D--H   <-- master
         \
          \
           \
            E--F--G--I--J   <-- dev (HEAD), origin/dev
                   \
                    K   <-- feature-X (HEAD)

Здесь большинство людей просто запускают git checkout feature-X; git rebase dev, и это нормально, и вы можете свободно использовать этот метод. (Я часто так делаю. Подумайте о том, чтобы сделать это с последующим приемом git reset HEAD^, описанным ниже.) Но иногда я просто переименовываю feature-X в feature-X.0, а затем создаю новый< /em> feature-X с git checkout -b feature-X:

...--C--D--H   <-- master
         \
          \
           \
            E--F--G--I--J   <-- dev, origin/dev, feature-X (HEAD)
                   \
                    K   <-- feature-X.0

$ git cherry-pick dev..feature-X.0

...--C--D--H   <-- master
         \
          \               K'  <-- feature-X (HEAD)
           \             /
            E--F--G--I--J   <-- dev, origin/dev
                   \
                    K   <-- feature-X.0

...--C--D--H   <-- master
         \
          \               K'-L'  <-- feature-X (HEAD)
           \             /
            E--F--G--I--J   <-- dev, origin/dev
                   \
                    K--L   <-- feature-X.0

...--C--D--H   <-- master
         \
          \               K'  <-- feature-X (HEAD)
           \             /
            E--F--G--I--J   <-- dev, origin/dev
                   \
                    K--L   <-- feature-X.0