In this video, learn the foundational building block that is the GitHub workflow.
- [Instructor] The GitHub Flow starts with a master branch. Now, the only special thing about this master branch is that it's the first branch Git creates when it starts to verge or control a project. Now because of this, and for most projects, it's usually designated as the production branch, so any changes that occur on this master branch are now live on production. This branch, of course, can be really any branch, it doesn't have to be the master branch. But most projects will keep and designate this branch as the version of their project that is deployed into this production environment. Now, when it comes to making changes to your project, now whether that's a hot fix change, a feature addition, or a bug fix, it doesn't make a lot of sense to make those changes directly on this master branch, that's going live to production. So, when I want to make these changes I want to make a new line of work, a new timeline if you will, that represents these new changes that I want to make. Changes you make on a branch don't affect the master branch, so you're free to experiment and commit changes, and safe in the knowledge that your branch won't be merged until it's ready to be reviewed by someone that you're collaborating with. Once your branch has been created it's time to start making changes. So, whenever you add, edit or delete a file you're making a commit, and adding them to your branch. Commits also create a transparent history of your work that others can follow to understand what you've done and why. Each commit has an associated commit message with a description explaining why your particular change was made. This is important when you want to look at previous changes to your project. After you add your changes in the form of commits it's time to open up a pull request. A pull request starts the discussions and reviews of your commits. Now, this is basically you saying that you have some changes you've made and you want to add them to the master branch. You can open up a pull request at any point during this development process. Now, I've seen that a lot of people wait to open up a pull request until they've made all of the changes they want to make in their branch, before ever letting others look at their code changes. I've found that it's best to open up your pull request as early as possible in the process so you can start those discussions about your changes with your team members before you've made all of them. If you need to go in a different direction, well, it would have been nice to hear that feedback before you made all of the changes in the wrong direction. We'll talk more about this later when we dive into customizing workflows. After you've opened your pull request, and have received feedback, and made the needed changes based on that feedback that you received, you can deploy your branch for final testing, and to verify those changes in production. And once verified, you can then merge your branch into the master branch to then incorporate your changes into production.
- Designing your delivery pipeline
- Enabling continuous integration (CI)
- Adding automated builds
- Making changes based on code reviews
- Adding unit testing
- Adding continuous delivery to your CI pipeline
- Examining commit relationships in Git
- Working with branches in Git
- Reverting changes
- Troubleshooting in Git
- Resolving merge conflicts
- Fine-tuning the GitHub flow
- Adopting an inner-source culture