Can anyone explain why a commit in GitHub would display the following information : 'Contributor-A' committed with 'Contributor-B' on 15 Feb.
Does it mean that 'Contributor-A' is the author (who does not have the push access to the master) and 'Contributor-B' is the committer/maintainer?
Then why isn't there a PR created for merging this commit? Or does it mean that there was a closed PR about this commit, but the maintainer did not merge it via web interface but performed rebase or cherry-picking to include it?
Many thanks!
...maintainer did not merge it via web interface but performed rebase or cherry-picking to include it?
I was able to get this by cherry-picking a commit from another branch and directly pushing to the current branch - an example on GitHub.
A Pull Request is not required to push code between branches. A Pull Request is a method that allows developers to collaborate on changes prior to merging between branches.
For sure, it happens when the pull request was merged by "Rebase and Merge" strategy via the web interface, but I'm not sure if this is the unique case.
Contributor-A committed with Contributor-B on 15 Feb.
Contributor-A submitted the pull request and Contributor-B effectively merged it.
It might happen in other scenarios as described here: how to apply a git patch as if the author committed to my repo?
Related
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.
We use GitHub flow as branching strategy which means that anything in master is the result of a merged pull request. It's trivial to get the last commit by doing the following.
GET https://api.github.com/repos/:org/:repo/git/refs/heads/master
However it seems non-trivial to work out the pull request that caused this commit.
Is it possible to find out the pull request that created this commit via the API?
The PR should be one of the parents—the second one—of the commit in master, since that commit is the result of a merge of the PR.
You can find that parent with the GitHub commit API
GET /repos/:owner/:repo/git/commits/:sha
GitHub doesn't offer a way to get the branch from a commit, but you could list all the PR and cross-reference the SHA1 found above with said PRs.
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.
I've done a few pull requests on GH already, but I committed to the master branch. Now I read on various places that it's a good idea to create a branch.
Are there any guidelines for branch naming? I usually work with Mercurial and give my branches the same name as their relevant bug ticket ID, but that doesn't work for this.
I've looked at a few repositories: some commit to master, some commit to fix-somebug, some commit to patch-1. I understand that this doesn't create conflicts, because pull requests are merged to master (or a different, long living branch) and the branch is then deleted, is that correct?
The idea behind a branch for a pull request is to allow for said branch to be automatically deleted once the pull request is accepted.
And since April 2013, that branch will be deleted for you:
You are then suppose to update/rebase your master from the master of the upstream repo in order to get what you developed in isolation a branch from the official repo that you have forked (since that repo has accepted your pull request)
The name of the branch should represent the development effort you are engaged in.
It is always a good practise to make commit on the git branches rather than master. You can use any name for your git branch(it doesn't allow spaces in branch names, also some special characters).
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.