I have a pull request that is currently against the master branch and I want to change its base to a branch that is two commits behind master.
When I change the base branch in GitHub Enterprise the two commits that are not on master also get dragged into the pull request.
Is there a way to change the base branch but just have the commits that are actually in the pull request? I don't see any options other than the branch name, and my commit and one of the other commits touches the same file but not the same lines.
Related
We are using Azure DevOps, recently came across the issue when some of the commits that was stated to be completed and merged to the master branch dont show up in Repos history.
Azure master branch doesnt show the merged commits
It depends on the merge method you choose when you PR.
Azure Repos has several merge strategies, and by default, all of them are allowed. You can maintain a consistent branch history by enforcing a merge strategy for PR completion.
So, if you select the Squash merge, which is a merge option that allows you to condense the Git history of topic branches when you complete a pull request. Instead of each commit on the topic branch being added to the history of the default branch, a squash merge adds all the file changes to a single new commit on the default branch.
In this case, the commits that was stated to be completed and merged to the master branch dont show up in Repos history.
You could check the document Merge strategies and squash merge for some more details.
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 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.
I have a project, biocommons/hgvs. A contributor forked the project, made some changes, and submitted a pull request. I'd like to make some minor changes to those commits, and I'd prefer to do so in a feature branch.
Is there a way to pull the PR commits into a new branch?
You cannot pull them in another branch in a sense how mercurial uses branch (as in named branch created by hg branch).
However, you simply can continue to work on top of your latest commit and later merge your head and the head created by the pull request, thus both, yours and their head being anonymous branches. (IMHO this is the beauty - every head can work on its own, no need to expressly branch or name things)
If you still want a name, you can stick a bookmarks onto the head of the pulled changes; they work very similar to 'full' branches except that they can be changed and moved.
If you really need and want the changesets to be in a named branch, then pull from the forked repository, create the named feature branch manually and use rebase or histedit to move the commits to the just created feature branch.
I've made multiple commits to my local repository and now I intend to do pull request to submit these changes over to the source/master.
When I do a pull request, it automatically includes all of my commits. I couldn't locate a way to submit each commit in its own pull request. Could someone please give some pointer on how to do this on GitHub.
Update
To clarify on this question, I forked a new local repo from upstream/master. Then, in my noobie-ness, I made new files in my local master itself without branching repo out first. So, effectively, my question is with these changes committed to local master repo, is there a way to raise pull requests for each new file one by one, and not for all of them in one go.
Many Thanks.
I'm not sure if there is a better way in GitHub, but in general, you can create a new branch for each pull request, cherry-picking the commits you want for each request.
The new branches should preferably be based on upstream master to make the merge painless.
Using command line git, using origin as your own github remote repo, upstream is the upstream remote:
git checkout -b {my_pull_request_feature_branch} upstream/master
git cherry-pick {sha1_of_first_commit_for_feature_X} [sha1_of_another_commit_for_feature_X] ...
git push origin {my_pull_request_feature_branch}
Repeat for each pull request.
When you do a pull request on GitHub you can then choose which branch you want to send in your request.
A commit does not stand on its own, it always links to the full previous history. So if you ask to pull commit B which depends on your commit A, then you are also asking to pull A, because your work in B depends on it.
If you want to submit multiple independent pull requests, you should make sure that those commits are completely independent of each other. So they should be on their own branches. This also makes it easier for the project maintainers to integrate your pull request, as they can just merge the branch without having to cherry-pick stuff.