30

So, total newbie to Git. Been reading through the guides and think I have the basics but am having difficulties accomplishing this one goal.

I have a repo created for my generic markup source code. Just stuff I reuse for every breakout. It's called markupDNA.git

I would like to have different directories in my mac sites dir ~/Sites/project-N. Where I build upon the generic stuff and do a breakout of a site. I would like these to be tied to my main git repo as forks, but you cannot fork your own repo?

I wish I could do something like this:

git clone <url> name
git add .
# make changes
git commit -m 'whatever'
git push

But I don't want it to push to origin. I want it to push to a fork of the markupDNA repo whence it was cloned. But it seems like it just pushes my changes right up into the origin master. The idea is to keep the markupDNA clean and just have a lot of forks for my different projects, each of which will have their own cloned dir on my hard drive.

Any ideas?

Fuego DeBassi
  • 2,967
  • 6
  • 29
  • 37
  • possible duplicate of [How do you fork your own project on github?](http://stackoverflow.com/questions/10963878/how-do-you-fork-your-own-project-on-github) – Shane Dec 14 '14 at 14:45

7 Answers7

24

You're doing the right thing.

cd ~/Sites/
git clone ~/Dev/markupDNA/ project-N
cd project-N
git remote rename origin markupDNA
  • Nav to the folder where you store your projects
  • clone your base markupDNA repo with custom name
  • rename the remote so that if you want to an 'origin' later, you can
kubi
  • 48,104
  • 19
  • 94
  • 118
  • 3
    This is exactly what I need to use my skeleton application. It would be crazy to create a branch for every project that uses the skeleton application... and this way, I can still pull updates from the skeleton – NDM Jan 27 '13 at 01:14
  • 1
    When you then need to update with changes from your skeleton app you can use `git pull MarkupDNA master` – Nick Nov 12 '15 at 10:55
21

It will probably be a lot easier to use branches, rather than using separate forks. You can still have separate checkouts for each branch; just clone your repo multiple times, and use git checkout in each one to switch it to the appropriate branch (or git checkout -b to create the branch and check it out all at once). Once you have created the branches, you can push them to GitHub using git push origin <branchname>.

Brian Campbell
  • 322,767
  • 57
  • 360
  • 340
  • This seems like a good way to go about it. But when I clone my repo, make a new branch, edit from that branch and try to do a "git push git@github.com:rorourke/markupDNA.git" the branch doesn't appear up on github? – Fuego DeBassi Sep 22 '10 at 21:51
  • 1
    You need to do "git push origin " to create the new branch on the remote. I'm surprised the command you quoted doesn't give an error, or does it? – ebneter Sep 22 '10 at 23:33
  • @Fuego as ebneter says, you need to specify the branch name you are pushing when pushing new branches to GitHub. – Brian Campbell Sep 22 '10 at 23:44
  • If you want to use multiple checkouts, you should use the `--shared` option to clone subsequent copies from the first. This option will use objects from the first repository, saving you from having two copies on the disk. Read the manual page about it! – George Hilliard Jun 19 '14 at 13:48
  • 1
    Use of branches is not the same thing. In fact, it is only a partial workaround as you cannot use separate issues and separate wiki. – Alen Pelin Feb 14 '17 at 03:58
11

This tutorial gives a simple and straightforward answer :

  1. Create a new empty github forkedreporepository

  2. Clone it locally:

    git clone https://github.com/YOURUSERNAME/forkedrepo.git

  3. Add the original github repository as remote of the new local repository:

    git remote add upstream https://github.com/YOURUSERNAME/originalrepo.git

  4. Pull down a copy of the original github repository to your new local repository:

    git pull upstream master

  5. Push the files from your new local repository to new github repository:

    git push origin master

This won't be recognized by github as a fork of the original repository, off course, but this is as good as it gets.

Walt Ritscher
  • 6,977
  • 1
  • 28
  • 35
clemlatz
  • 7,543
  • 4
  • 37
  • 51
10

Surprised no-one has referenced this guy's blog post yet.

Here's the relevant steps:

$ git clone git@github.com:YOURNAME/foo.git bar
$ cd bar
$ vim .git/config
[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*
    url = git@github.com:YOURNAME/bar.git #replace foo with bar
$ git remote add upstream git@github.com:YOURNAME/foo.git
$ git push -u origin master

Instead of editing the config, I usually use a combination of git remote remove and git remote add.

You could also use git remote rename followed by git remote add if you wanted to keep the upstream origin around.

funroll
  • 35,925
  • 7
  • 54
  • 59
  • Just curious but why would you want to fork your own project? – yan Jul 10 '14 at 09:19
  • One reason is if you are going to clean it up but want a record of the old history. For example, deleting lots of old branches and tags. – funroll Jul 10 '14 at 19:09
  • 3
    The use of vim is a little silly when there are already git commands to make the appropriate edits: `$ git clone git@github.com:YOURNAME/foo.git bar`, `$ cd bar`, `$ git remote rename origin upstream`, `$ git remote add origin git@github.com:YOURNAME/bar.git`, and then `$ git push -u origin master`. – user139901 Sep 11 '14 at 18:31
  • 1
    @B.Garvin Had the same thought. Feel free to edit my answer if you so desire. – funroll Sep 11 '14 at 19:48
  • @funroll Wow, I guess I must not have read very carefully, as, yes, you already say everything in my comment. Sorry about that. – user139901 Sep 11 '14 at 23:56
  • @B.Garvin No worries! I wasn't trying to be snarky, btw... I actually didn't notice that I had already mentioned those commands at the time I wrote the comment. Thanks for your suggestion. – funroll Sep 15 '14 at 13:13
9

to make true GitHub fork of own repository you can use this steps:

  1. Create an organization
  2. Fork to organization
  3. Rename forked project
  4. Move back to your account
cnd
  • 32,616
  • 62
  • 183
  • 313
  • 3
    I get "rdp already has a repo in the rdp/screen-capture-recorder-to-video-windows-free network" when I "Transfer Ownership" back to myself. But I can use the copy that's found in the organization, thanks! – rogerdpack May 15 '12 at 17:52
  • Yes, I got the same error... I can't even fork that forked project back to myself after renaming. Wish I could make GitHub "forget" it was a fork somehow... – Adam Burley Sep 30 '12 at 15:00
  • Can you elaborate on how to use `git pull-rebase upstream master` i dont understand that. This method in the post throws the error on trying to `4. move back to your account` – Noitidart May 24 '14 at 23:40
  • Yes seems like this method doesn't work anymore in github. with "fork in git" I wanted to say that you can just push to another remote/repository but then it will not be a fork in github terms. – cnd May 25 '14 at 04:58
  • 3
    For private repo this did not work, when trying to move it back..."This repo is not transferrable. Please contact the owner of the root repo" – Eddie Jaoude Jun 06 '14 at 11:32
  • @EddieJaoude Did you figure this out? – Nick Jan 06 '15 at 14:13
  • @Nick No, I don't think so :( – Eddie Jaoude Jan 07 '15 at 14:30
1

You can also use Github's import tool.

(it's made for importing from SVN, etc. but you can use it for this too)

  • Create new repository in Github. IMPORTANT: don't "initialize with a README"
  • On the next screen click "Import code"
  • Paste the URL to the Github repo you want to import. (screenshot)

Again, this is creating a new repository and not a true fork on Github. But all your branches, history, etc will be there.

mihow
  • 334
  • 4
  • 13
1

Sure you can clone from a clone. In git there is no concept of a main repo. People often designate a main repo, but that is by convention, not because of a technical reason.

So you can do everything exactly as you describe and even more.

For example it makes sense to keep a branch in your breakout sites with ideas for additions or modifications to your generic stuff. You can pull these up towards your generic repo and distribute again from there.

Peter Tillemans
  • 34,983
  • 11
  • 83
  • 114