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 development all the changes are automatically deployed to a staging server, and are available to be tested, before they are pushed to master.
We generally branch out from the latest development branch; and branches are named in this pattern: <author>/<branch-type>/<branch-name>
Even we follow the same procedure exactly making our production branch and latest stable branch as protected and people review the code before they can be merged. We run the build and check if the code is as per expected standards and then the pull request gets merged. And regarding the names we almost use the same thing <Sprint>+<Jira id>
Jitendra, <author> is for maintaining a point-of-contact context, if we ever run into any roadblock with that particular branch.
Also, if you ever want to switch to a branch of an author, you don't need to remember the exact branch name, you can just find it from a list, like so: git branch --list 'sid/feature/*'. And when you know that this feature has something to do, say with the feed, you can zero in on the result even more quickly: git branch --list 'sid/feature/*-feed'
This is especially helpful when you have a long list of branches.
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.
Commit message convention
As for commit messages we are using the following model:
[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.
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.
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:
master
production
release/4.0.0
feature/{jira-story-code}
personal branch for example for john doe would be jdoe/{jira-code}
Sai Kishore Komanduri
Engineering an eGovernance Product | Hashnode Alumnus | I love pixel art
May 18, 2017
Our (Team Hashnode) convention is quite similar to the one j mentioned.
We have two branches
master
anddevelopment
; no direct modifications are made to these.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-splitting
alkshendra/feature/response-share-prompt
sai/misc/editor-experiments
klvenky
May 25, 2017
Even we follow the same procedure exactly making our production branch and latest stable branch as protected and people review the code before they can be merged. We run the build and check if the code is as per expected standards and then the pull request gets merged. And regarding the names we almost use the same thing <Sprint>+<Jira id>
Sai Kishore Komanduri
May 25, 2017
Jitendra,
<author>
is for maintaining a point-of-contact context, if we ever run into any roadblock with that particular branch.Also, if you ever want to switch to a branch of an author, you don't need to remember the exact branch name, you can just find it from a list, like so:
git branch --list 'sid/feature/*'
. And when you know that this feature has something to do, say with the feed, you can zero in on the result even more quickly:git branch --list 'sid/feature/*-feed'
This is especially helpful when you have a long list of branches.
Kleo Petrov
Professional human being for 29 years
May 18, 2017
Branching convention
We (Coherent Labs) are using git flow with some small modifications:
develop
andmaster
are locked. Only accepted (reviewed by two developers) PRs can be merged.feature/<feature-name>
- every new feature will have a prefixfeature
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.Commit message convention
As for commit messages we are using the following model:
<Jira-issue-ID> <action-verb> <explanation> <description (optional)>
For example:
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.
Marco Alka
Software Engineer, Technical Consultant & Mentor
May 18, 2017
Currently, I am settling on GitFlow, which results in
Pratik Upacharya
Your Problem Solver
May 17, 2017
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.
Stephan de Vries
Full stack developer, enthusiastic about new technologies.
May 18, 2017
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 likefix/1.0-{name of issue}
to indicate what version the fix is for.feat/{name of feature}
contains code for features.j
stuff ;)
May 17, 2017
branches 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 :)
Mgbako John
Full Stack Developer
May 17, 2017
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.
Clément
May 25, 2017
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