Git Web Development Workflow: juggling the publishing of urgent fixes and multiple milestones

Question

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?

Answer 1

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)

Answer 2

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.