How to commit to gitlab

How to create and commit a branch in gitlab

This is intended as a question that I answer for other people’s benefit. However, if someone answers this question before I finish my research, I would be grateful.

How do I, from the shell, branch an existing git repo (which I have developer access to), edit it, commit those changes then push it to the server for review before being merged.

EDIT

Please note that this is not my project, but someone else’s. This use has given me access to do some work. When done, I will request that they merge the changes back to the original

2 Answers 2

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

For setting up your repo, you will need to follow these instructions. Then you will need to clone/fork the existing repo like this.

Then make your changes. Once you are done making your changes. You will need to make a «commit» that looks like this

Then you will want to pull down any changes from the repo that may have been pushed while you were working.

Once the pull is completed with no conflicts, you may push your changes up.

EDIT To push to a repo without overwriting the master, do this:

If I understand your question correctly:

This is actually a perfectly normal situation, here’s what to do:

On GitLab, fork the project: this creates a clone of the original repository in your personal workspace. The point is that you can push to your personal workspace.

On your PC, clone from your fork, not the original.

On GitLab, visit your fork’s page, and near the top there should be a button offering you to create a Merge Request from the branch that you pushed just now. Click on it, review the changes, if it looks good, then set an assignee and click Create. The assignee should receive an email notification

You don’t need write access to a project to be able to contribute. All your write operations are on your workspace on GitLab and on your local PC. Reviewers of your Merge Request can accept it or reject as they wish. They can also ask that you make improvements, which you can implement and push (simple git push after your local commits), that updates the merge request (reviewers can reload the page in the browser and see your changes).

GitLab Web Editor

Sometimes it’s easier to make quick changes directly from the GitLab interface than to clone the project and use the Git command-line tool. In this feature highlight, we look at how you can create a new file, directory, branch, or tag from the file browser. All of these actions are available from a single dropdown menu.

Create a file

From a project’s files page, select the ‘+’ button to the right of the branch selector. Choose New file from the dropdown.

Enter a filename in the Filename box. Then, add file content in the editor area. Add a descriptive commit message and choose a branch. The branch field defaults to the branch you were viewing in the file browser. If you enter a new branch name, a checkbox displays, allowing you to start a new merge request after you commit the changes.

When you are satisfied with your new file, select Commit Changes at the bottom.

Shortcuts

You can use shortcuts when editing a file through the Web Editor. It uses the same shortcuts as the Web IDE. For details, read the documentation for Command Palette.

Template dropdowns

When starting a new project, there are some common files that the new project might need. GitLab displays a message to help you:

Highlight lines

Web Editor enables you to highlight a single line by adding specially formatted hash information to the URL’s file path segment. For example, the file path segment MY_FILE.js#L3 instructs the Web Editor to highlight line 3.

The Web Editor also enables you to highlight multiple lines using a similar pattern. In this case, the file path segment MY_FILE.js#L3-10 instructs the Web Editor to highlight lines 3 to 10 of the file.

Select Copy Link Address in the context menu.

Upload a file

The ability to create a file is great when the content is text. However, this doesn’t work well for binary data such as images, PDFs, or other binary file types. In this case, you need to upload a file.

From a project’s files page, select the ‘+’ button to the right of the branch selector. Choose Upload file from the dropdown:

After the upload dialog pops up, there are two ways to upload your file. Either drag and drop a file on the popup or use the click to upload link. After you select a file to upload, a file preview displays.

Enter a commit message, choose a branch, and select Upload file when you are ready.

Create a directory

To keep files in the repository organized it is often helpful to create a new directory.

From a project’s files page, select the plus button ( + ) to the right of the branch selector. Choose New directory from the dropdown.

In the new directory dialog, enter a directory name, a commit message, and choose the target branch. Select Create directory to finish.

Create a new branch

There are multiple ways to create a branch from the GitLab web interface.

Create a new branch from an issue

The Create merge request button changed to open the merge request creation form in GitLab 14.8.

If your development workflow requires an issue for every merge request, you can create a branch directly from the issue to speed the process up. The new branch, and later its merge request, are marked as related to this issue. Once merged, the merge request closes the issue. You can see a Create merge request dropdown below the issue description.

To make this button appear, one possible workaround is to remove your project’s fork relationship. After removal, the fork relationship cannot be restored. This project can no longer be able to receive or send merge requests to the source project, or other forks.

This dropdown contains the options Create merge request and branch and Create branch.

Create a new branch from a project’s dashboard

If you want to make changes to several files before creating a new merge request, you can create a new branch upfront.

From a project’s files page, choose New branch from the dropdown.

