oliverdavies.uk/content/node.aba09cf2-f67c-4056-b503-5a53399e634b.yml

uuid:
  - value: aba09cf2-f67c-4056-b503-5a53399e634b
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:16+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: 'How I Git'
created:
  - value: '2024-03-29T00:00:00+00:00'
changed:
  - value: '2025-05-11T09:00:16+00:00'
promote:
  - value: false
sticky:
  - value: false
default_langcode:
  - value: true
revision_translation_affected:
  - value: true
path:
  - alias: /daily/2024/03/29/how-i-git
    langcode: en
body:
  - value: |
      <p>After <a href="/daily/2024/03/27/hotfixing-without-branches">Wednesday's email</a>, someone said, "It sounds like you and I use git very differently." So, I wanted to explain what my typical Git workflow is.</p>

      <p>I used to use Git Flow, but now, I almost never create a new branch when starting a new task.</p>

      <p>I keep my workflow as simple as possible by using trunk-based development and working on a single branch as much as I can.</p>

      <p>Before I start, I make sure any uncommitted changes are committed or reset and that the automated tests, static analysis, coding standards checks, etc., are passing so I know I'm starting from a good place.</p>

      <p>Then, I start working on the task.</p>

      <p>I like to work in small steps and make small, regular commits, but I don't always push each individual commit to the remote repository.</p>

      <p>Sometimes, I'll make a number of "work in progress" commits and squash them into one before pushing them.</p>

      <p>I want the time between making and pushing the commit to be as short as possible, and I want each commit to be deployable.</p>

      <p>If I'm doing test-driven development, I'll typically commit each time a test is passing - whether it's adding a new test or extending one.</p>

      <p>I run any tests often whilst writing code to ensure they pass, either using a watch command or a keybinding in Neovim.</p>

      <p>I won't push a commit that would cause the code to not work, a test to fail, or block any other (potentially more urgent) changes from being pushed to production.</p>

      <p>If I push a commit that breaks the CI pipeline, I'll fix it quickly, which is usually possible as the changes are small.</p>

      <p>If not, I'll revert the commit to get back to a deployable state as quickly as possible.</p>

      <p>If I'm going to add a feature flag, I'll usually know that in advance and avoid rushing to add one later if a more urgent task comes in.</p>

      <p>By keeping each commit in a working and deployable state, a change can be feature flagged and deployed but not activated until the feature flag is enabled.</p>

              
    format: full_html
    processed: |
      <p>After <a href="/daily/2024/03/27/hotfixing-without-branches">Wednesday's email</a>, someone said, "It sounds like you and I use git very differently." So, I wanted to explain what my typical Git workflow is.</p>

      <p>I used to use Git Flow, but now, I almost never create a new branch when starting a new task.</p>

      <p>I keep my workflow as simple as possible by using trunk-based development and working on a single branch as much as I can.</p>

      <p>Before I start, I make sure any uncommitted changes are committed or reset and that the automated tests, static analysis, coding standards checks, etc., are passing so I know I'm starting from a good place.</p>

      <p>Then, I start working on the task.</p>

      <p>I like to work in small steps and make small, regular commits, but I don't always push each individual commit to the remote repository.</p>

      <p>Sometimes, I'll make a number of "work in progress" commits and squash them into one before pushing them.</p>

      <p>I want the time between making and pushing the commit to be as short as possible, and I want each commit to be deployable.</p>

      <p>If I'm doing test-driven development, I'll typically commit each time a test is passing - whether it's adding a new test or extending one.</p>

      <p>I run any tests often whilst writing code to ensure they pass, either using a watch command or a keybinding in Neovim.</p>

      <p>I won't push a commit that would cause the code to not work, a test to fail, or block any other (potentially more urgent) changes from being pushed to production.</p>

      <p>If I push a commit that breaks the CI pipeline, I'll fix it quickly, which is usually possible as the changes are small.</p>

      <p>If not, I'll revert the commit to get back to a deployable state as quickly as possible.</p>

      <p>If I'm going to add a feature flag, I'll usually know that in advance and avoid rushing to add one later if a more urgent task comes in.</p>

      <p>By keeping each commit in a working and deployable state, a change can be feature flagged and deployed but not activated until the feature flag is enabled.</p>

              
    summary: null
field_daily_email_cta: {  }