Collaborating on GitHub - Full Stack Web Dev Bootcamp Day 3 (2024-06-19)

In this lesson we go over how you can contribute code on GitHub. You learn how to go about finding an issue to work on, getting assigned, then submitting code changes.
GitHub can be used as an open-source collaboration tool where anyone can find other people's projects to contribute to. It doesn't necessarily have to be just code. It could be contributions in the form of submitting issues such as bug reports, feature requests, etc. You could also contribute to the documentation and guides.
In the golden days of GitHub, employers would actively look into the developer's GitHub profile to see what they have been working on. The profile page usually has things like the contribution graph and what you have been working on lately in the activity section.
GitHub is also widely used by companies and part of their software development life cycle. Although not necessarily open to everyone, the codebase is shared and open to the company at large, in a practice usually known as inner source. Because open source practices are applied to the closed company setting.
Teams often use features like the Projects board to navigate their Agile process, to see what everyone's been up to. Usually there are standup meetings for that. The kanban kind of board allows the team to know who's working on what and the status of those tasks.
In the open source setting, you can find Issues to work on. But it's important you first ask to work on it and get assigned. Don't just work on it without being assigned because multiple people could do that and waste time doing the same thing. Only start the task after commenting and being assigned to the issue. This practice might not apply if you are working in a company because you already have permission to the repositories and you already know what you should be working on, therefore assigning yourself without asking for another person is okay in that situation.
The lecture shows how you can contribute to somebody else's project. Since you don't have permission to change the code directly, you have to create your own copy, called a fork. Remember, a fork is a feature from GitHub, not from Git.
After making changes to your own copy, you can then propose changes to the original repository via a pull request.
A person will then review the code and leave any feedback if applicable. That is called the code review process. After addressing any feedback, any further changes to the code are reflected in the existing pull request. You don't have to create a new pull request.
The code reviewer will then approve the proposed changes.
From there on, either the reviewer or the one who proposed the changes could merge the pull request. In the open source setting usually the maintainer would do it since the one who proposed the changes doesn't usually have permission to the original repository. In the company setting it could be either person, depending on the team/company process.
In the pull request phase, usually builds are run to ensure the quality of the proposed changes. This is called continuous integration (CI). Tests, linters, etc, would run to ensure the proposed changes are okay to be merged in.
After the new code is integrated into the master branch of the original branch, the application, if there was one, would usually be deployed to production, where the public at large would have access to, and see the new feature or bug fix. That is usually automated using continuous deployment (CD).