Overview

Code repositories are hosted on the cloud version of GitLab, GitLab.com. Our GitLab subscription level is Gold, which includes all features offered by GitLab.

Invites to your team’s GitLab group were emailed on Friday, 6/24. Please let your project manager know if you did not receive an invite after also checking your spam folder (and if you are a UCSD student, checking your campus quarantined emails).

Please refer to the GitLab project creation guide to create projects within your team’s subgroup as needed.

Recommended Reading

GitLab documentation is very helpful. Recommended reading:

• Getting Started

• Create Team Wiki

• Manage Design Materials

General Terms

Code Repositories: This is where all the code will be stored. From here you can push and pull code as your team works on the project.

Pushing Code: You are adding your most recent changes to the repository.

Pulling Code: You are grabbing the most recent version of your project and putting it on your local machine.

Check-in Code: This means to upload code to the master branch so the admin can check and update the project. (The same thing as pulling but done on the master branch)

Branches: A branch is just a line of development. When coding, you should always work on lines of development that are not the main line. This way if one branch completely breaks, the main branch where the majority of the code is will be fine.

Merging: Simply, you are putting the code of one branch onto another. Generally, when you have code on one branch that is done, you merge it onto the main branch.

RDS Quick Start Repo Guide

Clone

To clone a repository to begin contributing to it, run git clone https://gitlab.com/sdsc-rds/[REPOSITORY PATH].git. This should create a copy of the repo saved locally on your machine. To find the url for a repository that you would like to clone, first navigate to the repository on GitLab. Then, you can click “Clone” in the upper right and choose between SSH or HTTPS.

Open

To use SSH, you will need to have added an SSH key to your GitLab account. To use HTTPS, you will just need to know your username and password.

Branch

You want to keep development to a separate branch on your local machine to avoid conflicts. The general structure during development will look like this

Run:

1. git checkout dev

2. git branch [BRANCH NAME]

3. git checkout [BRANCH NAME]

You have now created a new branch that is a copy of dev and can begin development. Typically you would name the branch something related to what you are implementing.

Make Changes

Make whatever changes might be needed to do what you need. Commit often so you don’t lose your progress.

Push Changes

To push changes, the general workflow is:

1. checkout dev - git checkout dev

2. pull to update dev - git pull

3. checkout your feature branch - git checkout [BRANCH NAME]

4. merge dev into your feature branch - git merge dev

5. resolve any merge conflicts

6. test to make sure everything works

7. push your feature branch to the repository - git push -u origin [BRANCH NAME]

8. submit a merge request from your feature branch to dev

Submit a Merge Request

At this point in the guide, you have implemented a new feature and correctly pushed it to the dev branch. It’s not on the master branch yet. After the new feature is deemed to be prod-ready, you want to get those changes onto the master branch to go out into production.

1. Go to the GitLab repository page

2. On the left side, click the “Merge Requests” tab

3. Click “New Merge Request”

4. Select the source branch to be dev

5. Select the target branch to be master

6. Click Compare branches and continue

7. Fill out the necessary fields

8. Click submit merge request

Open