Cvetan's avatar

Git branching best practices

I was wondering about Git branching, for instance when starting a new project.

Let's say i am starting new Laravel project. I install Laravel to master branch. Open up development branch and start working.

When i have something ready i merge it to master branch. Is this good practice and should master branch contain production ready code?

0 likes
4 replies
tykus's avatar

For me, master is always production ready; so I will only ever merge into master when I will immediately deploy to production at the same time.

Other teams can/will have different strategies.

Cvetan's avatar

And what about development branch from my example? Is that good? Also do you tag releases from master branch?

matthijsvdorp's avatar
Level 1

We use Feature branches for new functionality bugfixes. Every new feature branch merges to develop. When we do a release to production we have one PR which merges develop into master.

For fixing bugs we create a bugfix branch from the master branch and merge these back to both master and develop.

This model is described on the follwing site if you want to take a closer look https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow

automica's avatar

An extension to using the feature branch workflow is GitFlow workflow. https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

"Gitflow is ideally suited for projects that have a scheduled release cycle. This workflow doesn’t add any new concepts or commands beyond what’s required for the Feature Branch Workflow. Instead, it assigns very specific roles to different branches and defines how and when they should interact. In addition to feature branches, it uses individual branches for preparing, maintaining, and recording releases. Of course, you also get to leverage all the benefits of the Feature Branch Workflow: pull requests, isolated experiments, and more efficient collaboration."

Please or to participate in this conversation.