We use a subtree deployment a lá this Gist to deploy a subdirectory of our Yeoman project. In our case, the branch is called production, not gh-pages.
This worked perfectly until yesterday when the Git server rejected the command git subtree push --prefix dist origin production
, saying
! [rejected] 9fe1683aa574eae33ee6754aad702488e0bd37df -> production (non-fast-forward) error: failed to push some refs to '[email protected]:web-and-new-media/graduation2015.git' hint: Updates were rejected because a pushed branch tip is behind its remote hint: counterpart.
If I switch to the production branch locally (which is clean), git pull
returns Your branch is up-to-date with 'origin/production'.
even if I use the --rebase
option.
I can see the contents of the production branch on the server through our web UI and there's nothing there that shouldn't be, just the compiled output of our dist
directory like I'd expect.
To that end, it seems like I should safely be able to force an overwrite of these files, but how? git subtree push
doesn't have a --force
option.
Only when you are up-to-date will you be able to push your own new commits to the remote. The --force option for git push allows you to override this rule: the commit history on the remote will be forcefully overwritten with your own local history.
Warning: force pushing will overwrite the remote branch with the state of the branch that you're pushing. Make sure that this is what you really want to do before you use it, otherwise you may overwrite commits that you actually want to keep.
To force a push to only one branch, use a + in front of the refspec to push (e.g git push origin +master to force a push to the master branch).
git subtree split lets you specify a rev other than HEAD. So smash those together, and have git subtree push let you specify which local thing to run split on and push the result of that split to the remote ref. Does a 'split' using the subtree of <local-commit> and then does a 'git push' to push the result to the <repository> and <remote-ref>.
An alternative approach to overwriting local changes using git --pull force could be git pull --force "@ {u}:HEAD". The world of Git is vast. This article covered only one of the facets of repository maintenance: incorporating remote changes into a local repository.
Until you push local changes to the remote repository, all your work is available only on your machine. When you finish a task, it's time to synchronize with the remote repository.
On default, --force-with-lease will refuse to update branch unless the remote-tracking branch and the remote branch points to the same commit ref. Pretty great right?
The trick was to chain the subtree split into a forced push:
git push origin `git subtree split --prefix dist master`:production --force
I got this from the Addendum of http://clontz.org/blog/2014/05/08/git-subtree-push-for-deployment/, who actually references this answer on Stack Overflow. I had skimmed this one earlier but Steve Clontz's post made it click for me.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With