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.
Related
I've noticed that rebasing from master when there are no conflicts does not cause existing reviews to be dismissed.
In the docs, github describes the "Dismiss stale pull requests ..." setting as "New reviewable commits pushed to a matching branch will dismiss pull request review approvals".
What does "reviewable commit" mean here?
If you push any change to the branch manually, or you create any change in the web interface (e.g., applying a suggested change) other than a merge from the destination branch (or a rebase onto it, as appropriate), then GitHub will dismiss the review.
Basically, updating with the main branch using the GitHub tools for that does not cause a reviewable commit and everything else does. Note that in general it is nearly impossible to determine whether a manual merge or rebase introduces any "meaningful" change and therefore doing it manually always dismisses approvals.
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.
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 forked a repo on GitHub, made and pushed changes to my version, and now want to send a pull request to the original repo.
How can I send a pull request with changes affecting a single file and not include the commits and changes done on the other files?
You now (January 2015) can do it directly from the GitHub web interface.
See "Quick Pull Requests":
When using your browser to edit a file on GitHub.com, the web-based commit composer lets you quickly propose a change to a new branch and then immediately open a pull request for discussion and review:
Reducing the time it takes to open a pull request lowers the contribution barrier, and having this workflow available entirely within the browser makes collaboration more approachable for people with all technical skill levels.
Create a new branch from origin/master, commit the right changes to it (you can use git cherry-pick to copy commits among branches) and create a pull request of that branch.
I forked some project and cloned it locally. Changed files, commited changes, pushed changes and changes were either implemented or rejected. Then, some time has passed so I fetched/merged my fork with the project I forked from. Made some changes, commited and pushed. Sent pull request and that's where the problem begins: in pull request there are commits which were implemented or rejected and I don't want to send them to master owner, I just want to send new ones.
Am I doing something wrong? How can I fix this?
What I do is create a new, clean branch based on upstream, and then cherry-pick the changes I want to submit onto that branch (or develop them on that branch in the first place, or use some other method to copy them over to that branch).
It can look a bit silly to have a list of public branches called "clean1", "clean2" or whatever, but hopefully you won't need to make too many of these.
Alternatively, you could just submit patches instead of pull requests.