In other words, use git commit (without -amend) only for the first time you create the PR’s commit(s). Use force push to update the remote branch: → git add changed-file another-file Try limiting your PR to a single commit and add later changes by amending the original commit. → git rebase upstream/main Don’t add unnecessary commitsĭon’t create new commits throughout the PR progression. Use rebase when you need to have your PR branch synchronized with changes on the target branch (address conflicts as needed): → git fetch upstream → git push origin HEAD Syncing with ongoing work → git checkout -b my-pr-branch upstream/main Starting pull request workĬreate your PR branch directly from the upstream repository’s branch it should be merged to (typically main): → git fetch upstream You should only maintain branches that are part of an ongoing PR work. It’s a maintenance burden that serves no purpose. There is no reason to keep your main branch in sync with the upstream repository’s main branch. → git remote add upstream upstream-repo-urlįorget about your fork’s main branch. I will go into more detail later.Ĭonfigure two remotes on your local repository so that you have origin pointing to your fork and upstream pointing to the repository you’re contributing to as follows: → git clone forked-repo-url This section provides a condensed version of an approach for contributing to a software project without using git pull. This article is for beginner to intermediate Git users looking to extend their skills in using pull requests and merge requests when collaborating on a project. The git pull command may look harmless, but it is used in ways that often leave a fair amount of mess. I would like to explain why the git pull command is not to be used lightly and to question whether it is ever needed.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |