CODEWITHSUNDEEP
gitversion-control
Mike Christensen
Mike Christensen

Reputation: 91726

What is considered best practice for using Git to manage multiple releases of a web site?

We're currently in the process of migrating from Subversion to Git. In Subversion, we had this complete nightmare of branches and it was totally unclear how to find anything or what branch to sync to. Basically, someone created a new branch every time we pushed out a new version of our app to the production server. So there would be a branch called 1457 with all the bits from that build. Then, after that build was done they'd create a new branch called 1458 and start checking in there. When that build was ready, we'd copy everything out to production and repeat. Sometimes, there'd be weird sub-releases and there'd be a branch called like 1457_B or something. It got totally confusing.

It seems they want to keep using this system with Git as well. I think it would be annoying to have to "switch branches" every time we release a version. It seems a better approach would be to just have a "main repository" that's in sync with whatever currently is in production, and then have a single "Development" branch with incremental changes I can push to every few days or so. Then, when a build is ready to be deployed, merge the Development branch back into main and call it good.

I think their argument is that they want to be able to see the bits from any specific build in time - which is odd because I've never actually come across a need to do this. With Git, is there a better way to "label" a point in time so that you can quickly see a repository as it existed at a certain checkpoint? Creating a branch for each build seems like overkill to me. I know these questions are kind of vague, mainly I'm just looking for the recommended best practices for this workflow, which I'm sure is quite common.

Upvotes: 2

Views: 526

Answers (2)

TheBuzzSaw
TheBuzzSaw

Reputation: 8836

I would strongly recommend investigating git tags. Using a branch implies that further development will happen on that line. However, if all they want to do is mark releases, have a "production" branch and simply tag the releases. Now, if they want to have multiple simultaneous releases, branches might indeed come in handy there.

Upvotes: 3

Dominik Honnef
Dominik Honnef

Reputation: 18440

Git has support for tags, which are either pointers to commits, or full-blown objects with signature, author and obviously a reference to a commit.

So for each release you'd have a tag that describes a specific point in time.

Your approach of having a main branch and a development branch is definitely the usual approach, unlike having one branch per release. Such branches would only come into play when maintaining an older version (e.g. bug fixes), but that rather applies to the context of applications, not websites.

Upvotes: 1

Related Questions