CODEWITHSUNDEEP
gitgithub
theomega
theomega

Reputation: 32031

Make additions to a commit in a pull-request

Lets assume I branched a feature-branch from the master in git. Now I commit some changes to this branch and I think it is ready for the master branch. So I push to the remote repository and use the github UI an issue a pull request from my feature-branch to the master branch.

Now, due to the feedback in the pull request, I need to change some things in my feature branch. I now the simple option to commit the changes as a new commit and push it. If the branch is now merged later on, my feature is splitted into multiple commits.

What are the possibilities if I want to avoid having multiple commits? I see the following possibilities:

  1. Use git commit --ammend and append the changes to the current commit
  2. Use git rebase -i and squash the changes together into one commit

Both of these solutions have a huge problem: I can't comit anymore without a push -f.

Question:

  1. Is this workflow somehow wrong? Is it wrong to aggregate the commits and should I simply leave them as separate commits?
  2. If no, is it OK to use push -f here?
  3. If yes, how can I make sure I don't do anything really bad? Can I somehow limit the effects only to my remote branch and not affect anything else? Destroying my own feature branch is not that bad, but destroying the master is not good.
  4. Are there any other possibilities avoiding the push -f?

Upvotes: 0

Views: 182

Answers (4)

Sven
Sven

Reputation: 70863

If your pull request hasn't been accepted as it is, and the discussion has lead to you incorporating feedback, I'd say that your original pull request has been declined and you should prepare a new one if the project you are contributing to has some tighter requirements for pull requests.

Otherwise, you are expected to add new commits to your branch instead of rebasing or amending to already existing commits, push them to github and let the pull request be updated.

This way you will end up with a pull request that has at least two commits: The original one that got discussed, and the commit with the feedback changes.

If the project required pull requests to be one commit only, you have to create a new pull request with all your changed squashed into one commit, and probably rebased onto the new current head of development.

Upvotes: 0

ThanksForAllTheFish
ThanksForAllTheFish

Reputation: 7251

  1. Basically it is not right, but if you are sure no one else pulled that branch, you can rewrite its history freely. You should not rewrite the history of a remote pulled branch for such operation will cause problem on local repositories which will, probably, reintroduce the history you rewrote.
  2. As already said, simply rewrite your local history before pushing to remote.
  3. Point 3.

Upvotes: 0

cforbish
cforbish

Reputation: 8819

  1. Since it is your branch, you can rewrite history and the workflow is correct and in the end is less confusing than separate commits.
  2. The answer to 1 was yes so git push -f away.
  3. Before pushing you can just observe what you local branch looks like. Tools like gitk and git log can help.
  4. Since this is your branch git push -f is not bad, but you can always create a new branch if you want to keep your old branch as is.

Upvotes: 1

Fred Foo
Fred Foo

Reputation: 363567

  1. It can be confusing. Squashing/amending only when merging might be a better idea than squashing while developing. That should be done by the person merging in the PR.
  2. It's required when you've altered the history :)
  3. git push -f <remove> <branch> to only force-push one branch.
  4. Making a separate branch. But that requires a new PR, so it's usually not worth it unless the changes are so big you'd want to restart the discussion.

Upvotes: 0

Related Questions