git ,, local push '' из функциональной ветви к мастеру, без проверки

Question

Я бы хотел слиться с FeatureBranch, чтобы освоить, не выполняя сначала «checkout master».Я пытался (находясь в FeatureBranch)

git push . master

, но получил (с удивлением):

Everything up-to-date

Несмотря на наличие коммитов в FeatureBranch, которых нет (пока)в мастер.

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

1. Я хочу внести изменения в моих коллег, которые остаются наглавная ветвь
2. без дополнительного шага ,, checkout master ''
3. , что позволяет ему оставаться в FeatureBranch
4. и избегать быстрой смены многих файлов, что приводит к путанице / предупрежденияммногие инструменты, которые имеют отношение к dirs / файлам в репо

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

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

Моя версия git:

git --version
git version 1.6.5.1.1367.gcd48

(Windows)ТИАkarolrvn

Answer 1

Относительно вашего вопроса о том, почему команда push действует так, как она ...

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

Answer 2

Вы не можете зафиксировать ветку, отличную от текущей; или, другими словами, новый узел, созданный git commit, всегда является дочерним элементом текущего HEAD.

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

# Currently working on branch 'foo' in $SOME_DIR/main-repo
# main-repo is a local clone of shared-repo

# Create the staging repo alongside the existing main-repo
cd $SOME_DIR
git clone shared-repo staging-repo
cd staging-repo
git remote add local ../main-repo

# Switch back to main-repo and continue working
cd main-repo
# (Make changes and commit to branch foo ...)

# Switch to the staging repo
cd $SOME_DIR/staging-repo

# Make sure we are up to date with shared repo (*)
git pull

# Merge changes from main-repo
git fetch local
git merge local/foo

# Push changes up to the shared repo
git push

Потенциальная проблема этого подхода заключается в том, что он не позволяет вам проверить результат объединения изменений, внесенных в ветку 'foo', с изменениями, внесенными в shared-repo / master (*). В зависимости от характера изменений, это может быть нормально, но в большинстве случаев вы захотите, по крайней мере, сделать быструю проверку работоспособности (например, проверить, что код все еще компилируется, возможно, запустить тесты дыма) перед отправкой в ​​общий репозиторий. 1008 *

Чтобы сделать это, вам нужно:

1. build staging-repo - но в этом случае слияние могло бы быть сделано непосредственно в main-repo
2. иметь промежуточное репо в отдельной среде сборки из основного репо, т.е. $SOME_OTHER_DIR/staging-repo. Это позволило бы построить и / или протестировать промежуточное репо без ущерба для среды основного репо.

Answer 3

У меня была такая же проблема, и, основываясь на вашей идее, я нашел решение довольно простым:

git push . HEAD:master

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

Answer 4

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

Но главное остается: push / pull - это примерно Удаленное РЕПО.
Оформление заказа о локальном репо.

Если вы имеете в виду эту схему, вы понимаете, что не настаиваете на master.

Answer 5

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

git checkout master
git merge FeatureBranch
git checkout FeatureBranch

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