joshjohanning

Rewriting repository history

Sometimes history rewrites are required in order to migrate repositories into github.com. Several factors can dictate the need to rewrite history of a repository:

• objects larger than 100Mb
• commits larger than the 2GB push limit

Although rewriting history might not be required for your repository to migrate to github.com, you may consider rewriting history for several reasons:

• migrate large objects to LFS
• cleanup previous mistakes or bad practices that caused repo bloat
• remove secrets from repo history

joshjohanning

Organization archetypes

The intention of this document is to provide some guidance and suggestions to customers who are wondering how they should structure organizations and teams in their GitHub Enterprise environment. The idea isn't to give hard and fast rules on which approach is better than the other, but to give examples of when one approach might be preferable to another depending on the use case.

1. A single organization with direct organization membership for repository access (not teams)

          ________________
          |     Org      |
          |    ______    |
          |   |      |\  |

| | Repo | \ |

joshjohanning

Migrate git repos script

I used this for migrating git repos from Bitbucket to Github. It uses git's --mirror flag for cloning and pushing to also transfer all tags and branches.

It would be helpful to have SSH keys set up on both ends. Then all you should have to do is to make sure the hardcoded orgname is set to the appropriate one for both the source and destination.

Once I migrated repos, I used this to replace my origin url locally (assumes using ssh):

sed -i s/bitbucket.org:orgname/github.com:orgname/g .git/config