2

I've used to using Github as a backup or a central repository and doing both development and testing locally.

Now I have a remote test machine and want to be able to push local commits to the remote such that the remotes working directory updates, allowing me to run tests on the contents.

1) Most of the instructions I have found for setting up remotes is to use a --bare init. As far as I understand, this means the remote lacks a working directory and accepts pushes. Setting up a remote without --bare fires an error when I try and push. How can I accomplish the above workflow?

2) Is this workflow even a good idea? Should I instead have a test repo located on the remote machine in addition to the bare repo. I make my pushes from development to the bare repo and then, when I am ready to test, I pull from the bare repo into the test repo.

In case it matters, I asking in relation to a Rails project but I haven't tagged this question as such because I can't see why it would.

Rupert Madden-Abbott
  • 12,899
  • 14
  • 59
  • 74

3 Answers3

4

I'd suggest going with a bare repository for pushing and a second repository that will pull from it where the tests will run. It will be easier to understand and you don't have to be careful when you decide to scratch the test environment and re-create it. If they are on the same server, the test repo can have 'alternate' set up for the central one, so the objects won't be stored twice (created using git clone --shared).

Even with this setup, you can easily have the tests run automatically. Just install a post-receive or post-update hook in the central repository, that will run the test. There is even a ready-made implementation in contrib/continuous in git sources that you can tweak to your needs.

It's not that you couldn't set up a push repository with working directory. Git will not allow you to push to the checked-out branch (because it does not know how to update it during push and would not know how to do it later), but that can be worked around by using 'detached HEAD'. It will however be quite confusing and you risk accidentally removing important data when you decide to rebuild your test environment.

Jan Hudec
  • 73,652
  • 13
  • 125
  • 172
1

In most cases, you don't want to push into a non-bare repository. The reason is, that pushing only updates the history, but not the working directory; this is explained in the git FAQ.

So yes, your second suggestion would be the way to go. You could even use a post-update hook to update your test repository automatically

Lars Noschinski
  • 3,667
  • 16
  • 29
0

The way we do it in our projects, is to have a separate branch for every test server (staging, test, qa). When you want to deploy some changes to one of the servers you simply merge them into the specific branch for that server and then use Capistrano to deploy.

psyho
  • 7,142
  • 5
  • 23
  • 24