I have forked a master from upstream, and have created two branches from it. Is it possible to send in PR from a single branch?
I did that, and despite the github web UI is creating the PR against a single branch, I noticed the changes from the other branch is included in the PR request as well.
What's the correct way to send in PR from a single branch?
The likely problem is you didn't git checkout master before creating the second branch, then the second branch you created is descendant from the first branch you created. Just checkout to master before adding the second branch.
Related
Commit Merge branch dev from my-branch
2 pull requests from my-branch to dev and master branch
Hi everyone,
I have problem when pull request from my branch to dev and master branch. It was occured 1 commit is Merge branch dev into my branch - I hadn't pull request it yet. That's odd.
Base on first image, you can see the title is commit dev from my branch (So, It means I created a pull request). But in the commit, we can see a commit named "Merge branch dev into ...".
And I don't know how to check it, because it only has one Pull request to merge code (into dev from my-branch).
My process is :
Switch master (git checkout master)
Pull from master (git fetch -p and git pull)
Create new local branch from (git checkout -b my branch)
Push to GitHub (git push origin -u HEAD)
Pull request (first is into dev from my branch, second is into master from my branch)
The different with other my pull requests is this pull request have many conflicts I need to fix manually.
I'm not sure if I wrong at what step?
And I have last question, how we can block pull request from dev to another branch?
Thanks so much.
I just wonder why it has Merge branch dev, It makes code was wrong.
And could anyone tell me know how to block pull request from dev to another branch?
I made some changes to several files of the project on a new branch (let's call it branch_a), I commited them, created the Pull Request, and it was recently reviewed and approved. It's still pending Merge on the master branch.
Now, someone asked for another change. It's a small supplemental change in 1 of the files edited in the first Pull Request.
What's the best way of doing this? Should I ask for the first Pull request to be merged and then create a new branch (branch_b), make my change and create a new Pull Request, ask for review and merge again?
Or is there a "cleaner" way, when the first Pull Request is somehow merged with the second one and we don't have to make 2 different merges?
If another change requested is a part of the same feature as in ‘branch_a’, then you can simply make change in the same branch, your PR request will show up those changes, but PR approval will be required again.
If another change requested is outside the scope of feature ‘branch_a’ and it is just a file is same between two changes, then you can create a new branch out of master say ‘branch_b’, complete your changes and raise PR for the same. After ‘branch_a’ is merged into master, you can rebase your second branch ‘branch_b’ to include updated master codebase into branch_b, (or vice-versa if branch_b is merged first).
This is especially useful if the order of merge is not decided in advance.
Below are the steps, for rebase, here ‘feature_branch’ is the name of your branch for which you want to perform rebase:
git checkout master
git pull origin master
git checkout feature_branch
git rebase master
Here you might get some conflicts(if there are any) multiple times as per number of commits in your feature_branch. You can resolve the conflicts manually and proceed with further process of rebase with below command:
git rebase --continue
At any point if you think that things are not going well and you would like to cancel rebase process, then execute below command:
git rebase --abort
Finally when all conflicts are resolved and you get message as successfully merged, then execute below command to push changes to origin:
git push --force origin feature_branch
for more information on rebase process follow link:
https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase
Branch off the first pull request branch, edit, add, commit, push, and ask for a second PR merging to the first branch. When the first branch is merged the second PR will be reconfigured automatically (by GitHub) to be merged into the main branch.
I have main as default branch and dev as non-default.
I created one issue and one PR to merge from new temp branch to dev branch
In PR, I have mentioned Resolves #1.
When I merge PR to dev branch, the issue #1 does not gets closed as it is non-default branch.
Then I using git commandline inside main branch, I did git merge dev so dev branch is merged to main.
In main branch commits, I can see the Merge pull request ... commit as well.
But the issue #1 does not gets closed even as PR is indirectly merged to main (from temp to dev to main)
Any reasons for the bug ?
Update: -
When merging dev to main , next time I did not used git merge dev on main branch, but I created new PR to merge dev to main.
And it closes the issue.
Why I worked while merging with PR and not when git merge is used ?
This is by design and not a bug
When you merge a linked pull request into the default branch of a repository, its linked issue is automatically closed
And
Note: The special keywords in a pull request description are interpreted when the pull request targets the repository's default branch. However, if the PR's base is any other branch, then these keywords are ignored, no links are created and merging the PR has no effect on the issues. If you want to link a pull request to an issue using a keyword, the PR must be on the default branch.
From
https://docs.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue
PS: I have emailed GitHub support also for this in the past. Unfortunately is hasn't changed (yet)
I have forked a master from upstream. I have created a branch, made some commits, and now want to issue a pull request. I want to know when my branch is merged by the user, will it get merged to the upstream master, or the user will have an option to create a new branch and merge my branch with it? Btw, I don't have push permission.
Where the Pull Request merges depends on how you create it, when you pick four things:
The base fork: Which fork of the repository the PR will be merged into
The base branch: Which branch in that repository the PR will be merged into
The compare fork: The fork with thew new code
The compare branch: The branch containing the new code
So if you configure the base to be upstream_repo:master, yes, when the PR is accepted, it will be merged to master.
For more, see GitHub's help on Using Pull Requests.
When pushing to a pull request, there are always two builds going on on travis-ci displayed in the github pull request view:
continuous-integration/travis-ci/pr
continuous-integration/travis-ci/push
When the branch has been created from master, which stays unmodified by others commits, this triggers two times the same build. Is there a way to do only one build?
That's probably because that PR is from another branch inside the same repo. The /pr build is for all PRs which can sometimes be from another repo, while the /push part is because this commit was part of this repo.