After creating a personal branch for a Git project, is it best to keep only work that I eventually plan to merge into the main branch? What is the usual way to handle experiments, prototypes, test files, or other changes that should remain purely local and never be uploaded?
4 Answers
Branches are cheap, so a common workflow is to create a temporary branch for experiments and another clean branch for the actual feature. You can also reset or delete the temporary branch once you are finished. If an experiment becomes useful, move the relevant commit to the proper branch with cherry-pick or by rebasing.
There is no requirement that every branch eventually be merged. A local branch can be a sandbox, and a shared branch can contain only the work intended for review. The important part is keeping experimental commits separate from the branch you plan to merge, especially if other people will see or build from it.
A branch is yours to use as you like. Local, uncommitted experiments will not be included when you create a pull request. You can leave them uncommitted, stash them temporarily, or put them in a separate local branch. Just avoid committing secrets or credentials.
A pull request is based on the commits that exist on the branch compared with its target branch, not on every file currently sitting in your working directory. You do not normally upload selected files directly; instead, commit related changes separately and include only the appropriate commits. If necessary, use interactive rebase to remove, edit, or reorder commits before opening the pull request.
For a quick local test, leaving the files uncommitted or using git stash is usually simpler. For a larger experiment that needs several commits, a separate branch is easier to manage.
If you push the branch for other people to review, keep unrelated experiments out of it. Otherwise they may appear in the review and make the branch harder to merge.