In most tutorials and most repositories it is recommended to fork a repository and make the changes you want to make on a new branch. Why is this?

CodePudding user response：

Typically, when you're working on a project as an external contributor, you preserve the main branch to match that of the upstream repository. This makes it easier to pull in changes without introducing conflicts or unwanted merge commits.

Additionally, you generally want to create a feature branch every time you work on a different feature because you don't want to commingle code for different features and you want to be able to work on multiple feature branches at once. For example, if you have two changes to make, you might make one on its own feature branch, open a pull request for it, and then start on another branch before the original one is merged.

CodePudding user response：

It is not a technical requirement. Rather it is a good working practice to keep incomplete code out of the main branch.

By working on a new branch, you can save and test your progress (commit to the branch) without affecting the main branch. This provides a safe working space that will not break the main branch until you are ready to merge back to main.

When you are satisfied with the work on your branch you can merge back into the main branch.

This also also makes it easy to throw away your branch if you do not want to keep it. Deleting the new branch will not affect any work that happened on the main branch.

If you are the only one working on the project, it may seem silly. It remains a good practice. Larger projects will have activity happening on the main branch and should not include incomplete or untested code. Keep your drafts on a working branch and off the main branch.