https://github.com/Decimal458/test.git
When I create a PR(#3,#5,#7) to merge "dev/" into "stage", the PR include old commit.
But create PR(#4,#6,#8) to merge "dev/" into "main", it would not happend.
In the company I work for, those PRs that are merged into the "stage" may contain more commits and even see other people's files in "Files Changed".
I would like to know how to only display my own commits or files when creating a PR that is merged into stage, just like a PR that is merged into main.
Note: I don't have permission to execute merge in the company.
I would like to know how to only display my own commits or files when creating a PR that is merged into stage, just like a PR that is merged into main.
This is all about rebasing --onto: you rebase only your commits on top of the PR target branch, and then force push your feature branch.
That will update the PR, and show only your own commits.
If you were to make a PR from CVG-xxx to develop, you would see commits from CVG-yyy, because your feature branch was initially create from it.
Assuming CVG-yyy is the commit just before your own CVG-xxx branch:
git fetch
git rebase --onto origin/develop CVG-yyy CVG-xxx
git push --force
The result is: only your own commits are on top of origin/develop now.
Your PR (to origin/develop) will only include your commits.
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 have created a branch and committed to it, got it reviewed and merged with main branch. Now when I try to push another change into another commit with the same branch now I see 2 commits on the branch and if I now merge, the first commit as well as the second will get merged? why is this happening?
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.
I am a new developer and just starting to ramp up my PR's at work. So I made a PR and before that PR was merged I made another PR. My first PR was finally approved and merged but the second PR doesnt have the changes from the first one. So I am wondering if I merge the second PR without the changes of the first PR will this override my first PR's changes?
That sounds like a bit of a sketchy operation to me. If you're unsure, here's what I suggest.
Suppose your first PR was merged to origin/master and your second PR is on branch pr2. Then I'd do the following:
git checkout master
git pull --rebase origin master
git checkout pr2
git rebase master
Briefly, I'm suggesting you sync your local master branch with upstream, then rebase your pr2 branch on master. This essentially applies the novel commits in master before your novel commits in pr2. At this stage, you'll find out if you get any merge conflicts. If not, you can examine/test your project and decide if merging your PR will be safe.
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.