\n Just git clone the repo and you’re set!!<\/p><\/blockquote>\n
However, what we want with mirroring is to replicate the state of an origin repository (or upstream repository). By state, we mean all the branches (including You’ll need to do this when migrating your upstream repository to a new “home”, like when switching services like GitHub.<\/p>\n As with most tools, there’s a lot of ways to accomplish that, but I’ll be focusing on two of them. The difference lays on whether you already have a working copy of that repository or not.<\/p>\n If you haven’t cloned the repository before, you can mirror it to a new home by<\/p>\n This will get all the branches and tags that are available in the upstream repository and will replicate those into the new location.<\/p>\n Don’t use Also By working copy, we mean a “normal” repository, in which you have the files that are being tracked into git and where you perform commands like In this case, you may have a lot of local branches and tags that you don’t want to copy to the new location. But you do have references to remote branches. You can view them with By default, when you do a To do so, run<\/p>\n This will update your references to the origin repository and also clean the stale branches reported by Now we’re ready to send those updated references back to the Ok, what just happened here?!<\/p>\n We want those references inside the The Git is certainly not an easy tool to learn. Although when you do, it turns into a very powerful and flexible tool.<\/p>\n If you want to learn more about it, please see the excelent book written by Scott Chacon and available for free<\/a>.<\/p>\n What about you? Have any tips on git you want to share?<\/p>\n \n When people talk about mirroring a git repository, usually we have a simple answer in mind: Just git clone the repo and you’re set!! However, what we want with mirroring is to replicate the state of an origin repository (or upstream repository). By state, we mean all the branches (including master) and all the tags … \u00bb<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[1],"tags":[147,202],"aioseo_notices":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/3463"}],"collection":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/comments?post=3463"}],"version-history":[{"count":26,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/3463\/revisions"}],"predecessor-version":[{"id":9529,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/3463\/revisions\/9529"}],"wp:attachment":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/media?parent=3463"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/categories?post=3463"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/tags?post=3463"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}master<\/code>) and all the tags as well.<\/p>\nMirroring a git repository without a local copy<\/h2>\n
$ git clone --mirror git@example.com\/upstream-repository.git\n$ cd upstream-repository.git\n$ git push --mirror git@example.com\/new-location.git\n<\/pre>\n
Warning<\/h3>\n
git push --mirror<\/code> in repositories that weren’t cloned by --mirror<\/code> as well. It’ll overwrite the remote repository with your local references (and your local branches). This is not what we want. Read the next section to discover what to do in these cases.<\/p>\ngit clone --mirror<\/code> is prefered over git clone --bare<\/code> because the former also clones git notes and some other attributes.<\/p>\nMirroring a git repository if you already have a local working copy<\/h2>\n
git add<\/code> and so on.<\/p>\ngit branches -r<\/code>. If you pay attention to that list, tough, you may notice that you have a lot of branches that were already deleted in the upstream repository. Why?<\/p>\nCleaning old references to remote branches<\/h3>\n
git fetch<\/code> or git pull<\/code>, git will not delete the references to branches that were deleted in the upstream repository (you may view them in your .git\/refs\/remotes<\/code> dir). We need to clean those old references before mirroring them to a new location.<\/p>\n$ git fetch --prune\n<\/pre>\n
git branch -r<\/code>.<\/p>\nFinally, mirroring the repository to a new location<\/h3>\n
origin<\/code> repository:<\/p>\n$ git push --prune git@example.com:\/new-location.git +refs\/remotes\/origin\/*:refs\/heads\/* +refs\/tags\/*:refs\/tags\/*\n<\/pre>\n
.git\/refs\/remotes\/origin<\/code> to be the LOCAL references in the new location. The local references there will be stored in the refs\/heads<\/code> dir. Same thing happens to tags.<\/p>\n+<\/code> sign indicates that we want to overwrite<\/strong> any reference there may already exist.<\/p>\n--prune<\/code> means we want to delete any reference that may exist there if we don’t have such reference in our refs\/remotes\/origin\/*<\/code> (and tags) references.<\/p>\nConclusion<\/h2>\n
![\"\"](\"https:\/\/no-cache.hubspot.com\/cta\/default\/378213\/2aeae558-5b72-4df3-bf32-e1119f34d85e.png\")
<\/a><\/span><\/span>
\n<\/p>\n","protected":false},"excerpt":{"rendered":"