How do I move a code repository while preserving branches and tags?
Quick answer
Before switching, compare the source and destination repository’s branch names, tag names, and commit history. For GitHub’s documented command-line import route, a bare clone followed by a mirror push copies references such as branches and tags; large files may cause a warning or error. [S1] Verify the result rather than assuming the transfer worked, and separately check settings and collaboration records because source-code imports do not necessarily include them. [S2]
The question, the details, the next step.
How do I move a code repository while preserving branches and tags?
Treat the move as a transfer plus a verification pass—not just a successful upload. Before starting, record what matters in the source repository: branch names, tag names, and the commit history you expect to retain. Then make the transfer using a method supported by your destination host and compare the destination against that record before asking the team to switch.
For GitHub, its documented command-line import procedure uses a bare clone of the source followed by a mirror push to the new repository. The documentation says this copies references such as branches and tags, and warns that large files may produce a warning or error. [S1] That describes this GitHub import route; it is not a guarantee for every host or every migration method.
What exactly should I compare after the transfer?
Compare the same categories on both sides, using a consistent inventory or inspection method:
- Branches: Check that each expected branch name is present at the destination. If particular branches are important to your team, confirm those individually rather than relying only on a total.
- Tags: Check expected tag names, especially any your team uses to identify releases or milestones.
- Commit history: Inspect representative history on important branches and confirm that the expected earlier revisions are available. A source-code import can include revision history, but the import guidance does not establish that every platform or migration method preserves identical content. [S2]
- Transfer warnings: Record any warnings or errors and investigate them before switching. GitHub’s procedure specifically notes possible warnings or errors for large files. [S1]
A matching branch or tag name alone is not proof that all expected repository content arrived. Use the source as your comparison baseline.
Does a successful repository import move our pull requests, issues, and settings too?
Do not assume so. GitHub’s command-line source-code import guidance says these tools import source code and revision history only; settings and collaboration history, including issues and pull requests, require more advanced tools. [S2] Make a separate inventory of anything your team needs beyond the repository’s code and history, then confirm how your chosen migration method handles each item.
For example, keep two sign-off sections: “repository contents verified” and “platform setup and collaboration data reviewed.” The second section might include the settings or records your team relies on, but the right items depend on your project and migration route. The cited guidance does not establish what a different host or migration tool will transfer.
Can you give me a simple verification record to use before we switch?
Use a short record that makes the comparison and any unresolved differences visible. Replace the bracketed fields with your own details; this is a planning template, not a claim that any migration has passed.
Repository migration check
- Source: [host / repository]
- Destination: [host / repository]
- Comparison date: [date]
- Transfer method: [method]
- Expected branches recorded: [yes/no; notes]
- Expected tags recorded: [yes/no; notes]
- Important commit history reviewed: [yes/no; branches or examples checked]
- Warnings or errors reviewed: [yes/no; details]
- Settings and collaboration data handled separately: [yes/no/not applicable; notes]
- Differences still to resolve: [list or “none identified”]
- Switch approved by: [team role or name]
Only mark a check complete after comparing the destination with the source baseline. If a difference is unexplained, pause the team switch and have the repository owner investigate it.
A practical checklist
Record the source repository and the transfer method before beginning.
Create a baseline list of expected branch and tag names.
Compare destination branches and tags against the source baseline.
Review expected commit history on important branches.
Investigate transfer warnings or errors, including any involving large files.
Track settings and collaboration data separately from code and revision history.
Document unresolved differences before the team switches to the destination.
A few more useful answers
If the branch and tag names match, is that enough to approve the move?
No. Also review the expected commit history and investigate warnings or errors. Matching names are one check, not proof that all expected content arrived.
Will the same import steps work on every hosting platform?
The cited procedure is specifically GitHub’s command-line import route, not a universal guarantee. Check the destination host’s guidance for the method you plan to use.
Should we switch the team over immediately after the transfer?
First compare the destination with your source baseline, record unresolved differences, and review any separately required settings or collaboration data. Switch only after the appropriate repository owner has reviewed the results.
Sources
References used for this guide.
- [S1] Importing an external Git repository using the command line docs.github.com · Checked
- [S2] About source code imports using the command line docs.github.com · Checked