Git Branching Workflows

Unfortunately we only branch on release. We don’t have separate branches. Consider it as everyone working on master, and no merges m, just code reviews.

Continuous integration AKA trunk based development is the workflow you want to have. Ensure you meet the prerequisites first though (reliable automated tests, solid code reviews, feature flags, etc).To be precise, small feature branches are perfectly fine. They are meant to be reviewed and squashed into master ("trunk") in a few hours to a few days maximum.Squashing instead of merging has a big advantage of being able to quickly revert the changes if things go awry despite all be

Or don't use branches at all. Develop on trunk/master with continuous integration. It reduces work-in-progress, exposes conflicts sooner and has a host of other knock-on benefits.

Yep. My team follows a similar workflow with Github - every feature, bugfix, etc is developed on a branch off of master, then merged back into master via pull request when it is ready for deploying.It's a nice workflow, changes are very visible to the entire team and well summarized (by the commit history and any comments/discussion on the pull request itself). Making a new branch is a one-line operation (two if you count hooking it up to the remote), so no, I've never personal

This seems to assume that everyone is committing into the same branch. How about the workflow where you create a new branch for each work package and merge it into the main branch when finished? It lets you check in to your own branch as often as you want (even broken code) without worrying about breaking anything for the other devs. The merges will be bigger though, days or weeks of work. A good point is that the branch merge is a natural time to look through all the diffs.

I've got a much nicer branching model- try not to have one. Everyone works off master, and you aren't allowed to check in code that won't run in production. Hide unfinished features behind feature flags, and never merge/push a change that won't pass tests/CI.The chaos of huge feature merges (a key source of bugs I've experienced) is minimized. You deploy fixes hourly, not weekly (or later monthly when it just won't seem to pass CI). The time between cod

I've worked on 10+ person teams over the past 5 years, on 10+ year old codebases with hundreds of thousands of lines. About 8-10 total years of software engineering experience in general. The best flow I've found, and the one my team uses now is:1. Make a branch from master called `yourName/featureName` 2. Work on the feature for a day or two max 3. Merge it right to masterCI/CD runs all the tests, builds it, deploys it to stage. All the other engineers and product peop

At my previous team (5-6 people worked simultaneously) we used CI & CD and we relied on feature flags, so we could merge our branches more often and make smaller pull requests on Github. Each part of the feature had its own branch with a clear goal and tests written for it (we never pushed to master, every time you start working on something, you create a branch prefixed with your initials, make a PR, merge after review and then do it all over again). Of course, master branch was always depl

It's rare to need to develop multiple features as concurrent branches, as long as you can release regularly.The practice that works really well is: just develop against master while running "git pull --rebase" regularly. Code review and then ship the feature, repeat. Use branches only for rare concurrent development, and only after the need has arisen (Git makes it trivial to move changes into a branch after the fact).

Consider forgoing long-lived/significant local branches too then. Branching has its downsides, and avoiding it has some upsides particularly for small teams. As an alternative, you might start using feature flags instead. Look into "continuous deployment" as well for more insight.