6

I need some help planning how the workflow will go for a specific site development environment recently converted to Git (from SVN).

I have 4 developers, live and staging sites on the client server, and a dev server which hosts the "hub" (bare repo) plus 2 of the developers' repos. We have several milestones of changes to be worked on, with an unknown order of completion and being worked on by multiple developers. Also, the live site needs numerous quick fixes done on the fly.

My main questions are:

  • How should urgent fixes be addressed
  • How should publishing a milestone of changes go

My brain is starting to go in loops trying to figure out the best workflow. For reference in this post, let's say I have two milestones of changes: mobile and redesign. Here is what I've come up with so far:

Each developer repo, the hub repo, and the stage repo all have these branches: mobile, redesign, master. Live repo has one branch: master

QUICK FIXES: developer makes the change to their master branch, pushes to hub. Then at live, pulls the change from hub (or stage first if they need to test there beforehand).

FINAL STAGE AND PUBLISH "redesign" MILESTONE: developer pushes redesign branch to hub and pulls the changes at stage. Client tests and approves. At hub, developer merges redesign into master (and creates a tag here I think), then pulls master at live. Or would it be better for the developer to merge the branches in his copy, then just push his master to hub. Also, if a tag is created, is it better just to pull the tag (if possible) at live instead of pulling the master branch? And should the tags only reside on the hub repo?

Cœur
  • 37,241
  • 25
  • 195
  • 267
spadeworkers
  • 375
  • 3
  • 11

2 Answers2

2

The workflow seems sound, except for the "merge" part.

I would always precede any merge with a rebase first: the developer rebase his work on top of the master branch in order to solve any conflict locally(like the first scenario I describe in "rebase vs. merge").
That will make any subsequent merge (after the initial rebase) a fast-forward one.

(Jefromi mentions in the comment that a rebase is not always possible.
True, whenever some work has already been pushed/pulled elsewhere, rebasing that same work is dangerous.)

As for pulling the tag or master at live, I would rather have only tags deployed, not HEAD of branch. Meaning I would push a a bare repo at live, which would have a post-receive hook set to update a non-bare repo (the actual live site) with a tag only if said tag is at the HEAD of the master branch (which git describe can easily check)

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Of course, you can't always rebase, in particular with hotfixes - you might want to merge them both into a maintenance branch and the current version. You can still have a developer ensure that it's a fast-forward merge in the public repo by performing the merge themselves locally. – Cascabel Nov 29 '10 at 05:36
  • Great, thank you for explaining in depth about rebasing and when to do it. About the hook, are you saying that whenever I create a tag on master, it will automatically push that tag to live? Not sure if I understood correctly. – spadeworkers Nov 30 '10 at 05:29
  • @spadeworkers: the idea is to have a script able to detect if the commit pushed is a label (that is where `git describes` comes in). If it is such a commit (i.e one with a tag), then that tag will be pushed to non-bare repo and that non-bare repo will be checked out with said tag (by the same `post-receive` hook script) – VonC Nov 30 '10 at 06:28
  • I see. Before I setup hooks though, what is the process for updating the live site with a tag? I've been looking in the documentation it didn't seem clear. I think its using the ref name, so would it be simply this (from live site): git pull 1.1.3 (where 1.1.3 is the name of the tag) – spadeworkers Dec 15 '10 at 00:52
  • @spadeworkers: since this is initiated by the bare repo hook, a simple `git pull` in the non-bare repo is enough (it will only take place when the commit has a tag). See http://stackoverflow.com/questions/2626964/what-user-runs-the-git-hook for such a hook. – VonC Dec 15 '10 at 04:59
  • I appreciate the input about using hooks, but I want to take this a step at a time and don't want to use hooks yet. But when I do, I'll definitely revisit your input. In the meantime, I just want to know how to pull a tag without hooks. If I just do git pull it will update with master, and I don't want any commits which are after the desired tag was created. – spadeworkers Dec 15 '10 at 21:44
  • @spadeworkers: the reason why I was still mentioning hook is because it is the natural mechanism for the bare repo to initiate the non-bare repo update: only the bare repo knows *when* it just received a tagged commit. To try the reverse (the non-bare repo pulling from the bare repo) means having to answer to the question: " *when* to pull?" That being said, a combination of `git fetch` and `git merge` might be what you want: See for instance http://stackoverflow.com/questions/791959 or http://stackoverflow.com/questions/1357086 – VonC Dec 15 '10 at 21:48
1

In my opinion your workflow is 75% ok. Here is how I would do it:

The basic concept is that each branch represents a state of the website. The master branch is the current work in progress, that is basically what you see on your staging site. You create a 'live' branch that represents the actual live site. You then have as many branches as you need for other tasks.

Your developers push their changes into the hub repository, each with their branches. When you are ready with a feature you merge/rebase your changes to the master branch and push it to the hub. Then you sync (push or pull) these changes to the staging site. You do this until you are satisfied with the changes. (On your development PC) you then rebase the live branch from the master branch. Push it to the hub, then sync (push/pull) to the live server, which updates the website.

The really important bit here is that you have a separate branch for the live site. This enables your developers to fetch the live branch and do quick changes to the site.

Finally a thing to note, except for local developers branches, all branches are duplicated in all repositories. This enables everybody to see the different stages of work.

rioki
  • 5,988
  • 5
  • 32
  • 55
  • Thanks, this makes things very clear. I can envision using this model for our workflow. And then the tag would be created after rebasing live from master on my dev pc, which would also (the tag) get duplicated after push to hub and elsewhere. Is that right? – spadeworkers Nov 30 '10 at 05:40