Hey everyone! I'm diving into using GitHub Actions for my application, but I'm feeling a bit lost when it comes to setting up continuous integration (CI) properly. I have a few branches: 'develop', 'feature/mail-sender', and 'main' (which is for production). I'm curious about your experiences and opinions on which branch I should set up for testing. Should I only test when merging 'feature/mail-sender' into 'develop', or when I merge 'develop' into 'main'? Or should I consider testing on both branches? I'd appreciate your insights on the best approach!
4 Answers
You should test everything but deploy only from the 'main' branch. That way, your configuration might look something like this:
```yaml
on:
push:
branches: ["main", "develop"]
pull_request:
branches: ["main", "develop"]
```
This way, you can catch any issues in 'feature/mail-sender' before they hit production, rather than dealing with angry customers later!
Run CI/CD on every commit pushed to ensure automatic tests happen consistently. If you're following trunk-based development, any merge or commit to 'main' should trigger a full release cycle. But if you stick with tagged releases, use a pattern like semver for running full releases.
In my opinion, there isn’t just one branch that works best. You want to think about 'main' and other branches that will eventually merge into it. The idea is to build on both branches to ensure your commits are stable. When you're ready to release, you can tag the appropriate commit on 'main'. It depends on the size of your project; if it's just you, using commit hashes might be the simplest way to go. For larger projects, stick to something like trunk-based development with more CI validations, like tests and scans.
Start off simple! You could set it up to run tests on any push to any branch, then as you get comfortable, look into specific environments in GitHub for tailored testing and deployments. Just begin with what you actually need and build from there.

I totally agree! The places I've worked that followed trunk-based development had a much smoother process for everyone involved.