Не может нажать на ветку после rebase

Ответ 1

Во-первых, вы и те, с кем работаете, должны согласиться с тем, является ли ветка темы/разработки для совместной разработки или просто вашей. Другие разработчики знают, что не сливаются в моих ветвях развития, потому что они будут переустановлены в любое время. Обычно рабочий процесс выглядит следующим образом:

o-----o-----o-----o-----o-----o       master
 \
   o-----o-----o                      devel0
                \
                  o-----o-----o       devel1

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

 git fetch origin
 git checkout master
 git merge --ff origin/master

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

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

git checkout devel0
git rebase master
git push -f origin devel0

Другие разработчики знают, что им нужно будет отменить свои девелоперские ветки с моего последнего:

git fetch <remote>
git checkout devel1
git rebase <remote>/devel0

Это приводит к значительно более чистой истории:

o-----o                                 master
       \
         o-----o-----o                  devel0
                      \
                        o-----o-----o   devel1

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

Также звучит так, как будто другие разработчики могут делать коммиты для ваших ветвей развития. Можете ли вы это подтвердить?

Единственное время для объединения - когда ваша ветка темы готова к принятию в master.

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

git branch 'my-name/devel-branch'

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

Ответ 2

Вам нужно принудительно нажать, когда вы переместили фиксации дальше по строке git, ожидая, что вы добавите фиксации к концу ветки. git push -f origin myNewFeature исправит вашу проблему.

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

Ответ 3

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

Притяжение будет в основном делать две вещи: выборка и слияние. Когда вы включаете --rebase, вместо слияния будет использовать rebase.

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

(Это объясняет, почему вы можете получать несколько подсказок разрешения конфликтов при выполнении переустановки по сравнению с одним разрешением конфликта, которое вы можете получить при слиянии. У вас есть возможность разрешить конфликт в транзакции EACH, которая переустанавливается, чтобы в противном случае сохранить ваши коммиты.)

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

Это потребует от вас одновременного нажатия на переменные изменения с использованием силы:

git push -f origin newfeature

Или в некоторых случаях ваш администратор может удалить силу, чтобы вы могли удалить и восстановить:

git push origin :newfeature
git push origin newfeature

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

Помните, что вы почти всегда можете отказаться от git GC, воспользовавшись:

git reflog

Это ОГРОМНАЯ спасательная жизнь, так как вы можете reset вернуться в более стабильное состояние, если вы потерялись во всех своих режимах управления перестановкой/конфликтами.

Ответ 4

Вам нужно выполнить принудительное нажатие, т.е. git push -f origin myNewFeature

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

Ответ 5

Общий ответ, который уже был дан - использовать git push -f origin myNewFeature при нажатии на измененные изменения - является хорошим стартовым местом. Я пишу этот ответ, чтобы обратиться к правлению о том, нарушит ли он ваш рабочий процесс.

Если мы предположим, что вы собираетесь использовать git pull --rebase ... (или некоторые варианты этого), за которым следует принудительное нажатие на удаленную ветку, то вещь, которая разбивает рабочий процесс в вашем примере, - это слияние 2, t22 > в hisNewFeature. Имеет смысл иметь возможность переустанавливать вашу собственную ветвь функции, пока никто не работает над этой ветвью, поэтому вам нужны правила для разграничения территории ветки.

Вы можете обойти это: a) установлением правила, которое вы только сливаете из master, или b) создания коллективной ветки develop, на которой вы основываете свою ветвь myNewFeature, и устанавливаете правило что вы только слились с develop. master затем будет зарезервирован только для этапов или выпусков (или, тем не менее, вы хотите установить это), а develop будет там, где вы будете нажимать каждую функцию, когда она будет готова к интеграции в другие ветки функций.

Я считаю, что это можно считать упрощенной версией рабочего процесса Gitflow.