When I work on my branch, my pushes don't show up on GitHub, so the pushes don't turn GitHub progress graph boxes green. When I work in the main branch, everything is fine. Could somebody please help me?
You need to merge your branch with the main branch. Or push both branches to github and make a pull request and merge the branches on github.
To push all your branches to github:
git push -u --all
now all your branches should appear
After you pushed all your branches you can use a pull request to merge the 2 branches.
Cick on New pull request.
From the dropdowns select the branches you want to merge. And then click create pull request. A message box will appear. Write the commit message you want and click again Create pull Request.
After you have created the pull request
If you have no code conflicts. You should see the picture above. If there are code conflicts you need to either resolve them in your IDE or via the command line.
If you want to merge branches without pushing to github here is a useful link.
https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
Related
I'm trying to create a Pull Request in GitHub repository from one branch to another branch. On completing the Pull Request, I see 2 commits being added:
Is there a way to get rid of the commit "Merge pull request from ..." via settings?
In ADO repository, there is an option to "Rebase and fast-forward" to get rid of that commit. Is there something similar in GitHub?
Thank you!
When merging a pull request on GitHub, you have 3 options when you click on the drop down button beside the button to merge the PR:
Create a merge commit
Squash and merge
Rebase and merge
While the first one is selected by default, you can choose the 2nd or 3rd option in case you want to avoid the merge commit as mentioned in your question.
All the 3 options are also explained in detail in this GitHub documentation.
How do I go about making my pull requests have only the changes made on the new branch? Every time I push a branch it has all the changes from the previous branches included in the pull request also.
My manager is really big on making sure we do small PRs and have only the new changes on each one for easy review, but I'm at a complete loss as to how to do this. This is my first dev job and up until now I unfortunately haven't been able to do group work so managing PRs that might be a while before they are merged in is totally new to me.
So far I've only found how to cherry pick commits, is this the only way?
If I understand you right, you have a main branch (master?) that contains the latest version of your software and you have one or more other branches that contain modifications. You do some more modifications in that other branch and if you create a pull request it will contain all other changes.
The most simple solution I can think of is to use dedicated branches for all changes. Before starting to work, create a new branch from the main branch with the ticket ID, work description or whatever you use to describe your work: git branch -b feature-123.
Commit to this branch only and push it to the repo. If you now create a pull request from this feature branch to the main branch, it will only contain the changes you did and nothing else.
The further pull requests highly depend on your internal workflow and branch structure. But basically this workflow applies to all new changes.
At my company we ask developers to squash commits on feature branches before merging into develop. Once squashed, the developer pushes to GitHub and logs into GitHub to create a pull request.
When the pull request is merged, we end up seeing two commits in the history of the develop branch:
A commit saying "merged pull request"
The single, squashed commit from the feature branch
Why does this happen? And how can we avoid it? I've read a similar Q&A about avoiding "merge commit hell" but my goal is to use the GitHub UI to create, track, and discuss pull requests.
The commit you're seeing is a merge commit; generally these are auto-created by git any time you do a non-fast-forward merge, but you can also force one to always be created. And that is what GitHub does when you use the merge button.
If you don't want merge commits, then you need to cherry-pick commits onto master instead of using the merge button. There is no way to do this within the GitHub web UI.
Edit: GitHub has now added squash and merge and rebase and merge capabilities within their web UI:
This question pertains to my workflow using github. My colleague sent me a pull request and kept advancing the branch he was working in with new commits? I want to pull the commits related to the pull request, but the pull request now has the commits too. I searched for solutions and kept being led to the "rebase" command. Regrettably, that command is too complicated for me, plus I use tortoiseSVN as my interface to github. I had some solutions using revert, but they were all un-elegant and there had to be something easy. Also the last time I tried a revert, I had some conflicts with commits that no longer existed because of the revert.
My colleague got a response from a github "ask a human". I am reporting the solution here to help other users.
Navigate to the branch with the work to be pulled.
Navigate to the commit history for the branch and identify the point in that history that you want to pull into the master.
Click on the button on the right marked "<>" == "Browse the repository at this point in the history".
Click on the branch pull down menu and create a new branch. This will create a new branch at that point in the history that you want to pull into the master.
Create and execute a pull request to merge that branch into the master.
Too easy. I don't understand how I didn't run across an example of this workflow. I hope I save someone else the time and headaches that I spent.
I may have screwed up, but there a way to get a code review going on GitHub after I did the below workflow?
I cloned a remote repository, branched the master and made my changes. I committed the changes, merged my branch into master, then ran a sync on GitHub and the changes are there now.
I'd now like to initiate a post-checkin review, but didn't fork the repository and so can't initiate a pull request, which as I understand it now is the common way to get reviews going in github. What should my next steps be?
Next time you should just push your changes from your branch to the remote repository, then submit a "pull request" for the branch back into master where the code can be reviewed prior to merging.
When you push changes to your branch, to compare your changes, go to that branch and look for this near the top in the code tab:
This is some good reading as well about how/when to use forking & pull requests: https://help.github.com/articles/using-pull-requests
EDIT:
And since you did say this is after the fact, the other thing you can do is go to the master branch->commits section, and click on the commit where you merged your branch in. That page allows you to make comments and view the changed files, so you can still review your code before you actually push it to your server. However, you should still do the other way next time.
To clarify...you can branch locally and then change, commit etc, and then push that branch to GitHub, then fire off a pull request?
Yes, and since August 14th 2018, you don't even need to switch to the Code tab:
When you push branches while using the “Pull requests” tab, GitHub will now display the dynamic “Compare and pull request” widget—so you can quickly create a pull request without having to switch back to the “Code” tab.
Learn more about pull requests in our documentation.