How to create a remote Git repository from a local one

Question

I have a local Git repository  I would like to make it available on a remote  ssh-enabled  server  How do I do this

User · Answer

A note for people who created the local copy on Windows and want to create a corresponding remote repository on a Unix-line system, where text files get LF endings on further clones by developers on Unix-like systems, but CRLF endings on Windows.

If you created your Windows repository before setting up line-ending translation then you have a problem. Git's default setting is no translation, so your working set uses CRLF but your repository (i.e. the data stored under .git) has saved the files as CRLF too.

When you push to the remote, the saved files are copied as-is, no line ending translation occurs. (Line ending translation occurs when files are commited to a repository, not when repositories are pushed). You end up with CRLF in your Unix-like repository, which is not what you want.

To get LF in the remote repository you have to make sure LF is in the local repository first, by re-normalizing your Windows repository. This will have no visible effect on your Windows working set, which still has CRLF endings, however when you push to remote, the remote will get LF correctly.

I'm not sure if there's an easy way to tell what line endings you have in your Windows repository - I guess you could test it by setting core.autocrlf=false and then cloning (If the repo has LF endings, the clone will have LF too).

User · Answer

I think you make a bare repository on the remote side  git init --bare  add the remote side as the push pull tracker for your local repository  git remote add origin URL   and then locally you just say git push origin master  Now any other repository can pull from the remote repository

User · Answer

Normally you can set up a git repo by just using the init command  git init   In your case  there is already a repo on a remote available  Dependent on how you access your remote repo   with username inside the url or a ssh key which handles verification   use just the clone command   git clone git  my url com   git-repo-name  git   There are also other ways to clone the repo  This way you call it if you have a ssh key setup on your machine which verifies on pulling your repository  There are other combinations of the url if you want to include your password and username inside to login into your remote repository

User · Answer

There is an interesting difference between the two popular solutions above    If you create the bare repository like this    cd      outside of any repo mkdir  my remote git cd     my remote git git init --bare    and then  cd   your path original repo git remote add origin  outside of any repo my remote git git push --set-upstream origin master   Then git sets up the configuration in  original repo  with this relationship   original repo origin -- gt   outside of any repo my remote git    with the latter as the upstream remote   And the upstream remote doesn t have any other remotes in its configuration    However  if you do it the other way around     from in directory original repo  cd    git clone --bare original repo   outside of any repo my remote git    then  my remote git  winds up with its configuration having  origin  pointing back to  original repo  as a remote  with a remote origin url equating to local directory path  which might not be appropriate if it is going to be moved to a server   While that  remote  reference is easy to get rid of later if it isn t appropriate   original repo  still has to be set up to point to  my remote git  as an up-stream remote  or to wherever it is going to be shared from    So technically  you can arrive at the same result with a few more steps with approach  2   But  1 seems a more direct approach to creating a  central bare shared repo  originating from a local one  appropriate for moving to a server  with fewer steps involved   I think it depends on the role you want the remote repo to play    And yes  this is in conflict with the documentation here    Caveat   I learned the above  at this writing in early August 2019  by doing a test on my local system with a real repo  and then doing a file-by-file comparison between the results   But   I am still learning  so there could be a more correct way   But my tests have helped me conclude that  1 is my currently-preferred method

User · Answer

In current code folder  git remote add origin http   yourdomain-of-git com project git git push --set-upstream origin master  Then review by git remote --v

User · Answer

You need to create a directory on a remote server  Then use  git init  command to set it as a repository  This should be done for each new project you have  each new folder   Assuming you have already setup and used git using ssh keys  I wrote a small Python script  which when executed from a working directory will set up a remote and initialize the directory as a git repo  Of course  you will have to edit script  only once  to tell it server and Root path for all repositories   Check here - https   github com skbobade ocgi

User · Answer

In order to initially set up any Git server  you have to export an existing repository into a new bare repository     a repository that doesn   t contain a working directory  This is generally straightforward to do  In order to clone your repository to create a new bare repository  you run the clone command with the --bare option  By convention  bare repository directories end in  git  like so     git clone --bare my project my project git Initialized empty Git repository in  opt projects my project git    This command takes the Git repository by itself  without a working directory  and creates a directory specifically for it alone   Now that you have a bare copy of your repository  all you need to do is put it on a server and set up your protocols  Let   s say you   ve set up a server called git example com that you have SSH access to  and you want to store all your Git repositories under the  opt git directory  You can set up your new repository by copying your bare repository over     scp -r my project git user git example com  opt git   At this point  other users who have SSH access to the same server which has read-access to the  opt git directory can clone your repository by running    git clone user git example com  opt git my project git   If a user SSHs into a server and has write access to the  opt git my project git directory  they will also automatically have push access  Git will automatically add group write permissions to a repository properly if you run the git init command with the --shared option     ssh user git example com   cd  opt git my project git   git init --bare --shared   It is very easy to take a Git repository  create a bare version  and place it on a server to which you and your collaborators have SSH access  Now you   re ready to collaborate on the same project

User · Answer

A remote repository is generally a bare repository     a Git repository   that has no working directory  Because the repository is only used as   a collaboration point  there is no reason to have a snapshot checked   out on disk  it   s just the Git data  In the simplest terms  a bare   repository is the contents of your project   s  git directory and   nothing else    You can make a bare git repository with the following code     git clone --bare  path to project project git   One options for having a remote git repository is using SSH protocol      A common transport protocol for Git when self-hosting is over SSH    This is because SSH access to servers is already set up in most   places     and if it isn   t  it   s easy to do  SSH is also an   authenticated network protocol and  because it   s ubiquitous  it   s   generally easy to set up and use       To clone a Git repository over SSH  you can specify an ssh    URL   like this     git clone ssh    user  server project git       Or you can use the shorter scp-like syntax for the SSH protocol     git clone  user  server project git       In both cases above  if you don   t specify the optional username  Git   assumes the user you   re currently logged in as       The Pros      The pros of using SSH are many  First  SSH is relatively easy to set   up     SSH daemons are commonplace  many network admins have experience   with them  and many OS distributions are set up with them or have   tools to manage them  Next  access over SSH is secure     all data   transfer is encrypted and authenticated  Last  like the HTTPS  Git and   Local protocols  SSH is efficient  making the data as compact as   possible before transferring it       The Cons      The negative aspect of SSH is that it doesn   t support anonymous access   to your Git repository  If you   re using SSH  people must have SSH   access to your machine  even in a read-only capacity  which doesn   t   make SSH conducive to open source projects for which people might   simply want to clone your repository to examine it  If you   re using it   only within your corporate network  SSH may be the only protocol you   need to deal with  If you want to allow anonymous read-only access to   your projects and also want to use SSH  you   ll have to set up SSH for   you to push over but something else for others to fetch from    For more information  check the reference  Git on the Server - The Protocols

[git] How to create a remote Git repository from a local one?

Examples related to git

Examples related to installation