I'm using git开发者_如何学C to version my home directories on a couple different machines. I'd like for them to each use separate branches and both pull from a common branch. So most commits should be made to that common branch, unless something specific to that machine is being committed, in which case the commit should go to the checked out, machine-specific branch. Switching branches is clearly not a very good option in this case.

It's mentioned in this post that what I want to do is impossible, but I found that answer to be rather blunt and to perhaps not take into account the possibility of using the plumbing commands. Unfortunately I don't have enough reputation to comment on that thread. I rather suspect that there is some way to do this and am hoping to save myself an hour or few of questing for the answer by just asking you good folk.

So is it possible to commit to a different branch without checking that branch out first? Ideally I'd like to use the index in the same way that git commit normally does.

I believe that the best way to do what you want is to make your commits on top of the machine-specific branch, then move them with git rebase. That's approximately what I do with my own home directory - essentially the same situation as yours.

# make a new branch starting from branch machine_1
git checkout -b move_to_master      
# make whatever commits you need to
git rebase --onto master machine_1 move_to_master
git checkout master
git merge move_to_master  # this is a fast-forward
git checkout machine_1
git merge master

If you accidentally commit to machine_1 before creating move_to_master, just create move_to_master, then reset machine_1 back to where it belongs, and follow the rest of the steps.

However, your question's worth answering, and I've provided a couple more alternatives at the bottom.

Creating commits not on the current branch

Precaution: be very very careful! This is scary stuff!

It is possible to commit to a branch that isn't checked out using plumbing commands, just not necessary very desirable. You have to get your index into the state you want (this can be tricky), and then you can use git commit-tree:

git commit-tree -p $PARENT_COMMIT < $COMMIT_MESSAGE_FILE

This will print to stdout the SHA1 of the newly created commit object; assuming PARENT_COMMIT was a branch tip, you must then use git update-ref to update the branch to it:

git update-ref -m "commit: [commit subject]" $BRANCH $NEW_SHA1

If you're scripting this, you could achieve it in a one-liner as git update-ref -m ... $(git commit tree ...). This is the scariest step. If you update-ref your other branch to the wrong place, it kind of sucks. You can still figure out where to reset it back to with git reflog show $BRANCH though.

Anyway, this was just the easy part. The really hard thing is getting the index into the state you want without actually checking out the files. Two of the common commands you might use:

git read-tree - reads tree information into the index, but doesn't update the work tree at all (git checkout is roughly equivalent to git read-tree, git checkout-index, and git update-ref HEAD). You could use this to make the index contain the contents of that not-checked-out branch, instead of HEAD.
git update-index - modifies the index. You can use this to add, remove, or refresh files in the index from the work tree.
git checkout-index - copy given paths from the index into the work tree. After using read-tree, you could use this to get the individual file you want to change, modify it, then put it back in with update-index. The "modify it" step could be complex - for example, before doing all this, you might create a patch with git diff, then apply it with git apply here.
git apply --cached With the --cached option, this applies a patch directly to the version in the index, without touching the work tree. You can therefore create a diff, read-tree the other branch, apply it to the index, commit-tree, and you're set. This is probably the most awesome way to do this.

The reason this is all so hard is that all of the git commands which give you access to all of its powerful merging capabilities rely on having the files in the work tree. When you think about it, the task you're trying to do is a merge - you have a diff on one branch, and you want to apply it on another. The way to get the result is by doing a three-way merge, using the diff on the original branch, the common ancestor with the other branch, and the tip of the other branch. Without the other branch checked out, you can't really do this merge!

As usual when doing things with plumbing commands, you should be very very careful to understand how everything works so you don't horribly ruin your repository. That said, I've actually used this to great effect when restructuring existing repositories (ones created by others... don't ask). I was only rearranging commits in those cases - using read-tree and not generally update-index - so it was much simpler than what you're probably trying to do.

Alternate approaches

Having said all this, there are a couple other approaches you could take to get done what you want to.

clone your repository. If you're only tracking config files, this wouldn't take much extra space, and things would be oh-so-much easier. If you're really obsessive, you could even use the git new-workdir (link to the version in HEAD of git.git) script to make only a working directory, not duplicating the rest of the repo (it uses symlinks in the .git directory). Just remember to be careful of committing in one workdir to the branch that's checked out in the other - the other will end up with its work tree out of sync.

write a single-commit wrapper script - this is the closest thing to making a single commit to another branch of all these options:

git commit
orig_branch=$(git symbolic-ref HEAD)
orig_branch=${orig_branch#refs/heads/}
git checkout master
git cherry-pick $orig_branch
git checkout $orig_branch
git reset --hard HEAD^

I do this for my Visual Git Reference project. I run make gh-pages, which builds the website and commits it to the gh-pages branch, without me having to switch branches. See my GitHub repo, particularly the files Makefile and publish. I probably should use $GIT_INDEX_FILE as Chris Johnsen mentioned above, but this seems to work fine.

It's possible I've misinterpreted your request, but let me know if this is what you're looking for.

You start on a machine-specific branch. You make changes, but instead of committing to the machine-specific branch, you want to commit the change to the common branch. What you should do is

git stash              # save your changes for later
git checkout common    # switch to the common branch
git stash apply        # recall the stashed changes
git commit             # commit as appropriate (on the common branch)
git stash drop         # kill off the last stashed changes (this is optional)
git checkout machine1  # go to your machine-specific branch
git rebase common      # put your machine-specific changes after the common ones
git checkout machine2  # [repeat]
git rebase common

Alternatively, you could use git merge instead of git rebase if that's not how your changes can apply.

Does this apply to your situation?