GitHub Pull Request Workflow
The GitHub pull request work flow is a fundamental process for collaboration on projects hosted on GitHub.
Here's a step by step overview of the typical GitHub pull request workflow.
Sub Branches - A sub-branch is a copy of a main branch as it was at that point in time.
3. Committing Changes - With the branch created, we can make the necessary changes to existing code base. It can be fixing bugs, adding new features or making improvements. We can save the changes that we have done on the branch. On GitHub, saved changes are called "Commits". Each commit has an associated commit message, which is a description explaining why those changes have done. Commit messages capture the history of the changes that we have done. It will be helped other contributors to get an idea about what we have done in the codes.
Recommended by LinkedIn
README Files - All changes will be made only to README file on your branch, which is the first point of contact for anyone visiting the project's repository. While creating a repository, we can add README file.
4. Opening a Pull Request - Once all the changes are done on the sub-branch, we can open a pull request. By using GitHub's @mention feature, we can ask feedback from specific people. By opening a pull request, we are proposing our changes and requesting to someone review and pull our contribution and merge them to their branch. Pull requests show differences of the content from both branches in different colors.
5. Merging a Pull Request - After we merge our pull request, the changes on our sub-branch will be incorporated into the main branch.
Conflicts - Pull request may introduce changes to code that conflict with the existing code on the main branch. If there are any conflict, GitHub will give alert about the conflicting code and prevent merging until conflicts are resolved.