in github, can I clone/merge branch online? - github

I want to clone/merge branch for my git repository inside github, for example merge updates in draft branch to gh-pages for publish.
And in some cases, I don't have access to command line for git command.
Is it possible to achieve this online ?

You can merge branches in GitHub using a Pull Request as long as the merge doesn't create any conflicts.
To merge a pull request on GitHub:
Create a Pull Request to merge the draft branch into the
gh-pages branch.
If it can be merged online, you'll see This pull request can be automatically merged. and a Merge pull
request button.
Click the button and you'll have a chance to Cancel the merge or add a commit message and Confirm Merge.
If you choose to Confirm Merge, the Pull Request will automatically close.
For more information, visit Github's Merging a Pull Request Help page.

Related

New Pull Request when a previous one is pending Merge

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.

How to Update a Pull Request on Github

I have a feature branch on git and I set is as a Pull Request.
I've made 3 commits to the feature branch but the latest commits are not showing up in the pull request page.
Is there a way to update my pull request to show the latest commits from the feature branch?
Check first your git status
you must be on the feature branch and not on a detached HEAD
your branch should be ahead of origin/feature branch
the remote feature branch should be the one from which the PR has been initiated.

Pull request to freeCodeCamp guide - how to proceed

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.

Github / EGit pull request workflow

Say I have a repo and someone forks it. Then they do work and submit a pull request. But the code contains a large number of lines and/or it creates a GUI. I'd like to fetch it so I can actually see it run from Eclipse before merging it into my master. The options I've come up with are:
Create a second repo in EGit and clone directly from their fork.
Create a new branch just for them. Then leave a comment for the request asking them to re-submit the pull request using the new branch and that I'll be closing the current request (without merging)
Always keep around a branch for them to use in their pull requests.
Besides setting up an organization on Github what else could I do?
Then leave a comment for the request asking them to re-submit the pull request using the new branch and that I'll be closing the current request
They don't have to re-submit, it you test and merge first locally, as described in the "Merging a pull request" GitHub page.
git checkout master
git pull https://github.com/otheruser/repo.git branchname
If the local merge works, then you can go ahead and merge the pull request through the GitHub web interface.
GitHub has documented how to checkout a pull request.
As I have illustrated before in "What support for git namespaces exists in git hosting services", you can use refs/pull/<PRNumber>/head as remote pull reference, in command line or in Egit when, for instance, creating a new branch.
If the PR number is 123, you can simply use the EGit Pull action, and use pulls/123/head as reference.

GitHub - how to submit individual pull request in case of multiple commits

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.