SU24 Using Git and GitLab
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:
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 main branch so the admin can check and update the project. (The same thing as pulling but done on the main 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
Set Up SSH Keys
Read the following guide on how to set SSH Keys and add them your Gitlab account.
Specially read the See if you have an existing SSH key pair, Generate an SSH key pair , and Add an SSH key to your GitLab account sections
If you have an existing SSH key pair, then skip to the Add an SSH key to your GitLab account.
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.
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. Branching isn’t necessary if you are the only person working on a project, but it’s still good practice to do it.
NOTE: Depending on how your repository is set up, there may be a “dev” branch alongside a “main” branch. In this case, you would want to pull and push from the “dev” branch rather than the “main” branch. In the case of this guide (excluding the last section on merge requests), only the “main” branch will be referenced.
NOTE: As of March 10, 2021, the default branch name for new GitLab repositories is “main”. Repositories created after March 10, 2021 may have a “main” branch instead of a “main” branch. If you are working with a repository that has a “main” branch, make sure to use “main” instead of “main” in all Git command below. See this GitLab blog post for more details.
The general structure during development will look like this
Run:
git checkout main
git branch [BRANCH NAME]
git checkout [BRANCH NAME]
Running these commands will create a new branch that is a copy of main and switch over to it. Typically you would name the branch something related to what you are implementing. (It’s recommended to name the branch to something that’s clear and concise, as you may never know when someone else will take over your progress).
When the new branch is created, you should push the branch to the GitLab Remote Repo. It’s not recommended to only keep your changes locally as they may be accidentally lost. In order to do this, run this command:
git push -u origin [BRANCH NAME]
This will push your local development branch to the remote repository. To check whether the branch was successfully pushed, got to the URL of the repository and check the branch tab to see what branches are currently available.
Make Changes
It is always recommended to push changes whenever you work on something (It doesn’t matter how small the change is, just push whatever you have at the end of the day).
In order to avoid conflicts, you should always push your code to your own development branch and NOT the main branch.
Push Changes
The following steps assumes that there is a dev
branch separate the main branch. To push changes, the general workflow is:
checkout dev -
git checkout dev
pull to update dev -
git pull
checkout your feature branch -
git checkout [BRANCH NAME]
merge dev into your feature branch -
git merge dev
resolve any merge conflicts
test to make sure everything works
push your feature branch to the repository -
git push -u origin [BRANCH NAME]
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 main branch yet. After the new feature is deemed to be prod-ready, you want to get those changes onto the main branch to go out into production.
Go to the GitLab repository page
On the left side, click the “Merge Requests” tab
Click “New Merge Request”
Select the source branch to be dev
Select the target branch to be main
Click Compare branches and continue
Fill out the necessary fields
Click submit merge request