CODEWITHSUNDEEP
git
Vecta
Vecta

Reputation: 2350

How to Manage Git Branches that Reflect Testing Environments

A site I'm working on in my organization has three branches: one for testing, staging, and production. Code is deployed to live sites from each of their respective branches.

This is becoming problematic (I think) and I'm unsure if it's just due to me being fairly new to Git still or a broken process.

If another dev is working on the test environment and I need to get something up to prod quickly, how can I make changes on test and merge it up to stage and then prod without including all of his changes with mine? I've used git cherry-pick but I'm unsure if this is the best route.

Thanks for your help

Upvotes: 1

Views: 67

Answers (2)

theDmi
theDmi

Reputation: 18034

Your solution works fine initially, but doesn't scale well.

A better approach is to separate deployment from source control. To get there, you need a release process that roughly follows these steps:

  • Create well-defined release packages that are not yet specific to an environment.
  • Define environments together with the configuration that is required for each environment.
  • Before deploying to a specific environment, apply the respective configuration. This turns a release into a deployment.
  • Upload the deployment to the environment in question.

This approach supports as many environments as you want. It also enables you to introduce rules such as "before deploying to the live system, we must deploy to QA".

Now that your release process is independent from the development process, you can use standard topic branching in Git to handle the situation you describe - each feature is developed on a different topic branch. So the other developer can deploy his topic branch to the test environment, and you remain completely unaffected from that.

Upvotes: 0

Bartek Banachewicz
Bartek Banachewicz

Reputation: 39370

Well, for one you could avoid "making changes on test".

I assume all branches spawn off the master. Create a branch urgent-hotfix, merge into test and see if it works in possible (that might include others' changes), then merge it straight to staging and prod.

The fact that those three are hooked to deployment doesn't mean that you can't have more branches, especially for hotfixes. My rule of thumb is "one-branch-per-developer" and it works rather well. Note that doesn't mean creating branches named as devs; it just means two devs won't work on the same branch.

For example, if I'm the only one making feature A, I'd make feature-A branch and commit directly to it. If there are more people working on feature-A, I'd make that first then branch another branch off it, called feature-A-part-A, commit to that one and merge working code into feature-A. I'm pretty sure you could adapt this to your scenario.

Upvotes: 3

Related Questions