# Working on GitLab by mirroring open source model

Table of Content

### Clone open source model to GitLab

Taking an ocean model ROMS as an example, let's consider the best practice of operating the ROMS repositories by cloning (not forking) the original ROMS repository to GitLab, where the mirroring is set to automatically import the update of the original repository. Please refer to this article for the settings up to this point.
I will create and operate my own devel branch to avoid changing the repository cloned from the original repository on GitLab.
Now the remote repository is GitLab cloning (mirroring) the original ROMS repository; local repository is operated using GitBash on Windows 10 Pro and Git on Supercomputer ITO.

### Final workflow

The target final workflow is shown below. The repository cloned from the ROMS master branch (Origin in the figure) to GitLab is automatically updated by mirroring, which is the master branch on GitLab (ROMS has many other branches. However, I will not consider them here.)
Create a devel branch in GitLab for your own development (Commit D1 in the figure). We will proceed with development in this devel branch (Commit D4 is the latest version). During that time, suppose the master branch is updated and Commit M2 happens. Suppose we decide to merge Commit M2 from the master branch with the latest commit (Commit D4) from the devel branch. If there are conflicts between the two, it is necessary to resolve the conflicts on the devel branch side. Such a method is called rebase.
The result of executing this rebase is shown in the lower panel of the figure. It means Merging on the devel branch side and generating Commit D5. As a result, the devel branch of Commit D5 becomes a branch from the master branch of Commit M2. Similarly, by rebasing the latest commit of the master branch into the devel branch, you can continue development on the devel branch without changing the master branch.
You can also perform normal Git tasks, such as branching from the devel branch to a new branch for specific development, then merging it into the devel branch.
Below is a summary of specific methods, including working locally.

### Create devel branch with GitLab

To create a devel branch on GitLab, click Branches just below the Project name on the top page of the Project (ROMS in this example). Next, click on the green icon New branch in the upper right corner and enter Branch name (devel in this example) in the form that appears, and Create from should be the default master. Finally, click the green icon Create branch that appears in the lower left.

### set GitLab devel branch as default

We will always work on the devel branch, so make the devel branch the default. This makes later operations easier.
Open GitLab Project (ROMS in this example), and click Expand button of SettingsRepositoryDefault Branch.

Select devel from the pull-down menu of Default Branch and click the Save changes button.

### Clone project locally

When doing actual development, first, clone the GitLab project (ROMS in this example) locally. Please refer to here.
Prepare a local working directory for Clone. For example, to create a work directory just under cal directory in c drive and clone it, do the following. After git clone, move to the directory with the project name of the cloned directory.

$cd /c/cal$ mkdir work
$cd work$ git clone git@gitlab:username/project.git
$cd project ### Verify branch locally On Windows, use Git Bash to move to the Clone directory. Immediately after Clone, it should be already on the devel branch. #Check current branch$ git branch
* devel

You may view local branches and GitLab branches (remote tracking branches).

### Rebase GitLab's master branch into devel branch

This will be summarized after it is actually needed.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Previous article

Next article