I am using Github Actions to build and deploy my website when I push. That is a classic continuous integration / continuous deployment workflow. It’s convenient to commit, push, and have my site build and deploy as a result. This workflow is simple but only works because I am the only contributor.
It is a good practice to run sanity checks on pull requests prior to merging. How would that be accomplished with Github Actions?
It turns out that you can do this but you need to be very intentional with how your jobs are configured.
In my workflow, I am designating a main branch
main that will run full CI/CD. Build, test, and deploy. And for any other branch, just build and test. …
Want to migrate your git branches from
main? Your branch protections, in-progress PRs, and drafts can migrate safely. Follow this simple checklist to confidently make these changes and create a seamless experience for yourself and your developer community.
If you have existing git repos at Github (or any other git hosting platform), you probably have a branch in your repo named
master. Starting October 1st, 2020, Github will officially stop their practice of naming the first branch of new repositories
master. Instead, the name
main will be used from now on.
The usage of
master is unfortunately deeply ingrained into those who learned how to use git and developed muscle memory. But did you know that Git (the tool) has no technical requirement that you use
master as your default branch name? However, because it is the first branch created when you run
git init, it's often the default used. As a result, hosting platforms such as Github or continuous integration systems like Jenkins or TravisCI create workflows that typically use these defaults as release branches. …