I just did my first pull request for a GitHub project that had part of my changes accepted and was then closed by the owner of the repo I forked. I want to make another change for that repo, but I'm unsure how to proceed. Since my pull request was accepted and closed, do I need to delete my fork and then create a new one? Or is there a way to refresh my fork to pull in the new changes from the master? Or should I simply just manually copy the changes into my forked project and then put my new changes on top of it? Thanks for any advice/direction.
G
Sorry this is a short answer, but to keep things clean, you should fork again. All the history from your current branch is already covered so there's no need to keep all that around.
Related
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.
I have fork-ed a project on an organisation I'm part of. I'm trying to get the fork updated as there were commits (see below) just by using the web interface.
I've searched the net but I did not find anything relevant.
How can I do that?
Thanks
As i've never played with someone's branch before, my question sounds stupid but bear in mind : This was my first time.
Please find the way to update the branch you've forked , when that person who own the branch, committed changes and you want your fork to be the same as his branch. All done by Github's web interface
Go to the pull request tab
Click on the button New pull request
Create a pull request
Commit (as you are asking for his changes willingly, you are the one committing :))
I've previously forked jockm/vert.x and sent him a pull request. Now I want to fork vert-x/vert.x (the upstream of jockm/vert.x) and send them a different pull request. But when I click the Fork button, unsuprisingly I end up in my tjcrowder/vert.x fork of jockm/vert.x instead. Is it possible to fork both vert-x/vert.x and jockm/vert.x simultaneously such that I can send each pull requests as appropriate?
I fear the answer may be the same as for this question about the converse situation ("there's no GitHub way, but you can add a remote repo") but I'm hoping otherwise — not least because I don't see how the answer there would allow me to send pull requests to the new remote.
There's no GitHub way (small lie, see below), but there's also nothing to fear.
By definition, your fork of a fork is a fork of the original.
When you open a pull request, you get the option to choose both the origin and the destination for your pull request. The choices available there obviously depend on the fork graph, but as long as there is a path in the graph between the 2 repositories, you should be safe.
Also, since pull requests live on the website side, you don't even need to add a remote as long as you don't want to use it from git.
Now of course, you might want to reconsider your place in that graph, and make yourself a direct child of the real upstream, but that's mostly unrelated.
As said earlier there is actually a twisted way to have multiple forks, which is to create organizations and fork in them. That way you can "own" multiple repositories in the same graph. But there's really no need to go there.
Thanks to sigma's answer, I saw that not only is the upstream repo available when I go to do a pull request on the jockm/vert.x repo, but all other forks of the upstream repo are as well. So what I ended up doing was:
Deleting my fork of jockm/vert.x and instead forking vert-x/vert.x, since mostly I want to work within the main upstream repo, not jockm's version.
Creating a branch for the commit I wanted to send to jockm, and a separate branch for the commit I wanted to send to vert-x.
Making the relevant changes to each branch.
Sending pull requests for each branch to the relevant repos, since the jockm/vert.x repo is listed as a possible target for the request (along with about 200 other forks).
I used separate branches (basically topic branches) so that those commits would remain the only thing in those pull requests, since subsequent commits on the same branch are automatically added to the pull request, and these changes needed to remain isolated until/unless merged.
It seems like the better option would be to create a branch on your fork, and create a pull request from that branch. You can use branches to "fork" your version
I didn't see any specifics on "multiple forks", so I would probably end up creating another GitHub account, under which I would do the second clone, and send the different pull request to vert.x/vert.x.
Since you can have "Multiple github accounts on the same computer" (with the right ssh config file, also described here), it is a possible workaround.
Note that, however, this is supported by GitLab, with GitLab 14.0 (June 2021):
Edit default path and project name when forking
Edit default path and project name when forking
Forking a project enables you to have an exact copy of an original repository where you can experiment, apply changes, and submit contributions to the parent project.
Your forks should have meaningful names that explain their goals, and if your project is diverging, you may need multiple forks of a single project.
In this release, GitLab now supports editing the project name and project slug directly when you create a fork.
You can now create multiple forks of the same project, each with a different name, all in the same group!
See Documentation and Issue.
You could also just create a new Organization under your profile/settings. Then you can fork different states of the same original repo through the same account.
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.