{infiniteZest}
// Articles. Tutorials. Utilities.
Home  |   Search  |   Login  
Categories Skip Navigation Links
New / All
AJAX
Apple
ASP.NET
.NET
Git
Google / Android
Python / IronPython
Miscellaneous
SQL Server
Pushing the New Git Repository to Server
Summary
This article talks about the steps involved in pushing a newly migrated Git repository to a server location.
 
Table of Contents

Basic migration from SVN to Git

Pushing to the new repository to server

Create a new bare repository

Push the branches

Pushing the branches to remote

Test with Cloning

One-way migration from SVN to Git

 
Article Series
Previous Article:
One-way migration from SVN to Git
This article is part of the Series:
Article Series: Migrating from Subversion to Git
Next Article: This is the Last Article of the Series

Basic migration from SVN to Git

The basic migration from SVN to Git is detailed in this article:

Basic Migration from SVN to Git

Pushing to the new repository to server

Once the cleanup after the migration is completed, it needs to be pushed to the server so that the repository is available to everybody.

Create a new bare repository

Now that the Subversion repository has been migrated to git and cleanup has been performed. We need to move this repository into a git server repository. Here the goal is to do away with the Subversion link and make git as the sole repository.

So, the first step would be creating a bare (empty) repository.

$ git init --bare appname.git
Initialized empty Git repository in /Users/username/Documents/repdir/appname.git/

Above command would create an empty git repository in the local directory you are in. Hosted sites like gitHub have gui interface to creating repository.

The config file in the appname.git directory will have the following config information. The refs will be empty.

 [core]
repositoryformatversion = 0
filemode = true
bare = true
ignorecase = true

This repository is now ready to receive the branches.

Push the branches

Go to the directory where you migrated the svn repository to git repository.

You need to tell that git repository that a remote server exits. A remote can be added with the following command:

$ git remote add remsrv file:///Users/user/Documents/repdir/projname.git

In the above command, remsrv is the alias for the remote server – you could call it origin. And the parameter after that is the newly created bare server git repository. In this case, that repository has been created locally, but it would typically be on a server.

With this remote entry, the config file (in .git/config) will get a new entry for the remote:

 [remote " remsrv "]
url = file:///Users/user/Documents/repdir/projname.git
fetch = +refs/heads/*:refs/remotes/remsrv /*

The above configuration only allows for fetching. But here you will be pushing from the clean local git repository to the server repository. For that you need to add a Refspec for push:

push = +refs/heads/*:refs/heads/*

That is essentially saying that take the branches in .git/refs/heads (these are local branches in the git repository we cleaned up) and put them in the server repository – projname.git/refs/heads.

If you want to do the same for tags, a similar refspec needs to be added.

push = +refs/tags/*:refs/tags/*

Pushing the branches to remote

Now a git push will send all these branches/tags to the server repository.

$ git push remsrv

You don’t need to specify individual branches – all of them will be pushed to the server.

Test with Cloning

Now you can discard the git repository that was created as a part of migration (obviously, in this case, you won’t be using Subversion anymore, but the newly created/filled git server repository will be used).

However, you can test whether the migration has been completed properly by cloning from that server repository:

$ git clone file:///Users/username/Documents/projdir/projname.git
Cloning into ‘appdir’...
remote: Counting objects: 4925, done.
Etc.

You can check whether all the branches are showing up properly, by using: git branch -a. You can then go to a few branches and do a git log to see where the last commit was.

If you have a server setup, more than likely, there will be a username and password.

You can automate this with git config file.

$ git config --global user.name "username"
$ git config --global user.email "username@username.com"

As discussed in the above sections, you can first use the local machine as the server (using file:///...) Once that is successful, the code can be pushed to the final server.

This newly cloned repository (either from the local server or a ‘real’ server) won’t be bare, as you can see from below:

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = https://projsrv.com/proj.git
[branch "master"]
remote = origin
merge = refs/heads/master

That completes the migration from Subversion to Git.

One-way migration from SVN to Git

You can find out more about the one-way migration from SVN to Git from this article (It also includes notes and thoughts on cleaning up the local git repository before pushing it to the server):

One-way migration from SVN to Git

Article Series
Previous Article:
One-way migration from SVN to Git
This article is part of the Series:
Article Series: Migrating from Subversion to Git
Next Article: This is the Last Article of the Series
Bookmark and Share This

More Articles With Similar Tags
icon-git-install.jpg
By default, git is available on the Mountain Lion. However, it is not added to the path. This article also discusses getting the git via Command Line Tools.
icon-svn-to-git.jpg
Tags: git, svn, subversion
This article talks about migrating a repository from SVN to Git one way – meaning, after the migration, the project is expected to be developed only in Git. It also talks about the cleanup of the migrated Git repository.
This article talks about the important aspects of migrating a repository from Subversion (SVN) to Git Version Control System.
This series of articles explains migrating Subversion repositories into Git.
About  Contact  Privacy Policy  Site Map