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.

  • Git server side hook not firing - how to check
  • Will merge be available in libgit2sharp?
  • Git / Github : Commit got lost
  • How to conclude your merge of a file?
  • Sharing git repo on NTFS partition between Linux/Windows dualboot
  • codenvy: How to create a persistent file?
  • 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

  • Raspberry Pi and GitLab
  • Where are the project files stored in a git repository `.git` folder?
  • Automatically resolve conflict on git for given file
  • Why is git svn show-ignore / show-externals so slow?
  • Rebasing a branch with sub-branches all at once
  • How to `git show` on a file that was renamed after specified revision?
  • 2 Solutions collect form web for “How to Manage Git Branches that Reflect Testing Environments”

    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.

    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.

    Git Baby is a git and github fan, let's start git clone.