pull-request

Frequently, my colleagues will make some changes to an open pull request, rebase their local branch against the base branch - often squashing their changes into previous commits as well - and force-push. How can I see what changed between the old version of the PR and the new version of the PR? I guess I could do a git pull and git checkout $BRANCH_NAME when the PR was first raised, then git fetch and then git diff $BRANCH_NAME..origin/$BRANCH_NAME after the PR was updated - but that will also show changes that have been introduced into the base branch (typically master) and brought into the

I recently started managing a project on GitHub where people have been submitting pull requests. Rather than merge them to master, I would like the ability to: First vet them to make sure they actually work Possibly making some stylistic changes before merging to master How can I do this? Do you have to make a separate branch, such as "dev", and instruct people to code against that before you merge to master? Jorge Israel Peña There is a github help page on this which details how to make changes to a pull request by checking out pull requests locally. What I might try is first creating a

I want to make the pull request merge into develop from the feature branch by default. I'm advocating the use of git flow, so when a pull request is submitted for a feature, the pull request needs to get merged into develop, and not master. Some of the managers commented that being human, there is a possibility that the team leads could overlook that fact and merge the pull request into master by mistake, causing issues with the release later on. We want to mitigate the risks of merge hell so this would go a long way in achieving this goal. Edit: I'm using a fork of gitflow called hubflow(

My project on GitHub has received a pull request . The pull request only partly fixes the issue that it's addressing. I've pulled in the changes to a local branch and added some commits of my own. I'd now like to push those commits back to my remote repo and have them show up on the pull request, but without merging them into the target branch. I'd like to keep the pull request open for further review and discussion, and potentially further commits. Is there a way I can add commits to the pull request without merging them into the target branch and therefore closing the pull request? As long

I have a webhook that currently fires on push to any branch. This triggers the webhook far too frequently. Ideally, the webhook would only fire when a pull request is merged into master . I don't see that as an option, though: Is there a way to get additional webhook options or to customize the webhook somehow? So, you can't customize the conditions of the trigger, but as LeGec mentions you can customize your code to only trigger when the Pull Request is merged. To do that, make sure your script responds to the PullRequestEvent . The conditions to test are: "action" is " closed " "merged"

I opened a pull request to rails repo on github by using Fork & Edit this file file button. Now, After getting feedback on my PR, I wanted to add some more commits. so here is what I ended by doing $ git clone git@github.com:gaurish/rails.git #my forked repo $ git rebase -i 785a2e5 #commit hash of my commit using which PR was opened $ git checkout patch-3 #branch name I had to send my commits under to be shown in that PR $ git commit -am "Changes done as per feedback" $ git push origin patch-3 This worked fine but seems quite a complex workflow. Maybe I am wrong something wrong here? my