-
Notifications
You must be signed in to change notification settings - Fork 0
/
2.2-trunk-based-development.qmd
120 lines (84 loc) · 4.17 KB
/
2.2-trunk-based-development.qmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
---
title: "Advanced `git`"
subtitle: "Block 2.2: Trunk Based Development"
title-slide-attributes:
# Background by <https://unsplash.com/@tahamazandarani>
data-background-image: images/backgrounds/taha-mazandarani-eLTEuvma_vw-unsplash.jpg
data-background-color: black
data-background-opacity: "0.8"
data-background-position: bottom
---
## What is Trunk-Based Development?
> A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after.
From <https://trunkbaseddevelopment.com/>
## What is Trunk-Based Development?
> A source-control branching model, where developers collaborate on code in a **single branch** called ‘trunk’, **resist any pressure to create other long-lived development branches** by employing documented techniques.
>
> They therefore avoid merge hell, do not break the build, and **live happily ever after**.
From <https://trunkbaseddevelopment.com/>
## What is Trunk-Based Development?
- Development happens on a single main branch (trunk)
- At most short-lived feature branches
- Developers commit changes directly to the main / master branch
- Integrates with continuous integration and continuous delivery
## Brief Detour: CI / CD 🤖
- **Continuous Integration (CI)**
- Integration of changes from multiple developers into shared repository with automated testing.
- **Continuous Delivery / Deployment (CD)**
- Automated deployment of changes if previous tests pass.
::: {.fragment}
More on these later... ⏲️
:::
## How to Get Started with Trunk-Based Development
- Avoid long-lived branches
- Use a single `trunk` instead (doesn't need to be called so)
- Use feature-branches
- Merge / pull / push often and regularly
- Make sure that any changes you merge can build / run (!)
- Set up a CI/CD pipeline (⏲️)
## Advantages of Trunk-Based Development
1. **Faster Feedback**: Immediate integration identifies conflicts early
2. **Reduced Merge Issues**: Smaller, more frequent merges minimize conflicts
3. **Promotes Collaboration**: Encourages teamwork and shared code ownership
4. **Simplified Deployment**: Continuous integration allows for quicker releases
## Best Practices: feature-branches
- Work in separate branches for each new feature
- Keep them short lived
- Naming
- `feat-xyz`
- `<username>/feat-xyz`
## Best Practices
- **Feature Toggles**: Enable features selectively without affecting the main branch
- **Code Reviews**: Ensure high-quality code before merging to trunk
- **Automated Testing**: Comprehensive test suites to maintain code stability
- **Monitoring and Rollbacks**: Quickly identify issues and revert changes if necessary
## Further Reading 📚️
- <https://trunkbaseddevelopment.com/>
- <https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-based-development>
## gitflow 🌊
Formerly highly popular workflow, now a bit out of fashion.
- Development happens in `develop` branch
- Only releases e.g. `v1.2.1` in main / master
- Features also in feature-branches
- Branches are much longer lived
- Can lead to difficulties with merges
- Many more active branches in general
# Questions? {background-opacity="0.4" background-image="images/backgrounds/questions.gif" background-position="top"}
## Speaking of Best Practices: READMEs 📑
- First touch point for anyone coming to your project
- Markdown formatted file named `README`(`.md`) in root
- Should (almost) always be present
- Even if only used by you
Example: <https://github.com/pcottle/learnGitBranching>
## Practical: README 📚️ {background-color="black"}
1. Add a `README` to your `git-example` repository
- Examples
- <https://github.com/pcottle/learnGitBranching>
- <https://github.com/microsoft/vscode>
- <https://github.com/iterative/dvc>
## *End of Block* 🎉 {background-color="black" background-opacity="0.2" background-image="images/backgrounds/kaiser.jpg"}
:::{.r-fit-text}
Any Questions?
:::
[[🏡 Back to Overview]](./index.html)
[[⏩️ Next Block]](./3.1-github-CI-CD.html)