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.
Related
I have a project on GitHub, and I forked it to a second repository.
There is still work done on the repo that I forked from, but the changes I make to the first repo should also be applied to the forked one.
How can I push a pull request to both of them at the same time? Or is that impossible to do in a simple way?
If it is, is there a simple alternative solution?
No, GitHub pull requests only target a single repository.
Pull requests are only relevant when you are communicating with other people. Since both repositories are yours, you can just execute a git pull or git merge command on your local machine to merge whatever branches you want to merge. Then use git push to push the changes up to GitHub if you want.
Also, I recommend that you simplify this setup and just use a single GitHub repository with multiple branches.
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 wanted to contribute to the FCC guides and I actually did.
This is my fork to the repository
Link: https://github.com/BitYog/guides
However, when I open the main guides repository, I don't see my changes being shown anywhere. What do I do so that my changes are merged and committed into the main repo?
You don't see your commits in the original repository, because you didn't create a pull request against that repository, but against your fork. In other words, you opened a pull request to merge BitYog/guides#BitYog-patch-1 into BitYog/guides#master. With that, you updated your own master branch, but not that of freeCodeCamp/guides.
Your changes will only show up when a pull request into freeCodeCamp/guides#master is merged. For that to happen, you need to open a new pull request in the freeCodeCamp repository and request to merge either your master or BitYog-patch-1 branch into master.
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?
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.