Like some companies add jira id to branch name.
We (Coherent Labs) are using git flow with some small modifications:
develop and master are locked. Only accepted (reviewed by two developers) PRs can be merged.
feature/<feature-name> - every new feature will have a prefix feature
fix/<bug-name> - fixes, regressions and quickfixes.
release/<release-version> - the release branches are ready for deployment, production tested code. All tests must be passing on the latest release branch.
tests/<test-related-code> - everything test related to our test automation infrastructure - our Selenium framework, test dependencies, unit, integration and GUI tests.
experimental/<experiment-name> - every reseach, POC (Point of Concept) and other related code are done in the experimental branches. These branches are never merged in develop or master and are removed once the "experiment" is over.
As for commit messages we are using the following model:
<Jira-issue-ID> <action-verb> <explanation>
<description (optional)>
For example:
[ED-666] fix exported JS code from the data-click attribute
On scene reopening, path strings were manipulated by the pathHandler method. We had to ignore paths coming from JS code in data-click. A RegExp check now filters which paths should be manipulated.
We have a Jira hook, which looks for the issue IDs in the commit messages, fetch all commits, PRs and branches and display them in the board. That way every developer and Project Manager can easily find and track the progress of the task.
Just like Marco, my team uses Git Flow:
master contains code that's currently run in production.release-x.x contains code of previous releases.develop contains code for the upcoming release.Depending on the type of code we're working on, we use different branch names with the following convention:
fix/{name of issue} contains code for bug fixes. Often with a version prefix like fix/1.0-{name of issue} to indicate what version the fix is for.feat/{name of feature} contains code for features.Currently, I am settling on GitFlow, which results in
Our (Team Hashnode) convention is quite similar to the one j mentioned.
We have two branches master and development; no direct modifications are made to these.
Side note: as soon as something is merged into
developmentall the changes are automatically deployed to a staging server, and are available to be tested, before they are pushed tomaster.
We generally branch out from the latest development branch; and branches are named in this pattern: <author>/<branch-type>/<branch-name>
Here are a few (recent) examples:
somu/perf/code-splittingalkshendra/feature/response-share-promptsai/misc/editor-experimentsbranches are constructed in the following matter
<type>/<developer>/<ticket-number>-<short-description>
feature/me/#123-adding-bla
bug/someoneelse/#124-fixing-bla
so in one year, if I'm really that slow to delete branches I can see
that's maybe overhead but I like it :)
Ya our projects we follow this branch naming conventions
1 - develop
2 - design
3 - master
4 - then name depending on the feature we are working on.
In my personal projects I follow following branch names, this is just a sample.
MAIN-DEV-WEB
MAIN-DEV-REST
MAIN-PROD-WEB
MAIN-PROD-REST
MAIN-DEV-WEB-FEATURENAME (This can be anything)
MAIN-DEV-REST-FEATURENAME
MAIN-PROD-WEB-HOTFIX
MAIN-PROD-REST-HOTFIX
This is just a sample, there are other names like integration branch, testing branch, versioning branch etc. This names depends upon the respective project.
Clément
We just started using something based on gitlab flow and I really prefer it versus the usual git flow we find. Here is the explanation: about.gitlab.com/2014/09/29/gitlab-flow
Basically the principle is less branch better it is. And upstream first so never need to think about merging something back...
We add on that release branches.
So any change is done in master through PR.
We have feature branch which could be deploy on our staging environment to let our QA department testing it before merging into master.
Master should always be minimum stable.
On day before release we create a release branch from master where QA does regression.
When a bug which need to be fix is found we still fixing it in master and cherry-pick into release branch.
When we release we merge to the production branch (only to have an history).
It is:
I hope it can help