I have a local Git repository. I would like to make it available on a remote, ssh-enabled, server. How do I do this?
This question is related to
git
installation
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 --> /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.
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 [email protected]:/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 [email protected]:/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 [email protected]
$ 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.
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.
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
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.gitOr you can use the shorter scp-like syntax for the SSH protocol:
$ git clone [user@]server:project.gitIn 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
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
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).
Source: Stackoverflow.com