git ,,local push'' from feature branch to master, without checkout

Question

Hi.
I would like to merge from FeatureBranch to master, without doing ,,checkout master'' first. I've tried (being in FeatureBranch)

git push . master

but I got (to a degree of surprise) :

Everything up-to-date

Despite having commits in FeatureBranch which are not (yet) present in master.

The reasons why I desire to be able to do ,,one-step local push'', are:

1. I want to give changes to my co-workers who stay on master branch
2. without the additional step of ,,checkout master''
3. thus being able to still stay in FeatureBranch
4. and avoiding rapid changing of many files which confuses/alerts many tools which have something to do with dirs/files in repo

I know I can do it in more steps in different ways. But I wonder whether there is a one-step solution to this (I think there should be).

I think/realize, that if conflicts arise, I would have to switch to master anyway. But in most cases I do not have conflicts and thus would benefit from one-step solution.

My git version:

git --version
git version 1.6.5.1.1367.gcd48

(Windows)

TIA
karolrvn

Answer 1

You cannot commit to a branch other than the current one; or to put it another way, the new node created by git commit is always a child of the current HEAD.

I have occasionally used a separate 'staging' repo in order to avoid the overhead of switching branches in my live development environment:

# 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

A potential problem with this approach is that it doesn't allow you to test the result of merging in the changes made on branch 'foo' with any that have meanwhile been made in shared-repo/master (*). Depending on the nature of the changes, this may be OK, but in most cases you will want to at least do a quick sanity check (e.g. check that the code still compiles, maybe run smoke tests) before pushing to the shared repository.

In order to do that, you would either need to:

1. build staging-repo - but in this case, the merge could just have been done directly in main-repo
2. have staging-repo in a separate build environment from main-repo, i.e. $SOME_OTHER_DIR/staging-repo. This would allow staging-repo to be built and/or tested without dirtying the environment of main-repo.

Answer 2

It seems that what you actually want to do is a merge, not a push? Unfortunately I don't think that's possible without being on the branch that is the target of the merge, so the command sequence would be:

git checkout master
git merge FeatureBranch
git checkout FeatureBranch

This entire operation should take less than a second, so I'm not really sure why you are strongly objecting to changing to the master branch for this...

Answer 3

Regarding your question about why the push command acts like it does...

Push is used to propagate commits from one repository to another, not among branches within a repository. In your case you are pushing from one repository to the same repository, so the answer is "Everything up to date", just as it should be. The fact that you are naming two different branches is irrelevant in this case.