2

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.

Malvineous
  • 25,144
  • 16
  • 116
  • 151
  • did you try any commit hooks? – J-16 SDiZ Oct 05 '12 at 09:22
  • @J-16SDiZ: No, I was hoping I could do this with git's built in features, so I don't have to remember to copy the hooks if the repository moves. – Malvineous Oct 05 '12 at 13:18
  • Hooks on the sandbox server, I means. Don't you have some CI infra already? How does the sandbox update? – J-16 SDiZ Oct 06 '12 at 02:44
  • @J-16SDiZ: I understand, but I meant if I have to move the web files somewhere else I would prefer I can just do a 'git clone' in the new spot and not have to remember to set up the hooks again. Hooks are fine for automating manual tasks (you can do them manually if the hook fails), but I don't like the idea of losing code because of a failed hook! – Malvineous Oct 06 '12 at 03:35
  • Did you know that you can do a non-fast-forward push with `git push remote +branch`? However the receiving git repository can be configure to reject these. – opqdonut Oct 17 '12 at 19:49
  • @opqdonut: You should put that as an answer, since it's a possible solution and then people can upvote it if it helps them. For me, I think it would only solve half the problem - I also have to 'git pull' the changes from that same branch, and I don't think you can do a non-fast forward pull. Or can you? – Malvineous Oct 18 '12 at 00:14

2 Answers2

1

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.

Niko Sams
  • 4,304
  • 3
  • 25
  • 44
  • That's true, this is what I have done for the dev/prod versions (e.g. so the dev version doesn't e-mail real people.) Since the sandbox is only temporary, I was hoping I could avoid keeping the sandbox code around forever by just deleting that branch when it's done. – Malvineous Oct 06 '12 at 03:29
1

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
opqdonut
  • 5,119
  • 22
  • 25
  • This isn't a bad idea - because you can't (or shouldn't) push into a working tree, I have a script which does the `git pull` in the target working tree. So I could change this to a form of `git reset && git pull`, since that tree will never have extra commits that need saving. – Malvineous Oct 19 '12 at 23:30