summaryrefslogtreecommitdiff
path: root/src/blog/2022-09-26.md
diff options
context:
space:
mode:
authoreug-vs <eugene@eug-vs.xyz>2022-10-01 17:44:14 +0300
committereug-vs <eugene@eug-vs.xyz>2022-10-01 17:44:14 +0300
commit9a6c3a5f8beb854df291dd8b0d0815787edb4838 (patch)
treedf6186783befde7336847f2dd2adcbf3901b4708 /src/blog/2022-09-26.md
parentb361d6b763ec1fbe7afe0b01b91e1b87f3552a3f (diff)
downloadeug-vs-xyz-9a6c3a5f8beb854df291dd8b0d0815787edb4838.tar.gz
blog: latest articles
Diffstat (limited to 'src/blog/2022-09-26.md')
-rw-r--r--src/blog/2022-09-26.md14
1 files changed, 14 insertions, 0 deletions
diff --git a/src/blog/2022-09-26.md b/src/blog/2022-09-26.md
new file mode 100644
index 0000000..2a8e8f8
--- /dev/null
+++ b/src/blog/2022-09-26.md
@@ -0,0 +1,14 @@
+# Branching sucks. Trunk-based development :git: will boost your project!
+I am now working on a cool startup and I'm really glad we adopt this model.
+
+## Trunk-based development :git:
+The idea of [trunk based development](https://trunkbaseddevelopment.com/) is to collaborate on a single branch called trunk and avoid creating long-lived branches.
+
+## Why is it so good?
+Trunk-based development helps to avoid many problems that extensive branching creates. Let's see why branching might be bad:
+ - Long-lived branches are a nightmare if you wanna move fast! Imagine a branch that is 4 days behind your trunk. Sometimes that might be more than 100 commits. Do you think you have any chance of merging that? This is unacceptable for a startup.
+ - Long-lived branches create multiple sources of truth. How do you know which changes to pick? But when you got your trunk it's deadly easy - it always represents the *current* state of your system - at any point in time! And it's guaranteed to work, especially if you practice continuous delivery.
+
+On top of that trunk-based development encourages you to rebase often. This means developers always have a clear view of how their changes interact with everyone else's changes.
+
+It also offers you an opportunity to skip Pull Requests entirely! This is an insane boost to development, but it only works if the developers trust each other and communicate frequently enough. If you do pair programming, there's really no need to do any code review!