Terms to understand

Branching

• By creating many branches we can maintain the VCS (Version Control Systems) of the project source code.
• The branching concept will help the team to create a new environment where they are free to experiment like implement new ideas, and fix bugs, and so on in progress at any given time, without making direct changes to the main branch.
• The newly created branch is a snapshot of the current branch you are in, but changes you make to it will not affect the main branch.

The branching is the core concept of git, so the entire GitHub flow completely depends upon the branch. Here anything in the Main branch is always deployable.

Commit

• After you have created a branch you can start making changes to it. When you add, modify, rename, move or delete a file you need to make a commit, and add them to your branch.
• The process of committing keeps track of your progress as you work on a feature branch.
• Each commit has an associated message with it, which explains why a particular change was made. Because of that, committing to a file creates a transparent history of what you did so others can follow up.
• Also, each commit is considered a separate unit of change. That means that if at some point a bug occurs in the code or if you have a new idea on how to do things that’s better than your current one, you can always go back to where you started.

Pull request

• The pull requests are a comparison of two branches of a single repository. After you have made your commits you can create a Pull Request to start a discussion about the commits that you made. Because the Pull Requests are tightly integrated with the Git repository, so anyone can see exactly what changes would be merged if they accept your request.
• The opening of a Pull request is quite easy and it can be done at any point during the development process. For example, you might have a very small amount of code, but you want to share the idea with your team, or when you're stuck and need help or advice, or when you're ready for someone to review your work, so they can give you suggestions or directions. After you’re pretty much sure that you’ve done all you can, you can open a Pull Request so others can view the work you’ve done and decide whether it’s alright.
• You can even notify specific people using the mention system. In that way, a specific person can be pinged that you can ask for feedback from specific people or teams by using syntax - @name in your Pull Request message.

• The Pull Requests are useful for contributing to open source projects and for managing changes to shared repositories and these are also very useful for the Fork & Pull Model. For example, your friend is developing an awesome application and you want to contribute to it. When you make a fork of your friend’s repository, GitHub will create a copy of its repo in your account. After you’ve made the changes and think that they might be relevant for your friend, you can open a Pull Request to start a discussion about that application. If your friend likes them, he can merge the changes.
• You can also consider using a Shared Repository model. Here basically when collaborators are granted push access to a single shared repo and the different branches are created when changes need to be made. In this model, the Pull Requests are an awesome way to start a conversation regarding the changes you would like to make to the project.

Discuss & review

• After you have made a Pull Request, the person or your team may have comments or disagreements so you might have to change something and make further commits to your branch and push up the changes.
• GitHub will display your new commits and any further feedback you might get in the unified Pull Request view.
• Pull Requests are designed to encourage and capture this kind of conversation.

Deploy

• In GitHub, you can deploy from a branch for end-to-end testing in production before merging to main.
• Once your pull request has been reviewed by team member and the branch passes your tests, you can deploy your changes to verify them in production like environment i.e. staging area.
• If your branch causes issues, you can roll it back by deploying the existing main branch into production.

Merging

• After testing the project in a staging environment, it's ready to move to production.
• For that we need to merge the development branch to the main branch and pull requests will store the historical changes of your code.