# Remote Repos

PRH Gitlab offers a centralized location for the storage of git repositories.

Why use PRH Gitlab?

* Protected by being housed on PRH servers -- in Westminster, Maryland.
* Full server back-ups ever night
* Long-term off-site backups
* Soon will have redundant fail-over to NY Server Closet.
* Central location for all PRH git-backed projects.&#x20;

## Getting Started with Remotes

Easiest way to pull and push code is to leverage ssh key-pairs -- allowing you to interact with the repo without the need for typing in your username and password multiple times. 1. Shell into wmsandbox 2. Run the following (hitting enter for all prompts)

```bash
]$ ssh-keygen
```

1. cd into the .ssh directory&#x20;

   ```bash
   ]$cd .ssh
   ```
2. cat the&#x20;

   ```bash
   ]$ cat id_rsa.pub
   ```
3. Copy the contents of the file that are echo'ed to your screen
4. Back in your web browser, click the 'Add SSH Key' button
5. Name your key, and paste the contents from your id\_rsa.pub file into the 'Key' input field.&#x20;

Now you'll be able to easily clone, pull, and push into git repos on PRH Gitlab (assuming you have proper permissions on the repositories themselves).

## Cloning

Pulling down a copy of an existing repo is called 'Cloning'

For example:

```bash
]$ git clone git@git.us.randomhouse.com:git-training/example.git
```

The above will create the 'example' local directory, and clone the contents of the 'example' git repo from our PRH git server.

Now that we have a local copy, treat work with it as you would have earlier.

In this example, we'll only work with the 'master' branch (assuming the master branch is the default when a clone is made from our remote repo).

`Make some local edits...`

```bash
]$ git commit -am "I made some changes"
]$ git push origin master
```

The above will work if you are the only one working on that branch of the remote repo.

What happens if another person has committed and pushed while you were working?

```bash
]$ git push origin master 

To git@git.us.randomhouse.com:git-training/example.git
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'git@git.us.randomhouse.com:git-training/example.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
```

Oops...we cannot push until we pull the remote changes in.

```bash
]$ git pull origin master 

remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From git.us.randomhouse.com:git-training/example
 * branch            master     -> FETCH_HEAD
   d860719..1727c33  master     -> origin/master
Auto-merging readme.md
CONFLICT (content): Merge conflict in readme.md
Automatic merge failed; fix conflicts and then commit the result.
```

Git will attempt to auto-merge. But sometimes, if edits happen from two different people on the same line in a file, the result is a conflict (as you see above).

Now, we just need to locally edit the file, make it how it should be, and commit and push again.

`...make edits...`

```bash
]$ git commit -am "Resolved conflicts"
]$ git push origin master

Counting objects: 10, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (6/6), 601 bytes | 0 bytes/s, done.
Total 6 (delta 1), reused 0 (delta 0)
To git@git.us.randomhouse.com:git-training/example.git
   1727c33..73237c0  master -> master
```

Now we are good to go.
