Git workflow recommendations
Git Recommendations For Pull Requests
- Avoid working from the
master
branch of your fork. Create a new branch as it will make it easier to update your pull request if Julia'smaster
changes. - Try to squash together small commits that make repeated changes to the same section of code, so your pull request is easier to review. A reasonable number of separate well-factored commits is fine, especially for larger changes.
- If any conflicts arise due to changes in Julia's
master
, prefer updating your pull request branch withgit rebase
versusgit merge
orgit pull
, since the latter will introduce merge commits that clutter the git history with noise that makes your changes more difficult to review. - Descriptive commit messages are good.
- Using
git add -p
orgit add -i
can be useful to avoid accidentally committing unrelated changes. - When linking to specific lines of code in discussion of an issue or pull request, hit the
y
key while viewing code on GitHub to reload the page with a URL that includes the specific version that you're viewing. That way any lines of code that you refer to will still make sense in the future, even if the content of the file changes. - Whitespace can be automatically removed from existing commits with
git rebase
.- To remove whitespace for the previous commit, run
git rebase --whitespace=fix HEAD~1
. - To remove whitespace relative to the
master
branch, rungit rebase --whitespace=fix master
.
- To remove whitespace for the previous commit, run
Git Recommendations For Pull Request Reviewers
- When merging, we generally like
squash+merge
. Unless it is the rare case of a PR with carefully staged individual commits that you want in the history separately, in which casemerge
is acceptable, but usually prefersquash+merge
.