Skip to main content

Git Branching Models

In Git repository you can use branching models to define a branch workflow for repositories. When you map your workflow to repository branches with a branching model, admins can guide developers to name branches consistently by configuring which branch types to make available. There are a number of branch types available, and several branch types have default branch naming prefixes (described below). You can also specify your own naming convention for each branch type. A consistent naming convention makes it easier to identify branches by type.

Branch types

Bitbucket Server comes with several types of branches that are frequently used in software development. This section explains what each branch type is for, and has the typical naming convention for the prefix for each branch type. The prefix can be changed for each branch type.

Development branch

Usually the integration branch for feature work and is often the default branch or a named branch. For pull request workflows, the branch where new feature branches are targeted.

develop

Production branch

Used for deploying a release. Branches from, and merges back into, the development branch. In a Gitflow-based workflow it is used to prepare for a new production release.

master

Feature branch

Used for specific feature work or improvements. Generally branch from, and merge back into, the development branch using pull requests.

feature/

Release branch

Used for release task and long-term maintenance versions. They branch from, and merge back into, the development branch. Merging into an older release branch can be configured to automatically merge to newer release branches, as well as the development branch.

release/

Bugfix branch

Typically used to fix Release branches.

 bugfix/

Hotfix branch

Used to quickly fix a Production branch without interrupting changes in the development branch. In a Gitflow-based workflow, changes are usually merged into the production and development branches.

hotfix/

Good to know:

  • New repositories will have the branching model enabled by default, and use the default branch prefixes.
  • Enabled branch types can't have empty prefixes, have a 30 character limit, and can't overlap (for example PROD and PRODUCT would overlap).

Comments

Post a Comment

Popular posts from this blog

Unlock protected blocks in Siemens SIMATIC Step 7

Recently I'd been called by Hindalco's Fabrication Plant division to unlock the protected blocks in Siemens SIMATIC Step 7. They were in need to unlock those blocks since an year because of 1 million Rupees of loss per month. They want to re-program those blocks but it was locked by the man who'd done the setup. From the people working in that department, I came to know that they were trying to call that man (someone from Italy) right here but he's not coming. Actually, what he'd done was that he'd locked some of the blocks and deleted the source file. And Siemens didn't provide any feature to unlock. Department people also told me that even the people working in Siemens don't know how to do it. Being a software engineer I know that any thing can be reverse engineered. So I took up the challenge. How did I unlocked the blocks? The first thing I'd done was searched about this software at Google and read about what is this software all about. Aft
50 comments
Read more

JS: The complete code example of Crypto.js (DES)

For one of the project I was trying to use crypto.js but I found that the Quick-start Guide have some deficiency in terms of library usage. So I am writing it here as a useful note for memory recap. <script src="http://crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups/tripledes.js"></script> <script> var encrypted = CryptoJS.DES.encrypt("The secret message", "secret_key"); var e_msg = encrypted.toString(); console.log(e_msg); var decrypted = CryptoJS.DES.decrypt(e_msg, "secret_key"); var d_msg = decrypted.toString(CryptoJS.enc.Utf8); console.log(d_msg); </script>
4 comments
Read more

How to convert JIRA story into sub-task or defect?

Many times we entangled in the situation where we have made a  story  in JIRA but later on realised that it should have to be  defect  or in other case,  sub-task  of another  story . Story → Sub-task So the workaround for converting the story into defect is given below: Open your  story Click on  more  option Click on the  Convert to sub-task  option in the dropdown You would be asked to choose  Parent  story, so chose relevant story After submit, your  story  gets converted into  sub-task Story → Defect Now if you want the story to be converted into defect, then you should first convert it into sub-task. Thereafter, you can convert that sub-task into defect as given below: Open the  sub-task Click on  more  option Click on the  Convert to issue  option in the dropdown You would be asked to fill up relevant fields required for raising a  defect , fill them up as required After submit, your  sub-task  gets converted into  defect .
Post a Comment
Read more