Migrating private repos to GitHub and A guide to using Git LFS
Sometimes you've got to move Repos between providers or accounts, normally this is smooth sailing but there can be some hassle in migrations with large files, this deals with the quickest way around these problems.
Recently, my team has decided to move away from our current BitBucket solution to GitHub, it offers better and a broader range of integrations has a better set of tools and is slowly becoming the company standard.
We have a lot of legacy repos, at first, we thought we could use GitHub's built-in migration tool, and it's definitely what I'd recommend but if you're using private repos with SSO it isn't always reliable. We needed a slightly different approach!
Migration
So to migrate first, we need to create a new one with your new provider and copy the link, then we have to clone our original Bitbucket repo;
$ git clone git@bitbucket.org:<group>/<project>.git
Then we need to create a remote upstream link to our new repo;
$ git remote add upstream git@github.com:<team>/<new-repo>.git
From here we can just push our branches and tags up ;
$ git push upstream master
$ git push --tags upstream
You'll need to push each branch individually, but it'll enable you to move everything, pretty easily, while maintaining your commits and version history.
After moving all your branches, sanity check both repos, if everything is there feel free to delete your old repos and start working with your new ones!
While migrating you might run into a problem with larger file sizes, GitHub has a file size limit of 100mb and prompts you to use Git LFS to manage these files.
But what is Git LFS, how does it store these bigger files and how do we use it?
Git LFS
Large binary files can be a pain to manage, even if they're under the 100mb limit, they bloat your local repo's size and often you don't even need older versions of these files.
Git Large File Store (LFS) is the git project's approach to dealing with large binary files. LFS is an extension on git that expands the functionality for dealing with larger files by not actually storing them in your local repo or working copy. Instead, it uses pointers to the files and stores the objects to a separate LFS Store, using this reference to pull them in only when needed.
This all means a smaller local store, and an easier time dealing with these files, if you want to read more about how if functions you can start with the docs or some guides explaining it more indepth.
Using LFS
So to store these larger files you'll first need to install git lfs, you can do it from the website or using most package managers.
Then you need to "install" LFS functionality in each repo before tracking your files;
$ git lfs install
$ git track "file.zip"
This will generate a .gitattributes file which you'll need to add to the repo, it stores the files that LFS is tracking;
$ git add .gitattributes
Then you just add the files normally and push to your heart's content;
$ git add <file.zip>
$ git commit -m "Add .zip file with lfs"
$ git push origin master
When migrating repos, you might have a load of these files, you can track the extension instead of the generic file name git track "*.zip"
But if you're migrating repos you may have these big files throughout the history, which will mean you'll run into the same errors on a push, we'll need to update the version history to change it to pointers using the migrate keyword;
$ git lfs migrate import --everything --include="*.zip"
At this point, you'll be able to push normally again and your files will all be stored in the correct places. LFS has a wealth of features that are worth looking into for your large files and other blob data that can prove really useful.
It's worth mentioning, .gitattributes is a pretty useful file, it manages a lot of how the repo behaves, this post covers getting started with it really well:
With all this, you should be able to migrate your repo providers, large files and all, good luck moving migrating!
Cover image from here
Top comments (0)