My company wants to contribute on opensource projects and managers want an easy way to see which upstream issues were closed by forks from our organization.
Is there any way to maybe copy upstream issues to a fork or reference them in an easy way to track my organization contributions to a project?
This may be possible through GitHub Projects. Projects exist per the organization, not a particular repo. You can also link to issues and pull requests from repos of other organizations by entering user/repo#issue in the project's task description.
In the case of your scenario, suppose your team shares a GitHub organization. You can create project, then add items that reference your issues and pull requests, which exist within the open source project's repo. You can configure and organize your project's view(s) to display the information you want to show. Since this merely links to the issues/PRs from the open source repo, the original stays intact, and how they are displayed in your project stay in sync.
Related
We have a team outside of our organisation that is writing firmware for us. They have an internal source control that we do not have access to. They share code with us by sharing a zip file with a .git inside it and we recreate the repo in our internal source control.
We want to conduct an overall code review. This will likely take some back and forth, multiple comments on multiple lines and files of code.
Is there a way to comment internally in our source control, then share these comments to a zip file with this external team? Or is the only way to do this, by creating another source control that is shared between us and the external team?
Create a GitLab account
Add them to your organization as a developer
Create a repository
Have them add that repository as a "remote" to theirs, so that when they push, their commits also go to that GitLab repository.
Then, do your collaboration via GitLab. It has a decent interface for creating Pull/Merge Requests, adding comments to code, and accepting them.
I've almost done my first big project in React+Typescript+Redux and started it on Firebase with users and some database conneted with logged users.
It was supposed to be my project to portfolio before looking for my first dev job, but it start to be very complex.
Now I have idea to use it in the future to make commercial app.
So the problem is I don't want to publish my code on github, but at the same time I want to publish all my commits and repository description on Github for recrutiers (and all my tasks from trello table). Is it possible to publish only commits and description from github repository?
No, this is not possible. If your repository is public, anyone can clone the entire repository. The only way to make your code inaccessible is to make the repository private, which means nobody can see it without having permssion.
I have a Github repository, lets call it:
http://github.com/LegoStormtroopr/ExampleRepository
I want to hand ownership of this repository over to an Organisation to get:
http://github.com/MyCoolOrg/ExampleRepository
But, I want to keep working on the code on my own fork. If I forked this code, I'd once again have a repository with the address:
http://github.com/LegoStormtroopr/ExampleRepository
In effect, I'd move the upstream to the organisation, make forks in a local github fork, and then be able to issue pull requests to the organisation.
I'd like to do this with the least hassle and breakages, and the documentation on what happens after a repository is handed over is a little hazy.
Are there any serious issues that will happen as a result of shifting the repository like this? Will things break because a repository that was there disappeared for a short time?
So having just given this a shot, it appears there are no issues when doing this. However a few things to note:
The organisation cannot have a previous fork of the repository. This prevents it from being able to take ownership.
If you transfer the repository to the organisation, and then fork this into your own account, any working copies of this don't need to be updated, however changes you make will be pushed into your repository, not the organisations.
You may need to reconfigure third-party applications (like Travis-CI and Coveralls) to work with the new organisation, but this is straight forward:
From your account, go to settings and select Applications:
Find the application you need to reconnect (for example Travis-CI) and click View:
Next to each orgnaisation there will be a button titled Grant (not shown because I've already clicked it):
To get Coveralls working properly, in addition to the above, you also need to:
Set your visibility in the organisation to Public:
Refresh the list of repositories in Coveralls (ignore the button name, it syncs public and private repositories):
Lastly, to retain your coverage history, in Coveralls in your old repository select "Change source" and in the list select the corresponding repository in your new organisation.
And now your organisation is all set!
I want to fork a github project to fix a couple of issues and then send a pull request.
The problem I'm running into is that I've already forked the project to adapt it for another user base.
Is it possible to create a second fork? If so, how?
When I try to fork now it just takes me to the previously created fork.
There is no way to have two forks of the same GitHub project unless you use two different GitHub accounts.
So:
Create a separate GitHub account (and verify the email)
Fork the
project
Invite your main GitHub account as a "Collaborator" (from
the settings)
You may need to add the extra step of creating an organization with the new GitHub account and inviting your main github account as an owner of the organization (also make sure your new fork is in that new organization). This will let you do things like deploy automatically to a Heroku app that is connected to your main GitHub account.
Why can't we just have multiple forks???
I mean that I could just commit and push without making a pull request, but I want to do it the offical way and I want somebody else to review the changes before I push to a public project.
GitHub pull requests do not need to be submitted from a fork; they work within a single repository as well:
Pull requests are especially useful in the fork & pull model because they provide a way to notify project maintainers about changes in your fork. However, they're also useful in the shared repository model where they're used to initiate code review and general discussion about a set of changes before being merged into a mainline branch.
There's nothing stopping you from creating a pull request even if you don't technically have to. This is often considered a best practice, and GitHub's own Flow model is largely based on pull requests.
Creating a pull request within a single repository is very similar to creating one from a fork:
Create a feature branch and push your work to that branch on GitHub
In the GitHub web UI, switch to your feature branch
Click the "Compare" & review button
The trick is not to use the master branch to create pull requests. Then you won't need to create multiple forks since you can make as many branches as you need and make pull requests against each branch independently.
Given a clean forked repo, create a dedicated branch and use that branch for the pull request.
You can create branches from the web UI (although it is not obvious).
Click the branch selection dropdown, type the new branch name in the input field, and then you'll see a clickable link Create branch: <new-branch-name> as shown below. The tricky UI part is that it might not be very obvious you should click the "create branch: xyz..." — it is NOT displayed as a button or as a hyperlink, and there is NO indication that this is a clickable link. Moreover, there is NO hint whatsoever that a branch can be created until you type in the search box — anyone would probably assume that the search box is used exclusively for searching branches, and not for creating them.
In case you already made changes directly in your fork's master branch then consider moving those changes into a dedicated branch and hard resetting the master branch to the original remote so that you keep it clean for synching with the upstream repo.
See also:
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository
The best way, recommended by github manual, is use command line git, mirror clone your repo and push it to your github.
https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/duplicating-a-repository
If you strongly prefer GitHub web interface to the command line, a GUI friendly workaround is create a new organization and fork to that new organization.
Another GUI way I can think of is to declare a fork as a template repo using repo's setting so you can create as many forks as you need.
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.