<p>You can still use pull requests with <a href="https://trunkbaseddevelopment.com/" rel="nofollow noreferrer">Trunk-Based Development</a>. Especially with larger teams, using <a href="https://trunkbaseddevelopment.com/short-lived-feature-branches/" rel="nofollow noreferrer">short-lived feature branches</a>, you would open a pull request into the trunk, which would start the build process. Depending on your environment and desire to have rapid merges, you could merge the pull request automatically, perhaps based on things like no new style violations, sufficient code coverage, tests pass, and no new static analysis violations, and defer the human review for later.</p>

CC BY-SA 4.0
2022-05-04T12:09:25.930Z
Is that still trunk based though? Your suggestion sounds like people should create feature branches rather than committing directly to main, which is our current situation.
James Geddes
CC BY-SA 4.0
2022-05-04T13:27:26.057Z
@JamesGeddes Did you see what site the links point to? Yes, that's from the definition of trunk-based development.
Thomas Owens
CC BY-SA 4.0
2022-05-04T14:19:35.627Z
I did, however not committing to main is surely not pure trunk based dev https://youtu.be/ASOSEiJCyEM
James Geddes
CC BY-SA 4.0
2022-05-04T14:56:48.407Z
@JamesGeddes In that video, Dave Farley is talking about human-gated pull requests. I mentioned this in my answer - you can still use pull request tools (like GitHub, Bitbucket, and perhaps others) to perform automated checks and automatically merge, while deferring human reviews for later. However, there is no way to both commit to trunk _and_ run your pipeline before a merge. You need to decide what is more important - waiting a short period of time (hopefully minutes) to get your automated results and merging or integrating faster and getting results later.
Thomas Owens
CC BY-SA 4.0
2022-05-04T15:00:22.927Z
Ah with you. I thought Dave Farley is saying that all PRs are always evil. Automated testing ftw.
James Geddes
CC BY-SA 4.0
2022-05-04T15:06:29.370Z
@JamesGeddes I'd have to rewatch that video to be 100%, but I watched it when it came out (his channel is great). I highly doubt he'd object to your pipeline blocking a merge, but I suspect he's say that you should be aiming to get your branch into main (meaning it passes the pipeline) within a day or two of opening it. That also has implications for how long your pipeline should take to execute - 10 or 15 minutes could be a very long pipeline. You can always defer more to post-merge - it's all about balancing ensuring quality, reducing risk, and letting people use your changes to buildon.
Thomas Owens
CC BY-SA 4.0
2022-09-07T20:11:07.803Z
@JamesGeddes From a purely Git perspective, this debate is kind of funny. In Git, a branch is a pointer to a commit that has a name. If the "trunk" is called `main` on the remote, and you call your local branch `main`, then it's TBD. If you rename your local branch to `my-branch` then TBD magically changes into "Feature Branch Workflow", which is also known as GitHub Flow and many other popular CI workflows.  PR's are fine, just temporarily rename (or copy) your local `main` to something else and push it out so you can use the PR tool functionality, if you want to.
TTT
CC BY-SA 4.0
2022-05-04T09:41:33.250Z
2022-05-04T09:41:33.250Z
Thomas Owens
<p>Currently, we use a simple branching strategy, with a single main branch and one layer of feature branches; no branches on branches on branches. We also have many pipelines that run against each PR to check the code before it is merged to the main branch, including but not limited to,</p>
<ul>
<li>code quality</li>
<li>linting</li>
<li>security assurance</li>
</ul>
<p>In a trunk-based approach, how does one run these tests before code is merged, without a PR?</p>
<p>I have seen <a href="https://devops.stackexchange.com/q/9855/30208">Trunk Based Development - release branch testing</a> but it did not fully answer my question. Thanks in advance for your patience with a n00b question :D</p>

<git><automation><testing><tdd>
How can you do pre-merge testing in trunk based development?
James Geddes
# How can you do pre-merge testing in trunk based development?

(Asked by: username_0 on 2022-05-04)

Currently, we use a simple branching strategy, with a single main branch and one layer of feature branches; no branches on branches on branches. We also have many pipelines that run against each PR to check the code before it is merged to the main branch, including but not limited to,

* code quality
* linting
* security assurance

In a trunk-based approach, how does one run these tests before code is merged, without a PR?

I have seen [Trunk Based Development - release branch testing](https://devops.stackexchange.com/q/9855/30208) but it did not fully answer my question. Thanks in advance for your patience with a n00b question :D

**Tags:** git, automation, testing, tdd


---

## 1 answers

### Answer by username_1 on 2022-05-04. Score: 2

You can still use pull requests with [Trunk-Based Development](https://trunkbaseddevelopment.com/). Especially with larger teams, using [short-lived feature branches](https://trunkbaseddevelopment.com/short-lived-feature-branches/), you would open a pull request into the trunk, which would start the build process. Depending on your environment and desire to have rapid merges, you could merge the pull request automatically, perhaps based on things like no new style violations, sufficient code coverage, tests pass, and no new static analysis violations, and defer the human review for later.

> **Comments:**
> **username_0**: Is that still trunk based though? Your suggestion sounds like people should create feature branches rather than committing directly to main, which is our current situation.  
> **username_1**: @JamesGeddes Did you see what site the links point to? Yes, that's from the definition of trunk-based development.  
> **username_0**: I did, however not committing to main is surely not pure trunk based dev https://youtu.be/ASOSEiJCyEM  
> **username_1**: @JamesGeddes In that video, Dave Farley is talking about human-gated pull requests. I mentioned this in my answer - you can still use pull request tools (like GitHub, Bitbucket, and perhaps others) to perform automated checks and automatically merge, while deferring human reviews for later. However, there is no way to both commit to trunk _and_ run your pipeline before a merge. You need to decide what is more important - waiting a short period of time (hopefully minutes) to get your automated results and merging or integrating faster and getting results later.  
> **username_0**: Ah with you. I thought Dave Farley is saying that all PRs are always evil. Automated testing ftw.  
> **username_1**: @JamesGeddes I'd have to rewatch that video to be 100%, but I watched it when it came out (his channel is great). I highly doubt he'd object to your pipeline blocking a merge, but I suspect he's say that you should be aiming to get your branch into main (meaning it passes the pipeline) within a day or two of opening it. That also has implications for how long your pipeline should take to execute - 10 or 15 minutes could be a very long pipeline. You can always defer more to post-merge - it's all about balancing ensuring quality, reducing risk, and letting people use your changes to buildon.  
> **username_2**: @JamesGeddes From a purely Git perspective, this debate is kind of funny. In Git, a branch is a pointer to a commit that has a name. If the "trunk" is called `main` on the remote, and you call your local branch `main`, then it's TBD. If you rename your local branch to `my-branch` then TBD magically changes into "Feature Branch Workflow", which is also known as GitHub Flow and many other popular CI workflows.  PR's are fine, just temporarily rename (or copy) your local `main` to something else and push it out so you can use the PR tool functionality, if you want to.  

---

