Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2019-02-19T17:32:02.480Z
Answers: 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?
Answers: Vivek
Answers: CC BY-SA 4.0
Answers: 2019-02-20T06:43:17.440Z
Answers: 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.
Answers: Sunil
Answers: CC BY-SA 4.0
Answers: 2019-02-12T08:19:00.013Z
Answers: 2019-02-12T08:19:00.013Z
Answers: Sunil
Body: <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>
  
Tags: <branch><subversion>
Title: Recommended SVN branching strategy for DevOps
UserDisplayName: Vivek
ThreadText: # 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.  
  
  ---
  
  