6

I'm using git to track a project, and if it's possible, I'd like to set things up so git handles all my code staging, I can have a local repository for testing, and then push changes to the server with git to make them live. However, in trying to use standard git push calls, I just end up with inconsistent branching and a terrible mess of conflicting histories. Is there a way to manage staging using git?

futuraprime
  • 5,468
  • 7
  • 38
  • 58

2 Answers2

9

You have in this blog post an example of Git repo used for staging:

IDE => local Git repository => remote bare Git repository 
                                   => Git repository with the live web application

It involves a post-update hook on the bare repo side, in order to trigger the update of the repo on the live web server side.

The final step is to define the “post-update” hook script on the bare repository, which is called when the bare repository receives data.
To enable the “post-update” hook, we have to either make hooks/post-update executable or rename hooks/post-update.sample to hooks/post-update, depending on the Git version.
In this script, we simply change to the folder of the live application, and start the pull operation:

#!/bin/sh
cd $HOME/example.org
unset GIT_DIR
git pull bare master

exec git-update-server-info

The reason there is a bare remote repo is because it is “discouraged” to do a push into a repo with a working directory.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • What is the benefit of the bare repo? Insofar as it is discouraged to push into a working tree, you haven't gained anything but complexity by adding this middle step. I haven't tried these and don't know Git that well, so if you would elaborate more that would be mucho helpful – SamGoody Apr 10 '11 at 13:55
  • @SamGoody: actually, I would rather don't use the *third* repo for the live web site deployment, but the second one *needs* to be a bare one in order to make *sure no local modification interferes with you pushing new commits to it*. See http://stackoverflow.com/questions/5490434/git-live-server-best-practices/5491039#5491039. The post-receive hook combined with a git archive (a tar to be extracted) is better. – VonC Apr 10 '11 at 14:03
  • As it stands work is occasionally done on the live server, and then merged backwards to the development computers. (Granting that our setup is unusual, it is correct for our needs.) We need the live server to have the ability to receive and push changes. Ideally, when pushed to it, changes should be merged in [or an err should somehw be logged]. Git archive would not be suitable. This solution would be, but why not push directly in? – SamGoody Apr 10 '11 at 14:17
  • @Samgoody: in that case, you need to be extra-sure no local modifications aren't committed when you want to receive and merge those changes coming from development. I would go as far as to reject any push if a local non-committed modification is in progress on the live site. – VonC Apr 10 '11 at 14:52
  • Agreed and accepted. And thank you. To the original point: Assuming the user really wants to have the live server as a git repo, is there any advantage to using a second bare repo and not just pushing to the live repository? Also, would you be able to give the commands needed to reject if there are non-committed files? – SamGoody Apr 10 '11 at 15:16
  • @SamGoody: if you have the necessary checks in your hook, you don't need the intermediate bare repo. Rejecting a push simply means for the hook to return anything other than 0. – VonC Apr 10 '11 at 16:31
0

Even though git is a distributed version control system, it is usually a good idea to have a central repository (could be a --bareone). It will simplify things.

Antony Hatchkins
  • 31,947
  • 10
  • 111
  • 111
  • Yes, but how does this help with having to manage a staging branch and a production branch and one or more development branches? – Thilo Jan 14 '10 at 07:04
  • Should I have a central repository, then clone it both locally and on the live server, and then SSH in and do manual pulls to update? That makes sense, but it feels like there ought to be a more elegant solution. – futuraprime Jan 14 '10 at 07:12
  • One bare central repository on live server would be enough. Since you're getting conflicting histories, I guess you make some changes in the production site. If doing that seems convenient for you, then manual pulls should be ok. If you can go without such changes, use post-update hook as suggested by VonC. – Antony Hatchkins Jan 14 '10 at 07:36