I Created a pr and it was approved. As Build got failed, I was unable to merge with master branch. So, I made some changes and committed code to feature branch. Still I am unable to merge with master branch because of the issue:"" There is 1 issue preventing you from merging this pull request.
You still need a minimum of one successful build before this pull request can be merged.""
To merge my changes with master, can I continue with my existing pr or do I have to create a pr?
Related
Can we create pull request from master branch to master branch in Azure devops because our team will work on directly in master branch and we need to code review and approval method also.
No this isn't how git works. You would have to branch off of master and then PR these branches back into master. Committing directly to master is not a recommended practice
Contributions to a source code repository that uses a distributed version control system are commonly made by means of a pull request, also known as a merge request.
The contributor requests that the project maintainer pulls the source code change, hence the name "pull request". The maintainer has to merge the pull request if the contribution should become part of the source base.
A pull request can be accepted or rejected by maintainers. Once the pull request is reviewed and approved, it is merged into the repository.
The above is how to pull request works.
We can push empty commits via git commit --allow-empty -m 1, But for your situation, even no empty commits(Because the source branch and target branch always the same), so of course the pull request will not be able to created.
Another thing will clearly tell you the reason:
If you use this API to create Pull Request from 'master' to 'master', you will find it is not accepted.
The detection of whether the 'sourcebranch' and 'targetbranch' are the same is high priority, even before the detection of the existence of the branch, so what you want to achieve is not possible from the basic of the design.
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.
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 working in my local branch-1 and my colleague works on his local branch branch-2.
He already committed and pushed the branch to his origin/develop and created a Pull request to upstream/develop. So now it is waiting for review and approving the pull request by someone else.
The problem is, in my local branch I need to edit one same file, which my colleague worked on. So my branch and his branch will containe the same file with different code. If his branch would be already in upstream, then I could merge it to my branch and resolve the conflict locally without problems.
However now it is in Pull request status waiting for review and I don't have time to wait, I need to create also my Pull request.
How and when will the conflict be solved, as the file with conflict is in both pull requests now, will git recognize it now or? As those branches are not in upstream yet.
Whichever branch is merged first, the other PR will have a merge conflict that must be resolved. If yours is merged first, theirs will suddenly have to fix a conflict. If their PR is merged, yours will have a conflict.
The PR main page will show the conflict and won't allow it to be merged.
The other answer is the correct one, but I want to add another possible course of action.
If your two separate features need to follow (for whatever business/architecture related reasons) merging order, where branch-1/feature-1 must be before branch-2/feature-2 and also at the same time, you need to create a PR for your feature, then what you need to do is rebase your branch on top of your colleagues branch and create a PR that way.
Once branch-1 is merged, then rebase branch-2 onto the latest upstream/develop. This will force you to resolve conflicts and update the PR accordingly.
I have 2 branches - master and develop
I have been doing some pull requests in my develop branch where it contains 5 items, in which it is the same as the number of items in master.
However, someone did some commits and pushed in a few more items into the master branch, and hence now it has 8 items.
As my pull request in the develop is still not yet approved/merged, whenever I tried to update my pull request, I am getting the message stating that This pull request can't be merged. You will need to resolve conflicts to be able to merge and asked me to do the following:
git fetch origin master
git checkout develop
git merge FETCH_HEAD
git commit
git push origin HEAD
And this happens after I have 'pushed' out my commits, making me confused at times. Then I realized that it is asking me to re-add and re-commit in the additional 3 new items. So does this means I must ensure that the items and contents between these 2 branches of mine should be the same as always? I have always used git pull/fetch but will there be a better way for me to make sure?
What this means is that GitHub would like to merge your PR branch into master, but it can't, because there are conflicts. As you've discussed in the question comments, the best way to deal with this (usually) is to merge your master branch into develop on the command line. That will show you the conflicts and ask you to resolve them. Once you've completed and pushed that merge, the PR will be mergeable back into master using the green button on GitHub.
You could simply merge your deploy branch into master (which I realize sounds a bit more sensible). In that case, you'd be bypassing the PR entirely. You'd have to close the PR "unmerged", and separately you'd manually push the merge commit to master.
By doing it the first way,
you make a better audit trail by merging to master on GitHub, using the PR;
you give your team a chance to review your code after the merge, before it lands on master; and
if you have automatic tests (such as Travis CI or CircleCI) which check PRs, you give them a chance to run your merged code as well.