3 ms·

Since we're talking about naming branches, what are your preferred names for branches ? I like 4-letter names: - `main` points to the last release for librar

Since we're talking about naming branches, what are your preferred names for branches ? I like 4-letter names: - `main` points to the last release for libraries (along with tags for history) - `prod` points to production in deployable projects (not libraries) - `next` is the development branch for the next version - `deps` is a temporary branch for dependency updates, squashed and merged regularly onto `next`

dvdgsng 6y ago
Good for you that you found something that works for you. But why the random length restrictions to 4 chars, seems kind of outdated? Also, how does using only a "next" branch for development scale for teams (maybe using a fork-based workflow?). While I use a similar approach like yours on my personal projects, I still prefer the widely known and battle proven Git-Flow when working on agile teams: - master - develop (optional) - feature/* - release/* - bugfix/* (optional) - hotfix/*
- corobo 6y ago
  Git flow doesn't care what you call your branches.
  - dvdgsng 6y ago
    correct, it doesn't, but using a quite common scheme like this makes onboarding and reasoning about git-related issues easier. YMMV.
- franky47 6y ago
  I use this pattern mostly on solo projects and small OSS libraries, when working with clients in teams there is usually already a convention in place, most often just `master` and `develop`. I've never managed to find use in the "complexity" added by adhering strictly to GitFlow (maybe I'm working in too small teams), I don't find it suited to the continuous delivery method. I still use feature branches and hotfixes though. I much prefer a linear history, and use semantic-release to automate releases via commit message standardisation, which gets rid of the `release/*` pattern.
kevincox 6y ago
I generally have v0, v1, v2, ... as the main branch. All changes are made in feature branches (with unimportant naming) and are merged into the appropriate main branch. If we need to support releases then a v1.2 or similar branch is created for each release. Fixes are then added there (as well as the main branch usually). I generally don't create branches for prod or releases, just tags. I also don't have a `next` branch. Whatever is on the version branch is "next" to be released.

dvdgsng 6y ago

Good for you that you found something that works for you. But why the random length restrictions to 4 chars, seems kind of outdated? Also, how does using only a "next" branch for development scale for teams (maybe using a fork-based workflow?). While I use a similar approach like yours on my personal projects, I still prefer the widely known and battle proven Git-Flow when working on agile teams: - master - develop (optional) - feature/* - release/* - bugfix/* (optional) - hotfix/*

corobo 6y ago
Git flow doesn't care what you call your branches.
- dvdgsng 6y ago
  correct, it doesn't, but using a quite common scheme like this makes onboarding and reasoning about git-related issues easier. YMMV.
franky47 6y ago
I use this pattern mostly on solo projects and small OSS libraries, when working with clients in teams there is usually already a convention in place, most often just `master` and `develop`. I've never managed to find use in the "complexity" added by adhering strictly to GitFlow (maybe I'm working in too small teams), I don't find it suited to the continuous delivery method. I still use feature branches and hotfixes though. I much prefer a linear history, and use semantic-release to automate releases via commit message standardisation, which gets rid of the `release/*` pattern.

kevincox 6y ago

I generally have v0, v1, v2, ... as the main branch. All changes are made in feature branches (with unimportant naming) and are merged into the appropriate main branch. If we need to support releases then a v1.2 or similar branch is created for each release. Fixes are then added there (as well as the main branch usually). I generally don't create branches for prod or releases, just tags. I also don't have a `next` branch. Whatever is on the version branch is "next" to be released.