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.
Related
I am not too familiar with GitHub, but I have a feature branch that I want to merge its current changes to master multiple times. Ideally, I want to break up the pull requests so that one pr doesn't get too long. So for example I want a pr for the frontend first. After that is merged, I will push changes for the backend and create another pr. I wanted to make sure that the same feature branch can have multiple prs to master (but there will only be one open pr).
Is this allowed in Github?
#aspiringsomeone, it is a good strategy to keep each PR incremental, self-contained and concise. However, it is good to create a new branch for new set of changes (features). In GIT, branches are just markers and don't consume too much space/resources. After your PR is merged, you can delete the branch and create a new branch for next PR.
In your case, first branch could be feature1_frontend (Hopefully, these changes don't depend on backend or somehow disabled until backend changes are ready). After PR_1 is merged, you can create feature1_backend branch and use it for next PR, say PR_2. As and when PR review is complete and it is merged, you can delete corresponding branches and move on.
Ideally, pull requests should be independent.
Do not keep a long-lived feature branch on hand and keep merging it (the same branch). That is a good way to end up with a zillion merge conflicts. You should always delete a PR branch as soon as it is merged.
But don't worry. If one pull request has to depend on another, there's a much better approach: In GitHub you can actually open multiple PRs that stem from one another, and that's probably the way to proceed here. So:
Branch off of your main branch to form feature1 and push it and open a PR asking to merge to the main branch.
Branch off of feature1 to form feature2 and push it and open a PR asking to merge to feature1.
Branch off of feature2 to form feature3 and push it and open a PR asking to merge to feature2.
Here's the cool part. When feature1 is approved and merged to the main branch, GitHub will automatically rebase the feature2 PR so that it is now asking to merge to the main branch, which is just what you want. And so on.
I just accidentally merged to a branch that I had 40+ local changes on - so now my changes and the merge are together, which I definitely do not want, with a lot of the files having edit & merge changes. I want to completely revert out the merge, is there a way to do this? If not, I'm in trouble.
I haven't checked anything in, I just only want to keep my local changes that I made.
If you merge to a branch via pull request in Azure Devops, then you can revert the completed pull request directly.
In Target branch, select the branch where you want to undo the pull request changes.
In Topic branch name, select a new branch where the reverted changes are created, then select Revert.
Select Create pull request to merge the newly created branch in a second pull request to complete the revert. For details ,please refer to this document.
If I ignore something, you could attach detailed steps or flow for this issue , this would be much easier for me to understand and reply.
I agree with Leo BL. You can try to copy your current project folder into temporary folder. Then checkout the merge source branch and compare it with temporary folder by some diff/merge tool. However, that maybe difficult to cut your changes if they were in the same files with the merge operation.
Just a quick hint: Basically, this is a git question. So maybe you should consider giving it the git tag aswell, so you can reach a greater audience.
Regarding your question: What means local change? Is the stuff not committed at all? What does git status show?
Assuming the changes are not committed, you could use git stash. I recommend this SO question:
Cancel git merge but keep local changes
I would try it this way:
1. Backup the directory (so you have a backup if something goes wrong)
2. Stash your changes
3. Revert the merge
4. Load the stashed changes
—> You should be fine
sorry but you are in trouble. After the merge the files are replaced
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.
In the spirit of testing the "there are no dumb questions" theory, why does Github's squash-and-merge strategy update the committer after merging a pull request?
That is, suppose I author a pull request in my fork of a project. Suppose it has two commits in it. Suppose I ask the project maintainer to now merge my pull request to master of the upstream project.
Suppose she chooses the squash-and-merge strategy so that there will be one commit at the end.
Suppose further that the merge can be accomplished via a fast-forward, i.e. as simple as possible a case as I can think of. (Fast-forward merges should just update the branch pointer, which seems to me like it would leave the commit completely unchanged.)
Why is it, then, that the latest commit on master after the squash and merge operation features me as the author (I understand that part) but the maintainer as the committer? Isn't that an alteration of a commit, and doesn't squashing and fast-forward merging ensure that commits are not altered?
Is Github silently doing the equivalent of something like git amend under the covers?
Isn't that an alteration of a commit
More than an alteration: a creation of a new commit, which reflect the changes of your two commits.
And your two commits are no longer referenced by the main repo: it references only the squashed commit.
That new commit has still you as an author, but is committed by the maintainer.
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.