84 lines
5.4 KiB
YAML
84 lines
5.4 KiB
YAML
uuid:
|
|
- value: 394246dc-42f8-4fbd-987c-7b62c47b9f06
|
|
langcode:
|
|
- value: en
|
|
type:
|
|
- target_id: daily_email
|
|
target_type: node_type
|
|
target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
|
|
revision_timestamp:
|
|
- value: '2025-05-11T09:00:55+00:00'
|
|
revision_uid:
|
|
- target_type: user
|
|
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
|
|
revision_log: { }
|
|
status:
|
|
- value: true
|
|
uid:
|
|
- target_type: user
|
|
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
|
|
title:
|
|
- value: 'Why I like trunk-based development'
|
|
created:
|
|
- value: '2022-09-20T00:00:00+00:00'
|
|
changed:
|
|
- value: '2025-05-11T09:00:55+00:00'
|
|
promote:
|
|
- value: false
|
|
sticky:
|
|
- value: false
|
|
default_langcode:
|
|
- value: true
|
|
revision_translation_affected:
|
|
- value: true
|
|
path:
|
|
- alias: /daily/2022/09/20/why-like-trunk-based-development
|
|
langcode: en
|
|
body:
|
|
- value: |
|
|
<p>For the majority of my software development career, I've worked with version control in a very similar way.</p>
|
|
|
|
<p>There are one or two long-lived branches, usually a combination of <code>develop</code>, <code>master</code> or <code>main</code>, that contain the production version of the code. When starting work on a new feature or bug fix, a new branch is created where the changes are made in isolation, and is submitted for review once complete. This is typically referred to as "Git Flow" or "GitHub Flow".</p>
|
|
|
|
<p>Whilst those changes are awaiting review, a new task is started and the process is repeated.</p>
|
|
|
|
<h2 id="trunk-based-development">Trunk-based development</h2>
|
|
|
|
<p>Something that I've been practicing and advocating for lately is trunk-based development, where there's only one branch that everyone works on, and commits and pushes to instead of creating separate per-task branches.</p>
|
|
|
|
<p>Even on a client project where I was the only Developer, I was used to creating per-task branches and I can recall when trying to demo two features to a client and the application broke when switching between branches.</p>
|
|
|
|
<p>The vast majority of the time, whether working individually or on a team, I've found that the per-task branches weren't needed and working on a single branch was easier and simpler.</p>
|
|
|
|
<p>There are still occassions when a temporary branch is needed, but in general, all changes are made to the single branch.</p>
|
|
|
|
<p>Trunk-based development ties in nicely with the continuous integration approach, where everyone commits and pushes their work at least once a day - ideally, multiple times a day. This eliminates long-running feature or bug fix branches that get out of sync with the main branch as well as conflicting with each other.</p>
|
|
|
|
<p>It seemed scary to begin with, having been used to per-task branches and asynchronous peer reviews via pull or merge requests, but trunk-based development has made things simpler and encourages other best practices such as pair and mob programming. having a good CI pipeline to identify regressions, using feature flags to separate code deployments from feature releases, and frequent code integration and deployment via continuous commits and pushes.</p>
|
|
|
|
|
|
format: full_html
|
|
processed: |
|
|
<p>For the majority of my software development career, I've worked with version control in a very similar way.</p>
|
|
|
|
<p>There are one or two long-lived branches, usually a combination of <code>develop</code>, <code>master</code> or <code>main</code>, that contain the production version of the code. When starting work on a new feature or bug fix, a new branch is created where the changes are made in isolation, and is submitted for review once complete. This is typically referred to as "Git Flow" or "GitHub Flow".</p>
|
|
|
|
<p>Whilst those changes are awaiting review, a new task is started and the process is repeated.</p>
|
|
|
|
<h2 id="trunk-based-development">Trunk-based development</h2>
|
|
|
|
<p>Something that I've been practicing and advocating for lately is trunk-based development, where there's only one branch that everyone works on, and commits and pushes to instead of creating separate per-task branches.</p>
|
|
|
|
<p>Even on a client project where I was the only Developer, I was used to creating per-task branches and I can recall when trying to demo two features to a client and the application broke when switching between branches.</p>
|
|
|
|
<p>The vast majority of the time, whether working individually or on a team, I've found that the per-task branches weren't needed and working on a single branch was easier and simpler.</p>
|
|
|
|
<p>There are still occassions when a temporary branch is needed, but in general, all changes are made to the single branch.</p>
|
|
|
|
<p>Trunk-based development ties in nicely with the continuous integration approach, where everyone commits and pushes their work at least once a day - ideally, multiple times a day. This eliminates long-running feature or bug fix branches that get out of sync with the main branch as well as conflicting with each other.</p>
|
|
|
|
<p>It seemed scary to begin with, having been used to per-task branches and asynchronous peer reviews via pull or merge requests, but trunk-based development has made things simpler and encourages other best practices such as pair and mob programming. having a good CI pipeline to identify regressions, using feature flags to separate code deployments from feature releases, and frequent code integration and deployment via continuous commits and pushes.</p>
|
|
|
|
|
|
summary: null
|
|
field_daily_email_cta: { }
|