4

I'm using Git for deployment of a website that has three different domains on two different servers, each representing different phases of development: dev, staging, and production

I have successfully set up deployment using each web root as a remote repository and using the post-receive hook to update itself on push.

But there are a few problems with this. First, when another developer makes changes, I would like to know that I only have to pull down from one repository. I don't want to have to ask him which of the 3 he committed to. Second, it would be nice to take advantage of some branching so that not only did each phase of the website have its own repo, but it had its own branch, too, so that, locally, each of my branches, "dev","staging" and "live" would push to the correct repo.

That's my dream. Can anyone think of a way to accomplish this workflow? I'm failing miserably.

Paŭlo Ebermann
  • 73,284
  • 20
  • 146
  • 210
aaron carlino
  • 303
  • 3
  • 7

4 Answers4

3

You could do something like this. In this workflow I'm assuming a central server (origin>), your computer (local>) and some devolopers (deva>, devb>).

First lets create some local tracking branches for your dev, staging and live branches and push them up to the central repo. This is only needed once so not much overhead.

local>git checkout -b dev
local>git push -u origin dev
local>git checkout -b staging
local>git push -u origin staging
local>git checkout -b live
local>git push -u origin live

Ok.

Now you have three branches that are setup as local tracking branches to the corresponding remote branches on origin. Now any developer can do the same, but they need less amount of work to do so. First they need to fetch the updated references so we can reference a remote branch and after that create the tracking branches with the git checkout command. This need to be done by all developers that are going to contribute to the central repository (and only once even in this case).

devx>git fetch
devx>git checkout --track origin/dev
devx>git checkout --track origin/staging
devx>git checkout --track origin/live

So lets say that deva has done some work that you want to take a look at. We assume that he/she is working on a new feature on the dev branch.

deva>git checkout dev
deva> ... edit some files
deva>git commit -am "new feature bla bla"
deva>git push

You get a mail from deva that he has pushed his changes. Then you do:

local>git checkout dev
local>git pull

Ok. So now you and the other developers have a system up and running so you can collaborate on any phase of development. But how do we get the changes up and running on the server environment?

We can solve this by utilizing the hook system in git. You can let the central repository notify each server environment that something has been pushed to it (you can easily detect exactly which branch that was pushed) and take action accordingly. This way the servers can update themselves, without you having to care about it. Well, of course you need to be careful what you push and don't push. But that requirement will always be there, no matter what kind of system you have.

Hope this helped you realize your dream :D

rtn
  • 127,556
  • 20
  • 111
  • 121
1

You need to protect some repo with some kind of mechanism in order to prevent a developer to:

  • push to the wrong repo,
  • push the wrong branch to the wrong remote branch

That is the kind of encapsulation gitolite can provide.

Another way is to prevent any operation on some repos for certain people, and that would be in line with Linus's advice in its 2007 Google presentation:

One of the things for commercial companies: the distributed model also helps with the release process.
You can have a verification team that has its own tree. And they pull from people and they verify it, and they verified it, they can push it to the release team, and say "Hey. We have now verified our version", and the development people, they can go on, playing with their head, instead of having to create tags, branches, whatever you do to try to keep off each other toes.
Again, you keep off each other toes by just every single group can have its own tree, and track its work and what they want done.

One staging repo could only monitor dev repo for certain person's commits. The same for the production repo.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
1

Another suggestion I would make here is Gitflow, relevant links

http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/

https://github.com/nvie/gitflow

His separation of branches is excellent. You can also pull from a developers branch, review the code and reject it if you wish.

sciritai
  • 3,688
  • 1
  • 17
  • 22
0

Using the method from http://toroid.org/ams/git-website-howto as a starting point, you can alter the post-receive hook to checkout a specific branch. For multiple sites on the same server you can try adding another git checkout line so that all sites are updated from their respective branches each time the hook is run. That page also talks about how to configure your local git repo to push to more than one remote repo with a single command.

Arrowmaster
  • 9,143
  • 2
  • 28
  • 25