Подтолкнуть к фиксации с --set-upstream? - PullRequest
Новая
       5

Подтолкнуть к фиксации с --set-upstream?

0 голосов
/ 14 мая 2018

Давайте возьмем этот случай, который я сейчас имею: 

$ git log --decorate
commit A (HEAD -> dev)
commit B
commit C
commit D
commit E
commit F (origin/dev)

Теперь, если я хочу перейти на HEAD, поскольку я уже сделал --set-upstream, я могу просто git push.

В моем случае я хочу нажать dev, но только до коммита C, поскольку я часто исправляю / сквош / перефразирую последние несколько коммитов, которые у меня есть. Я могу сделать git push origin C:dev, но разве нет менее подробного способа сделать это, учитывая, что я установил ветку dev для отслеживания origin/dev? То есть, есть ли способ для меня не указывать удаленный и ветвь, но все же подталкивать к определенному коммиту?

1 Ответ

0 голосов
/ 14 мая 2018

Я могу сделать git push origin C:dev, но разве нет менее подробного способа сделать это ...

Не совсем менее многословно , новозможно проще . 1 Я предполагаю, что для C вы имеете в виду хеш-идентификатор commit C.Есть еще кое-что, что вы можете сделать.В зависимости от того, как вам нравится работать, вы можете найти это лучше или нет.См. Раздел ниже сноски.

При использовании синтаксиса git push <em>remote</em> <em>refspec</em>, подобного этому, с аргументом refspec, который содержит буквенное двоеточие :, символ слевасторона аргумента refspec может быть что угодно , которое выбирает желаемый коммит.Необработанный хеш-идентификатор работает хорошо, но относительное имя, например, HEAD~2 или dev~2, также можно сокращать до полного хеш-идентификатора до четырех символов, если это однозначно идентифицирует объект.

Полный список всех возможных способов именования любого данного коммита приведен в документации gitrevisions .

1 Это зависит от того, что вам кажется простым,и как вы считаете "многословным".Необработанный хэш-идентификатор составляет 40 символов, а dev~2 равен 5, поэтому, очевидно, dev~2 является короче , но в некотором смысле это больше многословно: в нем три слова, dev, ~ и 2.Подсчет также может быть сложным, когда у вас есть несколько твердых коммитов, которые вы хотите протолкнуть вместе с несколькими дюжинами или сотнями шатких, которые вы еще не хотите нажимать - вырезать и вставить необработанный идентификатор хеша здесь может быть лучше.

Другой, возможно, лучший, рабочий процесс

Проблема здесь возникает из-за того, что вы работаете над веткой, которую вы назвали dev, которая является своего рода универсальной.Предположим, что вместо этого у вас есть ветвь с именем wobbly-feature-xyz или, возможно, wip/xyz, где wip обозначает незавершенное производство и является сигналом для всех в вашей группе, что эта ветвьбудет регулярно переписываться его история, и коммиты в ней не должны зависеть.Тогда вы могли бы безопасно сохранить текущие, шаткие коммиты в другом Git на origin (что, возможно, более надежно и получает регулярные резервные копии и т. Д.), Зная, что никто не будет зависеть от них так, как они, вероятно, будут зависетьпри фиксации в dev.

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

Допустим, мы начнем с этого репозитория в вашемGit и Git на origin и, ну, почти все остальные: 

...--A--B--C   <-- master
         \
          D--E   <-- dev
              \
               G--H--I   <-- wip/xyz

Теперь вы работаете в своей ветви функций wip/xyz, в то время как другие работают на их wipособенность веток.Алиса решает, что некоторые коммиты выполнены и готовы к работе, и помещает их в dev, поэтому после запуска git fetch origin ваш репозиторий теперь имеет: 

...--A--B--C   <-- master, origin/master
         \
          D--E   <-- dev
             |\
             | F   <-- origin/dev
             \
              G--H--I   <-- wip/xyz, origin/wip/xyz

Теперь вы можете перемотать вперед dev для получения нового коммита, более или менее в любое время: 

...--A--B--C   <-- master, origin/master
         \
          D--E--F   <-- dev, origin/dev
              \
               G--H--I   <-- wip/xyz, origin/wip/xyz

, а затем, в любое время, также используйте git rebase для копирования трех ваших коммитов WIP: 

      ...         G'-H'-I'  <-- wip/xyz
         \       /
          D--E--F   <-- dev, origin/dev
              \
               G--H--I   <-- origin/wip/xyz

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

     ...--D--E--F   <-- dev, origin/dev
                 \
                  G'-H'-I'  <-- wip/xyz, origin/wip/xyz

Если вы сейчас чувствуете, что first из ваших трех коммитов довольно солидный,теперь вы можете git checkout свои dev и быстрое слияние с последующим коммитом в него: 

     ...--D--E--F   <-- origin/dev
                 \
                  G'  <-- dev
                   \
                    H'-I'  <-- wip/xyz, origin/wip/xyz

Теперь вы можете git push на dev выдвинуть коммит G', давая: 

     ...--D--E--F--G'  <-- dev, origin/dev
                    \
                     H'-I'  <-- wip/xyz, origin/wip/xyz

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

(Это может или не может помочь вам отслеживать, какие коммиты вы считаете надежными.)

...