CODEWITHSUNDEEP
gitbranchpush
Malvineous
Malvineous

Reputation: 27300

git: better alternative to regularly pushing a rebased branch

I have a git repository for a web site, where the master branch represents production code. I have been asked to set up a 'sandbox' version of the site, for potential users of the system to experiment in so they don't have to do that in the production system.

Because the sandbox version of the site needs to be clearly labelled as such, and have some functionality disabled, I have created a sandbox branch (based off master) and made some commits there to add warning messages and so on.

I have then pushed both branches upstream, and on the web server I have checked out each branch in a separate directory - one for production and one for the sandbox.

This works fine, but the problem comes when I want to write more code. Once I commit the code to the master branch, it will be updated in the production system but the sandbox won't see the new code. So I rebase the sandbox branch onto master, so the commits for the sandbox always sit on top of production. But then of course once I've done that, I can no longer push the sandbox branch upstream because it's no longer a fast-forward. I have to log in to the git server, switch branches, do a soft reset then redo the push.

Surely there's a better way of doing this with git? What I really need is some way of consistently applying some commits on top of whatever branch is currently checked out.

Upvotes: 2

Views: 400

Answers (2)

opqdonut
opqdonut

Reputation: 5159

You can do a non-fast-forward push with git push remote +branch. However the receiving git repository can be configure to reject these.

However you might run into slight problems if you have edits to an old version of the branch but have pushed a rebased version upstream. One way to work around this is the following:

# you are on branch X and origin/X has been force-updated
git branch X-tmp   # keep a reference to your new commits
git fetch origin
git reset --hard origin/X   # now X is the same as origin/X

# now you have two options
# option 1: move the new commits from X-tmp to X by cherry-picking
# them one-by-one
git cherry-pick abc123
git cherry-pick def456

# option 2: this rebase should do the right thing and detect the equivalent
# commits in X and X-tmp
git checkout X-tmp
git rebase X

Upvotes: 1

Niko Sams
Niko Sams

Reputation: 4404

I would do this differently by having two code paths where required that both exist in master branch.

Eg. using some config file (that is not under version control) you can switch to the other code path. Or some environment variable - whatever suits you best.

Upvotes: 1

Related Questions