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.
Related
I am working on a repo where I am the owner and only author in it.
I want to have in my repo the same behavior as I would when working with a team that protects my branch from direct commits as they must go through a Pull Request. The reason for doing so is to protect from my own mistakes as I sometimes go back to main branch and accidentally push code to it. I want only code that passed through a Pull Request to be able to be merged to main branch.
In order to achieve such behavior I added the following rule to my main branch -
Which is almost what I need, expect that I am locked without the ability to approve my PR's as there is a message I get saying authors of the PR can't approve their PR's - a logical error nonetheless, but if I am working alone in the repo this is not what I am looking for.
How can I achieve what I am looking for?
Simply disable "Require approvals" (the second checkbox in your screenshot), you will still be required to create a PR.
You can merge your own PRs, the only thing you cannot do is to approve your own work (after all: why would you? Hopefully you deem your own changes good!)
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.
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.
I forked a repo from GitHub and make a bunch of changes. Then I found one of my modification in one file can be a patch to an issue of the original repo, but the author don't want to merge my other modifications, so I don't want to send a pull request directly. And I think forking it again and just modify that file to make a patch and then send pull request seems not so elegant. Are there any "standard" way to do that?
In my opinion, you should make a new branch with the same root, then use cherry-pick to add every commit you made except those who are not accepted by the author.
Then send a pull request on this branch.
Moreover, if you want to regroup all your modifications into one simple commit, you may use a squash rebase on a local branch before pushing it online.
Write down the SHA-1 hash of the desired commit. Switch back to the original project's master branch, create a new branch off of it and cherry-pick that one commit onto the new branch.
You can then push the new branch to GitHub and send a PR with its changes.
If you have modified multiple files within one commit, you'll have to rewrite the commit somehow.
I'm trying to identify the proper way of working with multiple branches on Gerrit that would match our workflow.
The way we work with branches right now is: we have master & feature branch. Master is the branch we want to polish and make it ready for release, while feature is obviously a field of intensive work. Now, in our particular case whenever somebody works on a bug fix, they:
create a change targeted for master branch
cherry pick it to the feature branch targeted change
once gerrit code review completes, submit both changes.
now the way i understand cherry-pick, it selects individual commit and merges it to the current change. if that is the case, i would expect to have no merge conflicts in the end, and indeed this workflow works perfectly with just GIT. Gerrit, however, most likely due to its nature (branches are not merged remotely the way these are locally and get a different sha tag) lists a tremendous number of conflicting files in the end.
Now, I resolved all these issues by applying merge strategy (ours on feature, theirs on master), but it does not feel right: if anything was not propagated, it just got discarded.
My question is: is there a safe workflow, similar to the above one, that would in the end produce a clean merge with gerrit?
I would say that it's better, in this case, to merge than to cherry pick.
A cherry pick adds the same changes but not the same commit. So while the source is the same on a cherry pick and merge the git tree is different. When the tree is different and you later do a merge git will think that the commit you previously cherry picked is missing and try to merge that change as well, even if the actual code is already there. That's probably why you get a lot of conflicts.
I would propose another way of working.
When you do normal work you develop on feature and push to Gerrit as normal.
When you do a patch (ie bug fix) on the stable production environment you do that directly on master (or local branches if you like but not on feature)
When the patch as been approved in Gerrit it get's merged into the real master and you can make a pull request to get that change to your local copy. Your version of master is now the same as Gerrits master
Now you would merge all new changes on master into feature. Make sure you do a rebase so that the patch ends up before anything you've already done on feature
Once it's time to deploy all new features you can merge feature into master, push to Gerrit (if you have permissions you can by pass gerrit by pushing directly to master instead of refs/for/master as these changes are already reviewed)
Once all changes are on Gerrits master you do a pull on your master and a merge into feature with rebase making feature a clean branch to work on. It's of course totally valid to have a new feature each release. Both work fine.
I'm a little confused, as this flow should work just fine. If other users submit changes before your bug fix is reviewed/verified/submitted, that could result in merge conflicts, but that should be rare.
If you:
Fix a bug on master
Push to review (creating change A in gerrit)
cherry-pick change A on top of the feature branch (resolving any conflicts from master to feature)
Push the cherry-picked change to review (creating change B)
Review/verify/submit changes A & B
Everything will work fine. The only way for merge conflicts to occur is if other users upload and submit changes between steps 1 and 5. Are you seeing different behavior? Can you provide more details?