Can I fork a private company repo (from the organisation, I'm part of) as regular user, to have a private fork under my own (not company) account? A fork that is in no relation to company or it's (original) repo?
I tried the simpliest thing, that is forking my own fork. But that failed.
No mater, if I'm at company/core repository or user/core fork, whenver I'm clicking Fork button in GitHub, I see two options -- my user account and company account. None of these buttons works. When I hover my own button, I see Click to visit the #user fork tooltip. When I hover company logo, I see You're already looking at this repository (which is actually a little bit misleading, as I'm actually looking at my fork, not at original repository).
Is there any workaround for this? Can I have my own, regular user-based, private fork of company?
Yes, I can. Only this is called a mirror, not a fork.
Steps are following:
Create new repository, that will act as your private "fork".
Get HTTPS / SSH addresses of both repositories and open console.
Execute git clone --bare https://github.com/company/company-repository.git.
cd to cloned local repository.
Execute git push --mirror https://github.com/user/user-repository.git (a "fork").
cd up one level and rm -rf company-repository.git.
These are instruction for one-time duplication ("forking") of a company repository as a regular user. Follow to this GitHub Help page for more details and for instruction on performing periodic updates of such "fork".
Note, that step 3. is quite fast (up to speed of your connection; 1 MB/s at my side), while step 5 is often limited by GitHub to something around 60 kB/s. So, for large repositories, it usually takes a lot more time to finish.
Related
I'm part of an organisation on github and would like to copy all the repos of that organisation to another regular github account at once.
I thought there would be a tool to help me to do this easily but haven't found one yet. What would be the easiest way to approach this? Thank you
I have tried looking into gh but I'm not sure it's the right tool for it. All I'm trying to do is basically cloning all the repos of the organisation I am a part of to another github account in one go
I have tried looking into gh but I'm not sure it's the right tool for it.
Considering there does not seem to be a native feature allowing for a bulk copy you want, gh is actually a good option.
Depending on the fork policy of your organization and the nature of said repositories (public or private), you should be able to write a script, using the GitHub CLI gh, which would:
list the repositories of an organization (gh repo list)
fork it (gh repo fork)
Note that will not copy issues or pull-requests.
I have forked a public Github repo using the Mac GitHub Desktop client, so I can make some changes and submit them.
I have got my fork into a total mess (I am not used to working with forks) and want to start over, but I cannot find a way to tell the client my repo should track the original repo rather than my fork... it seems irrevocably bound to my fork.
How can I get the client app to forget I have a fork?
I'll put up what I found by trial and error, but someone might have a better way:
I basically deleted my repo (form) on Github, and automagically the GitHub client showed my local repo now linked to the original repo again. I was able to go through the process of creating a fork all over again with my changes.
first: We use a github repository in the team for some projects.
I'm using scripts defined in the pre-commit hook directory, locally (works perfect for my commits).
What I need is for every user (collaborator) to use the hooks without using symlinks or asking them to put them on their home folders.
Is there a way to set them up so the users can't commit if the scripts don't exit 0?.
Thanks.
As Henrik alluded to, in the Enterprise version, there is such a thing as the pre-receive hook. It runs server side and so you would not need to install it on each collaborator's local machine. But you are using github.com actual, and they don't allow pre receive hooks , nor do I expect they plan to; allowing indivduals to run scripts on their server isn't likely in their business plan. So that likely won't help you unless you are in a position to go to the enterprise product
There are some remedies you do have, however, but it won't be equivalent. You can , for example, set a protected branch . You could thereby make it only you can check into that branch, and you of course would be using the local hook, every one else would be using a pull request.
Additionally, you could look into LGTM (Looks Good To Me) or similar automated pull request approval system. I don't believe the official server is up but the source code is there and it could be run by someone else. LGTM allows you to set a number of different conditions that would be closer to an equivalent to your pre-op hook.
Setting up such a system might well be more effort than it is worth to you, understandable; but it is do-able.
The main problem with using pre-commit hooks that come with git is that they are local to your repos and don't get pushed to github.com. I believe under the hood, those hooks aren't even transferred up to the repo on github, and that the pre-commit hook directory itself is not available like it is on the local copy of a git repo.
(I would say more on that architecture of the pre-commit hook dir except A. I am not sure if it is covered by NDA and B. I only saw the way it was on the Enterprise product, not github actual, and C. I don't know if the structure is still exactly the same)
Can anyone please consult me on one thing?
We have a project, and we just decided to hire more programmers to work on it.
Up to now I was the only programmer, backing up the code on GitHub.
But now I need to find a safe way how to manage multiple programmers.
So there is a master branch of private project, which other programmers should be able to clone.
But they should not be able to commit changes to master branch themselves.
Perhaps they should make their own branches, and commit changes there.
And I should be the only person who is able to review their work, and merge it to master branch if it works right.
Can anyone please tell me how exactly I should set it up?
Or send some good tutorials?
Thanks so much
Collaborative coding is rather the whole point behind Github. Here's an illustrative workflow to get you started. A similar development flow is absolutely essential to open source projects (which by nature must work via the internet). In fact, a lot of open source projects use Github. You can use this process, too; although there are some caveats, which I've listed at the bottom.
The key to understanding this workflow is that each developer will manage 2 repositories:
Personal work, on their local machine
Work visible to all participants, hosted by Github.com
Setup process, integrator (project lead):
Create github account
Host project there
Setup process, developer:
Create github account
Fork the project
git clone forked branch to local machine
Development process, developer:
Work on local copy
Push to github copy. (Remember, each developer has their own Github branch.)
Submit a pull request to the project lead's Github repository.
Rinse and repeat.
Development process, integrator:
Look on Github for pull requests
Review them, approve them, merge them
Work on local copy, as above, sans the pull requests
However, this isn't the only possible workflow. For example, Github makes it convenient for your developers to send pull requests to each other, e.g. if two of them are working together on a feature. This way, all of them may work in the "integrator" role somewhat.
Caveats:
If your program is not open source, then there is one caveat to using github: you must pay to host private repositories. They have a mechanism (disclaimer: never used) for organizing collections of people to work on either public or private repositories, however, and I believe the cost can be paid entirely in the organization owner — which would be great for your developers, and cost some extra for you.
If you only have a few contributers, you might be able to get by with having a free private repository by using Bitbucket instead of Github. They have an option to host private repos for free, and the workflow would be about the same as what I've outlined above.
The best way to achieve this is with a pre-receive hook which looks at the username of the person carrying out the commit and the branch they are trying to commit to. If the username isn't in a list of allowed users and the branch is the master branch then deny the push.
e.g.
#!/bin/bash
allowedUsers=( 'bob' 'john' 'george' ); # list of allowed usernames
while read oldrev newrev ref ; do
echo ${allowedUsers[#]} | grep -q $(whoami);
if [ $? -eq 1 ] && [ "$ref" = 'refs/heads/master' ] ; then
echo "You are not allowed to push to master branch";
exit 1;
fi
done
When working with GitHub the best and easiest way is to use Pull Requests. In your case every programmer is given only Pull access to the repository, and has to cone it. When he or she is ready with the changes, that programmer sends you a pull request. You then review the request, and if ok merge it into the main repository.
As you know GitHub has introduced a Repo Transfer feature. https://github.com/blog/876-repo-transfers
This allows you to change ownership of your root repos, not forking them with your organization. However, if you have already forked a repo and want to dump all its open issues to newly created one, what should you do?
Is there any solution on GitHub-2-GitHub issues import?
Though Tekkub answer makes sense, I still implemented a short script to transfer issues:
github.com/..../gh-issues-import
You should delete the newly created one and transfer the repo instead. Transferring repo ownership takes the issues with it.
Tekkub wrote a not-so-well-received answer (-2 as of this writing): "You should delete the newly created one and transfer the repo instead. Transferring repo ownership takes the issues with it." He isn't wrong; he just didn't walk through any of the considerations and gotchas. I'll enumerate a few of those below ...
Only Works if you have "admin" access to the parent repo:
In my case, I couldn't use repo-migration because I don't "own" the parent repo so I can't authorize the transfer (parent repo in the hands of a team-member who left). So it doesn't work for me. HOWEVER ... if you do in fact have admin privileges to the parent repo you are migrating, then using the "transfer repo" function is distinctly better and nowhere near as hard as it sounds.
Git history - trivial to keep
One of the commenters expressed concern over the new repo having its own history they don't want to lose. Well, that's the magic of git as a distributed VCS. You simply pull down all branches and tags and everything else to your local repo and then push that history up to the repo you are going to migrate.
git remote add origin1 https://github.com/blah/blah
git remote add origin2 https://github.com/blah/blah
git pull origin1
git push origin2
If you've created issues in both repos ... well that's screwed
Decide which repo has more important content, use that as the base, and port everything else into there. It's a "merge". good luck. The gh-issues-import.py script script posted by ibo.ezhe helps, but it doesn't restore comments on the issues. Feel free to improve it and send him a PullRequest (I did).
There's a Chrome Extension called Kamino that my colleague wrote. It's open source, and works extraordinarily well. It's more for copying issues individually, but he's looking at doing bulk copies as well.
Available here: https://chrome.google.com/webstore/detail/kamino/ffdebockfdjileaojbbccofhgncmioaf
Source code:
http://github.com/gatewayapps/kamino