To return to the file browser on this new branch, select Create branch.

You can now make changes to any files, as needed. When you’re ready to merge the changes back to your default branch, you can use the widget at the top of the screen. This widget only appears for a period of time after you create the branch or modify files.

Create a new tag

Tags help you mark major milestones such as production releases and release candidates. You can create a tag from a branch or a commit SHA:

From a project’s files page, choose New tag from the dropdown.

Select Create tag. GitLab redirects you to the tag list page.

Commit your changes, and GitLab redirects you to a new merge request form.

If you’d prefer to not use your primary email address for commits created through the web editor, you can choose to use another of your linked email addresses from the User Settings > Edit Profile page.

Description

Git commands are used for sharing and combining the code easily with other developers.

Git Commands

Following are the some basic Git commands can be used to work with Git −

The version of the Git can be checked by using the below command −

Add Git username and email address to identify the author while committing the information. Set the username by using the command as −

After entering user name, verify the entered user name with the below command −

Next, set the email address with the below command −

You can verify the entered email address as −

Use the below command to check the entered information −

You can pull the latest changes made to the master branch by using the below command −

You can fetch the latest changes to the working directory with the below command −

Here, NAME-OF-BRANCH could be ‘master’ or any other existing branch.

Create a new branch with the below command −

You can switch from one branch to other branch by using the command as −

Check the changes made to your files with the below command −

You will see the changes in red color and add the files to staging as −

Or you can add all the files to staging as −

Now send your changes to master branch with the below command −

Delete the all changes, except unstaged things by using the below command −

You can delete the all changes along with untracked files by using the command as −

To merge the different branch with the master branch, use the below command −

You can also merge the master branch with the created branch, by using the below command −

m-kyle / README.md

This document is still a work in progress. It will be used as a tutorial to help explain the basics of Git and GitLab to users unfamiliar with them.

Table of Contents

Git is a free and open-source distributed version control system. It is much faster than other alternatives such as subversion or cvs. Git performs almost all operations locally, which gives it a huge speed advantage over centralised systems that have to constantly communicate with a server somewhere.

Git is distributed, which means that even if you’re using a centralised workflow, every user essentially has a full backup of the main server. Each of these copies could be pushed up to replace the main server in the event of a crash or corruption.

This is a web based command line tutorial which allows you to type in the commands into a terminal to practice using Git. If you have never used git before this is a good place to start.

There are several basic commands that are essential to use Git in the command line. See this pdf for a decent overview of some of the commands. This is useful to use as a reference for remembering the commands after completing the tutorial.

Note: If you have any uncomitted changes and perform git pull then you can overright your local changes. Look at the git stash command on how to save your local changes before syncing with server. This is only a problem in the command line, the GitHub desktop app’s do not have this problem.

Git doesn’t just work using the command line interface, it can also be used with an application such as the official GitHub application. This makes it very easy to commit changes to a repository without needing to remember any commands. Using GitLab with the GitHub application can take some extra setup with the command line, but after the initial setup the command line does not need to be used again.

You should be familiar with using git from the command line before starting. See the Command Line section above.

You should now be able to see the added repository in the left column under the Other section label.

You should now be able to see the added repository in the left column under the Other section label.

Git is used differently from Subversion and can be difficult to transition between. Here is a list of some good ways to use Git with some links at the bottom to provide more information.

See these links for more information:

GitLab is an open-source ‘clone’ of GitHub. It’s functionality is very similar to that of GitHub, but because it is open-source it means that we can use it on our servers for free.

GitLab allows us to create and modify multiple Git repositories online. It allows admins to manage each repository, the users, and their groups. It has a simple user interface that is very easy to use.

The screenshot below shows all of the controls available on the top bar. Some of the controls are only available to users with certain privileges.

| Search | Help | Explore | My Snippets | Admin Area | New Project | Profile Settings | Logout |

Headers

To create headers put a hash symbol # before the text.

Emphasis

You can find out more about how GitLab renders Markdown here: https://github.com/gitlabhq/gitlabhq/blob/master/doc/markdown/markdown.md, or you can look at the source code for this project to see how it is done.

After you log in you will see the Dashboard. The dashboard can be navigated by using the bar on the left, these will show information about all projects and groups that you are members of.

While in the Activity tab you can see the activity of each of the projects and groups that you are a member of. This can be filtered by using the selectors at the top of the page:

Once you click on a project you will be navigated to a page which is similar to the main Dashboard, you can see the activity of the project or view the readme. At the side of the screen is a similar menu used to navigate the project. Below is a basic explanation of what most of them do.

