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

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

Но главное остается: push/pull об удаленных репозиториях.
Checkout — о локальных репозиториях.

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

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

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

Вы не можете зафиксировать ветку, отличную от текущей; или, другими словами, новый узел, созданный 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 (*). В зависимости от характера изменений, это может быть нормально, но в большинстве случаев вы захотите, по крайней мере, выполнить быструю проверку работоспособности (например, убедиться, что код все еще компилируется, возможно, запустить дымовые тесты) перед отправкой в ​​общий репозиторий.

Для этого вам нужно либо:

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

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

git checkout master
git merge FeatureBranch
git checkout FeatureBranch

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

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

git push . HEAD:master

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