2

Current Process Flow :

Currently i am having four Git branches master, prod, stage and dev.

The commit goes in this order:

  • all the development commits goes to the dev branch at the end of each sprint or ticket all the dev commits will be manually merged to a release branch by the respective developers and given as a single commit revision.

  • The release team will take the single change-set done at the release branch for releasing the story to stage for Q.A (No test environment is created for Q.A till now)

  • And finally, during the releases, the stage and prod will be merged and a unique tag is created and deployed in the production.

Issue :

Currently the master is synced with the stage environment but since we do not have a test environment Q.A is done at this branch and the branch is not a stable one.

I really need to know : The master should be synced up with which environment (dev, stage or prod)..?

Please help me on this.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
Bala Varadarajan
  • 514
  • 1
  • 5
  • 17
  • 2
    Maybe this link about a successful branching setup may help you: http://nvie.com/posts/a-successful-git-branching-model/ – veelen Jan 09 '14 at 08:08
  • Branching per environment is a continuous delivery anti-pattern. Ideally, you have a single branch that represents a deployable version of your software, and you build, test, and deploy that version through your series of environments via automation. The GitFlow and GitHubFlow patterns mentioned in the comment above are excellent starting points. – Daniel Mann Jul 16 '22 at 15:52

1 Answers1

1

Ideally:

  • master (2014) or these days (2020+) main should always representing production ie no need for prod.
  • (pre-)release branch (or "stage") is a good place for the staging process (where you integrates commits that are eligible to go to the next release) and for QA to do its tests.
    If QA has any modification to make, it should then make a dedicated branch.
  • a classic release branch is done after the release to manage the hot fixes

But the main idea remains: if you clone a repository, you get by default the main branch (Cf. the Git 2.28 (Q3 2020) init.defaultBranch configuration), and that should show you what is currently running in production, allowing you to start debugging/fixing quickly.

See also gitworkflow to manage those branches.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks Vonc. I had a same idea and communicated to the team but no one accepting here... frustrated...!! – Bala Varadarajan Jan 09 '14 at 08:05
  • @BalaVaradarajan yes, my proposition is a bit similar to http://nvie.com/posts/a-successful-git-branching-model/. But I would be interesting in the reason for the team's refusal. – VonC Jan 09 '14 at 08:10
  • first thank you for this answer, looks like this days master is not the default branch and all moved to main, I think you should consider it in the answer. – talsibony Jul 16 '22 at 14:50
  • 1
    @talsibony Good point. I have updated this 8 years-old answer, also adding the new `init.defaultBranch` setting. – VonC Jul 16 '22 at 15:16