<p>We use Git for our VCS. We follow Trunk based development strategy.
Trunk-Based Development (TBD) is where all developers (for a particular deployable unit) commit to one shared branch under source-control. That branch is going to be colloquially known as trunk, perhaps even named “trunk”. 
 lie of omission</p>

<p>This trunk is always stable, but it can have unfinished features covered by feature toggles. This type of development works </p>

<ul>
<li>When you are just starting up </li>
<li>When you are iterating quickly</li>
</ul>

<p>In short, feature branches will give you better isolation, but require you to deal with the pain of deferred integration, and merges. Toggles give you continuous integration, but require you to design/implement your code in such a way that supports toggles, and introduce the risk that unfinished feature code could negatively affect production.</p>

CC BY-SA 4.0
2019-02-19T17:32:02.480Z
Do you have a separate branch for development / release and new features? Suppose say you made a release where the customer demands a hotfix, so in that case do you create a new branch? or you make the fix in the released branch? How do you manage such circumstance?
Vivek
CC BY-SA 4.0
2019-02-20T06:43:17.440Z
It's good to have a hotfix branch, which can branch off from mainline and merge back into integration branch and mainline. These branches are cut when there is a need for an immediate action upon an undesired state of a live production version. When a critical bug in a production version must be resolved immediately, a hotfix branch may be branched off from the corresponding tag on the master branch that marks the production version. The essence is that work of team members (on the develop branch) can continue, while another person is preparing a quick production fix.
Sunil
CC BY-SA 4.0
2019-02-12T08:19:00.013Z
2019-02-12T08:19:00.013Z
Sunil
<p>We are using SVN as our version control system and we are using the below standard layout for our projects.</p>

<pre><code>Tags
Branches
Trunk
</code></pre>

<p>Trunk:
    -> Trunk will always hold the latest code changes.</p>

<p>Branches:
    -> When a release is planned a new branch will be created from the trunk and worked upon. Once the same is released it will be tagged.</p>

<p>Tags:
    -> Now after the release if we notice any issues in the delivered application then we create a new branch from the tags and then it is worked upon. Finally, the changes made will be merged into the trunk. Or sometimes we make the fix on trunk first and then backport it.</p>

<p>Is this the standard approach? or is there any recommended best practice?</p>

<branch><subversion>
Recommended SVN branching strategy for DevOps
Vivek
# Recommended SVN branching strategy for DevOps

(Asked by: username_0 on 2019-02-12)

We are using SVN as our version control system and we are using the below standard layout for our projects.
Tags
Branches
Trunk

Trunk:
    -> Trunk will always hold the latest code changes.
Branches:
    -> When a release is planned a new branch will be created from the trunk and worked upon. Once the same is released it will be tagged.
Tags:
    -> Now after the release if we notice any issues in the delivered application then we create a new branch from the tags and then it is worked upon. Finally, the changes made will be merged into the trunk. Or sometimes we make the fix on trunk first and then backport it.
Is this the standard approach? or is there any recommended best practice?

**Tags:** branch, subversion


---

## 1 answers

### Answer by username_1 on 2019-02-12. Score: 0 | Accepted answer

We use Git for our VCS. We follow Trunk based development strategy.
Trunk-Based Development (TBD) is where all developers (for a particular deployable unit) commit to one shared branch under source-control. That branch is going to be colloquially known as trunk, perhaps even named “trunk”.
lie of omission

This trunk is always stable, but it can have unfinished features covered by feature toggles. This type of development works

* When you are just starting up
* When you are iterating quickly

In short, feature branches will give you better isolation, but require you to deal with the pain of deferred integration, and merges. Toggles give you continuous integration, but require you to design/implement your code in such a way that supports toggles, and introduce the risk that unfinished feature code could negatively affect production.

> **Comments:**
> **username_0**: Do you have a separate branch for development / release and new features? Suppose say you made a release where the customer demands a hotfix, so in that case do you create a new branch? or you make the fix in the released branch? How do you manage such circumstance?  
> **username_1**: It's good to have a hotfix branch, which can branch off from mainline and merge back into integration branch and mainline. These branches are cut when there is a need for an immediate action upon an undesired state of a live production version. When a critical bug in a production version must be resolved immediately, a hotfix branch may be branched off from the corresponding tag on the master branch that marks the production version. The essence is that work of team members (on the develop branch) can continue, while another person is preparing a quick production fix.  

---