When in the files view you can change the branch using the drop down menu at the top of the page. The text to the right of the drop down menu is a breadcrumb trail, which allows you to navigate through different levels in the repository. Beside the breadcrumb trail is a + which allows you to add a new file to the repository in the current branch.

Allows you to see the latest additions to the repository for each branch. Also allows you to compare the differences between commits or branches.

Allows users to submit bugs or enhancements. This is where to do lists are stored, as GitLab markdown in project files does not support checkboxes.

Allows a user to submit a request to merge two branches together if they do not have permission to merge them. Users can comment and suggest changes, and if they have the permission they can also complete the merge.

If enabled on the project it allows users to paste some code that they need to save.

GitLab

Work in branches

Работа в функциональных ветках

Этот документ объясняет механизм ветвления и то, каким образом публиковать свои изменения в GitLab.

Терминология

master: главная ветвь проекта. Обычно ветки создаются от master. Вы не должны делать свою работу напрямую в master и должны создавать новые ветки для каждой задачи над которой вы работаете самостоятельно или сообща. Когда работа закончена выполняется слияние вашей ветки обратно в master. Ветвление и слияние в Git должно стать частью вашего ежедневного рабочего процесса.

origin: основной удалённый репозиторий в котором вы публикуете свои изменения и из которого получаете изменения других разработчиков.

Ветки

Две основные долгоживущие ветки:

Настройка GitLab аккаунта

GitLab должен знать что вам разрешено делать, а что нет. Для этого вам нужно настроить доступ по SSH-ключам. Это описано здесь

Цикл разработки

Мы используем подход, основанный на мерж-реквестах. Багфиксы и доработки должны быть опубликованы в собственной ветке разработчика, которая создаётся специально под задачу.
Затем создаётся запрос на слияние новой ветки с веткой master в основном репозитории. Следует избегать публикации непосредственно в ветку master.

Правила именования коммитов

Комментарии к правкам следует писать по-русски в кодировке UTF-8.
Многострочный комментарий состоит из однострочного заголовка отделённого от тела пустой строкой.
Длина строки заголовка и тела не должна превышать 80 символов.
Тело комментария должно содержать информацию о том что сделано и зачем это было сделано.
Многострочный комментарий используется при необходимости детализировать назначение набора изменений.
Если правка относится к задаче в трекере, в заголовке указывается номер задачи Jira.

IS-1276. Экспорт РПП в формат CSV. Выгрузка НДС в назначении платежа.

Правила именования веток

Имена функциональных веток должны кратко, в 1-2-3-4 слова (слова разделяются дефисом), характеризовать назначение ветки.
Нет необходимости включать в наименование ничего не значащие или понятные только вам аббревиатуры, постфиксы, указания на нежелаемое поведение.

Хороший пример: fix-service-control

Создание merge request

Идём на GitLab, находим модуль, в котором мы опубликовали свою ветку, далее на закладке Merge requests и нажимаем кнопку Create merge request.

Вводим Title. Заголовок обязательно должен включать номер задачи в Jira и тему, характеризующую изменения.
В Description можем указывать какие именно изменения были сделаны, почему предпочтение отдано именно такому подходу.
Дополнительно здесь можно указать информацию, которая может быть полезна ревьюверу чтобы сориенироваться в предлагаемых правках.
А также упомянуть тех, кому эти изменения могут быть интересны (чьё мнение вам важно). Для этого введите /cc @
Здесь работает markdown-синтаксис.
Проверяем что в список Changes попали только коммиты с вашей ветки.
Выбираем того, кому предстоит принимать ваш запрос из выпадающего списка Assignee.
Ставим галку Remove source branch when merge request is accepted.
Жмём Submit merge request. Мерж-реквест создан. О дальнейшей его судьбе вы будете узнавать из уведомлений, которые начнут приходить на электронную почту.

Больше мерж-реквестов

Для набора изменений, затронувшего несколько модулей, если изменения в этом модуле не совсем тривиальны и нуждаются в ревью (см. ниже раздел «Когда направлять мерж-реквест, а когда нет»), создаётся по одному мерж-реквесту на каждый модуль.
Имена веток во всех модулях должны совпадать. Для навигации между ними в описании добавляются перекрёстные ссылки.

Кто принимает мерж-реквест

Мерж-реквест должен быть одобрен хотя бы одним разработчиком, который не принимал непосредственного участия в написании кода этого изменения

Ревьюверу следует обращать внимание на:

Комментарии и замечания должны находиться непосредственно в данном мерж-реквесте.

Исправления замечаний делаются в той же ветке и видны в мерж-реквесте.