CODEWITHSUNDEEP
gitgithub
CaptSaltyJack
CaptSaltyJack

Reputation: 16045

Working on GitHub, confused about pull requests and avoiding conflicts

Often when I fork a repo, work on it, and submit a pull request, there are conflicts. I'm not sure how to deal with those. Am I supposed to do a git pull upstream/master on my end before pushing to my fork, and then subsequently doing a PR? Am I supposed to do a rebase at some point, too, to squash my commits? Which rebase command do I use for that, the interactive version? What about using the trick git reset --soft <commit> followed by git commit?

I'm just confused about at what point to do these things, and if I need to do them.

Upvotes: 2

Views: 184

Answers (2)

hek2mgl
hek2mgl

Reputation: 157967

I suggest to do a:

git pull --rebase upstream master

to pull upstream changes. The --rebase will put your own changes on top of the remote changes. This would probably lead to conflicts, but YOU will have to resolve them on your own - not the repo maintainer. Once you have resolved the conflicts, the pull request can be merged without conflicts into the master. But if the pull requests gets not merged immediately and the upstream master gets further developed new changes my arise. You would need to execute the above command again and resolve the conflicts.

Upvotes: 1

larsks
larsks

Reputation: 311606

When submitting a PR, you generally want to make sure your changes are based on the most recent version of a branch, which you can accomplish using the git rebase command.

Assuming you are making your changes on a "feature" branch (that is, a branch that you have created locally expressly for the purpose of the pull request -- adding a feature, fixing a bug, etc), you would so something like this, assuming you were basing your changes on the master branch:

# ensure the master branch is up-to-date
git checkout master
git pull

# rebase your PR
git checkout my-branch
git rebase master

If you are not working on a feature branch, @hek2mgl's suggestion (git pull --rebase master) will work, but I highly recommend using feature branches to isolate your changes from the upstream development.

This will ensure that your changes will apply without conflicts. You may need to resolve some conflicts locally as part of the rebase operation.

It is not necessary to squash your commits, but it is often helpful, especially if you have commits that are along the lines of "fixed a typo" or "forgot a semicolon". Some projects will ask you to limit PRs to a single commit, in which case it will be necessary to squash your commits.

Upvotes: 4

Related Questions