In the PR , after I merged a branch and deleted it, I restored the branch again on the PR.
Locally, then I made changes to the branch and pushed it to the remote branch. The commit is available on the remote branch but it does not come up in the existing merged PR.
After I compare and Pull Request, it is creating a new PR.
Is it possible to add the commit to the old PR itself?
No, you can't re-open the pull request if it was merged.
Related
I merged a pull request accidentally in github but it needs some changes how can I revert the pull request in github to add those changes that I want.
Thank you.
Open the Pull Request page: https://github.com/your_org/your_repo/pulls
Click on "Closed"
Select your PR
Click on "revert"
The best thing to do would be to simply make a new PR with the changes you want to make, as no matter what you do, the "bad" PR will always be a part of the git history. That being said, follow Vertexwhan's answer if you really want to revert the merge, but keep in mind that you will not be able to re-merge the same branch later on.
I had the same problem, revert pushed commit results in new commits that remove your code.
Then, you can't merge again the PR, these commits are already in master history so PR can't be merged again after revertion.
The solution I found and which doesn't force history :
On master, on your local repo :
git revert -m 1 <merged PR commit-hash>
The -m 1 : "specifies the parent number (starting from 1) of the mainline and allows revert to reverse the change relative to the specified parent." Keep master history clear.
https://git-scm.com/docs/git-revert
Next, you can create a new branch from master like : unrevert-<my-branch>.
On this new branch you can use git cherry-pich to restore reverted commits : git cherry-pick <commit-hash>.
Then, you can merge your unrevert-<my-branch> on your PR branch.
After it, you can reopen your PR and your commits are again mergable on master. You can continue to work on your branch like nothing happens.
That doesn't need to detach HEAD which can be complicated to deal with
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.
For one open source project, I opened pull request with commits in my branch. This PR stayed untouched for a few months.
Then, I did rebasing in that branch (because in the meantime it got conflict with master) and I messed something up so pull request got hundreds of commits from tens of contributors, and they are all added as "participants" to PR by GitHub. (I am not sure why GitHub is showing changes when those commits are from master, already merged)
I reverted rebasing in my local branch with git reset and it looks good, but I am wondering can I safely push that branch to origin? Will git push --force do the trick? If I do it, will those other commits be unaffected? What about participants to PR?
Note that this open source project is not mine, and that nobody else worked on my branch.
Will git push --force do the trick?
Yes, it will update/replace the PR commit history by your local one, and update the participants.
If you want to test it, you can push it to a new branch and create a PR from that new branch to see if the end-result PR looks OK.
And then delete that new PR, and force push to your original branch.
I was working on a branch of my Bitbucket repo (lets call it "frontend-dev"), which has now been merged with the master branch. I would like to branch again to make further changes, without creating a new branch. How do I branch and get back onto "frontend-dev".
I am using Sourcetree to manage version control.
Normally merging to master does not close or delete the branch. If there are changes in master since the merge from "frontend-dev", you can merge back to "frontend-dev". Either way, you can then simply switch your working copy to "frontend-dev" and continue developing.
Another question discusses what to do when you have closed or deleted the branch: Restore Merged Branch in Bitbucket Repo
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.