Как установить gitlab на windows

Обновлено: 06.07.2024

Прежде чем использовать Git, вы должны установить его на своём компьютере. Даже если он уже установлен, наверное, это хороший повод, чтобы обновиться до последней версии. Вы можете установить Git из собранного пакета или другого установщика, либо скачать исходный код и скомпилировать его самостоятельно.

В этой книге используется Git версии 2.8.0. Хотя большинство используемых нами команд должны работать даже в старых версиях Git, некоторые из них могут не работать или действовать немного иначе, если вы используете старую версию. Поскольку Git отлично справляется с сохранением обратной совместимости, любая версия после 2.8 должна работать нормально.

Установка в Linux

Если вы хотите установить Git под Linux как бинарный пакет, это можно сделать, используя обычный менеджер пакетов вашего дистрибутива. Если у вас Fedora (или другой похожий дистрибутив, такой как RHEL или CentOS), можно воспользоваться dnf :

Если же у вас дистрибутив, основанный на Debian, например, Ubuntu, попробуйте apt :

Установка на Mac

Существует несколько способов установки Git на Mac. Самый простой — установить Xcode Command Line Tools. В версии Mavericks (10.9) и выше вы можете добиться этого просто первый раз выполнив 'git' в терминале.

Если Git не установлен, вам будет предложено его установить.

Установка в Windows

Для автоматической установки вы можете использовать пакет Git Chocolatey. Обратите внимание, что пакет Chocolatey поддерживается сообществом.

Установка из исходников

Многие предпочитают устанавливать Git из исходников, поскольку такой способ позволяет получить самую свежую версию. Обновление бинарных инсталляторов, как правило, немного отстаёт, хотя в последнее время разница не столь существенна.

Если вы действительно хотите установить Git из исходников, у вас должны быть установлены следующие библиотеки, от которых он зависит: autotools, curl, zlib, openssl, expat, and libiconv. Например, если в вашей системе используется dnf (Fedora) или apt-get (системы на базе Debian), вы можете использовать одну из следующих команд для установки всех зависимостей, используемых для сборки и установки бинарных файлов Git:

Для того, чтобы собрать документацию в различных форматах (doc, html, info), понадобится установить дополнительные зависимости:

Пользователи RHEL и производных от неё (таких как CentOS или Scientific Linux) должны подключить репозиторий EPEL для корректной установки пакета docbook2X

Если вы используете систему на базе Debian (Debian/Ubuntu/Ubuntu-производные), вам так же понадобится установить пакет install-info :

Если вы используете систему на базе RPM (Fedora/RHEL/RHEL-производные), вам так же понадобится установить пакет getopt , который уже установлен в системах на базе Debian:

К тому же из-за различий имён бинарных файлов вам понадобится сделать следующее:

Вы можете установить GitLab Runner в разных операционных системах, установив систему контроля версий Git и создав учетную запись пользователя на сайте GitLab.

Обработка исходного кода истории проектов
Отслеживание изменений, внесенных в файлы
Быстрая и эффективная работа с небольшими и большими проектами.
Сотрудничать с другими разработчиками в разных проектах

GitLab поддерживает различные типы операционных систем, таких как Windows, Ubuntu, Debian, CentOS, open SUSE и Raspberry Pi 2. В этой главе мы обсудим, как установить GitLab в операционных системах Windows и Ubuntu.

Установка GitLab на Windows:

Нажмите на опцию CI / CD на вкладке Настройки и разверните опцию Настройки бегунов .

Please enter the gitlab-ci tags for this runner (comma separated): tag1, tag2

Вы можете изменить эти теги в пользовательском интерфейсе GitLab позже.

Мы использовали селектор как «докер», который создает среду сборки и легко управляет зависимостями для разработки проекта.

Установка GitLab на Ubuntu

GitLab может быть установлен в системе Ubuntu с помощью пакета Omnibus , который предоставляет различные сервисы для запуска GitLab. Пакет Omnibus предоставляет необходимые компоненты GitLab, устанавливает конфигурации и метаданные проекта, которые можно использовать в системе пользователя.

Если вы хотите установить GitLab из исходного кода, установите некоторые зависимости на сервере и вам необходимо настроить базу данных с помощью PostgreSQL. Это описано в главе Настройка среды . Вы можете установить координатор для создания веб-интерфейса и управления экземплярами сборки. Для получения дополнительной информации вы можете проверить главу Установка координатора .

Git — распределённая система контроля версий, которая даёт возможность разработчикам отслеживать изменения в файлах и работать совместно с другими разработчиками. Git выполняет все операции локально, что увеличивает его скорость. Кроме того, он локально сохраняет весь репозиторий в небольшой файл без потери качества данных.

GitLab — веб-приложение и система управления репозиториями программного кода для Git. Обычно GitLab используется вместе с Git и даёт разработчикам возможность сохранять их код онлайн, а затем взаимодействовать с другими разработчиками в разных проектах.

Перед началом работы с GitLab установите себе на устройство приложение Git по ссылке.

Найти подробную инструкцию по установке Git можно здесь.

Затем выберите в верхней панели раздел "Groups". Щелкните на "Your Groups". На этой странице должна находиться группа с номером и названием вашего проекта. Нажмите на нее, чтобы открыть.

Если после авторизации вы не видите группу своего проекта, то обратитесь в Техподдержку.

¶ Установка пароля

После авторизации нужно установить пароль для вашего аккаунта в GitLab.

Нажмите на вашу иконку в правом верхнем углу и перейдите в раздел "Настройки" (settings).

Затем перейдите во вкладку "Пароль" (password).

¶ Что такое репозиторий?

Репозиторий (хранилище) — место, где хранятся и поддерживаются данные. Чаще всего данные в репозитории хранятся в виде файлов.

В GitLab используются проекты — структура, включающая в себя репозиторий Git, настройки, обсуждения и другие сопутствующие инструменты.

Узнать более подробную информацию можно перейдя по ссылке: что такое репозиторий?

¶ Как создавать репозиторий?

Шаг 1. Зайдите в свой аккаунт на GitLab и нажмите на иконку "Groups" в верхней панели.

Шаг 2. Затем перейдите во вкладку "Your group".

Шаг 3. Выберите команду с названием вашего учебного проекта.

Если вы не видите в разделе "Your group" команду вашего проекта, то обратитесь в Техподдержку.

Шаг 4. Вы перешли на страницу своей команды. Теперь нужно создать репозиторий. Для этого нажмите на кнопку "New project".

Если у вас уже есть нужный вам репозиторий, то перейдите к шагу 6.

Шаг 5. Напишите название вашего репозитория и добавьте нужные данные. Готово!

Рекомендуем установить галочку напротив "Инициализировать репозиторий файлом README" - в репозитории появится документ "README. md", в котором можно описывать файлы, содержащиеся в этом репозитории.
Если вы хотите залить сюда файлы из уже существующего репозитория, то можеть не создавать новый "README. md".

Шаг 6.

Для этого зайдите на страницу нужного вам проекта. Далее перейдите в настройки.

Опуститесь до раздела "Advanced" и разверните его с помощью кнопки "Expand".

Найдите внутри блок "Transfer project" и с помощью селектора выберите новое расположение.

Переместить проект может человек только с ролью "Maintainer"(подробнее в разделе участники и роли)

Перенос существующего репозитория с другой платформы

Если проект был создан на другой платформе (Github, Bitbucket и т.д.), то при создании нового репозитория откройте вверху вкладку "Import project" вместо "Blank project", а затем выберите " Repo by URL".

Нужно обязательно выбрать "Repo by URL", в остальных случаях импорт не всегда проходит успешно

При этом вся информация по коммитам будет перенесена. Однако, чтобы она корректно отображалась и учитывалась в статистике, необходимо, чтобы коммиты были сделаны с почты @miem.hse.ru. Если коммиты были сделаны с другой почты, то необходимо добавить ее адрес в личном кабинете в Git.miem.hse.ru (подробнее в блоке "Коммит")

Откройте нужный репозиторий и нажмите на кнопку "Clone". Скопируйте ссылку.

¶ Переход в консоль

Далее вам нужно перейти в консоль.

Как это сделать?

Нажмите на значок поиска на Панели задач или кнопку Пуск.
Далее нажимите "Выполнить".

Не на всех видах Windows консоль открывается так, как указано выше. НО на всех можно нажать Win+R и ввести cmd .

В строке поиска Spotlight введите слово "Терминал" и нажмите Enter .
В результате вы увидите окно терминала.

Linux
Для открытия консоли (терминала) нажмите сочитание следующих клавиш: Alt+Ctrl+F1 .

¶ Клонирование репозитория

Для получения копии существующего Git-репозитория необходимо ввести в терминале команду git clone .

То есть мы просим Git создать копию репозитория, который находится по ссылке (<ссылка на репозиторий>), и можем указать путь к директории, в которую Git скопирует репозиторий (<директория>). Если его не указать, директория создастся в каталоге, где вы находитесь, когда выполняете команду и будет называться так же, как и сам репозиторий.

Клонирование репозитория осуществляется командой:
git clone <ссылка на репозиторий> <путь к директории>

После вы должны ввести имя пользователя и пароль от своей учетной записи в GitLab.

Обратите внимание, что имя пользователя - это имя вашей корпоративной почты до символа "@", а пароль - это пароль, который мы ранее установили в GitLab.
Если у вас возникают ошибки авторизации, обязательно проверьте, какой у вас логин: нажмите на крайнюю кнопку справа сверху на главной странице GitLab и посмотрите, что указано под вашей фамилией.

Вы можете в любой момент перейти к папке с вашим репозиторием с помощью команды:
cd путь/к/директории

Следующая команда показывает, что файл "README.md" скачался и лежит в нашей папке:
dir (ls в Unix)

клонирование репозитория прошло успешно

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

Если вы хотите проверить используемую конфигурацию, можете использовать команду git config --list , чтобы показать все настройки, которые Git найдёт:

Одной из важнейших команд является git status . Система отслеживает изменения, и с помощью этой команды мы узнаем о состоянии системы. Если выполнить эту команду сразу после клонирования, то можно увидить что-то вроде этого:

Это означает, что у вас чистый рабочий каталог. Другими словами, в нем нет отслеживаемых измененных файлов. Git также не обнаружил неотслеживаемых файлов, в противном случае они бы были перечислены здесь.

Если у вас уже есть некоторые файлы, которые нужно перенести в репозиторий, вы можете скопировать их в рабочий каталог.

¶ Встроенный редактор GitLab

GitLab предоставляет простой способ внести небольшие изменения в файлы проекта. Это среда разработки, встроенная в сайт GitLab. Чтобы её запустить, найдите файл, который нужно отредактировать и щелкните по его названию. На открывшейся странице вы увидите содержимое файла и две кнопки: Edit и Web IDE . Первая кнопка откроет файл для простого редактирования, вторая запустит встроенную среду разработки.

Также на сайте предусмотрена возможность создавать новые файлы. Для этого на странице репозитория нажмите на кнопку "+" и выберите "New file" . В открывшемся редакторе введите имя файла и нужное содержимое. Не забудьте нажать на кнопку Commit changes по завершении редактирования.

Кроме того, для частых типов файлов предусмотрены отдельные кнопки. Вы найдёте их над списком файлов на странице репозитория. Так вы, например, сможете быстро добавить файл README.md в ваш проект. Просто нажмите на кнопку Add README .

¶ Изменения в существующем файле

Чтобы внести изменения в файл, который скопировался вместе с репозиторием, просто перейдите в папку с копией репозитория на компьютере и откройте этот файл. В нашем случае, это файл "README.md". Он должен содержать описание репозитория, отображаемое на его странице на сайте. Добавьте в него новую строку и сохраните:

Если вы выполните команду git status , то увидите свои неотслеживаемые изменения в файле:

Мы видим, что у нас есть недобавленные изменения.

Для добавления изменений используется команда git add <название файла> . Команда git add . добавляет все изменения в рабочей директории в индекс для последующего коммита.

¶ Что такое коммит?

Коммит - это сохранение, фиксация (в архиве, репозитарии и т.д.) изменений в программном коде.

Команда git commit берёт все данные, добавленные в индекс с помощью git add , и сохраняет их слепок во внутренней базе данных, а затем сдвигает указатель текущей ветки на этот слепок.

При коммите данных их необходимо комментировать, чтобы в дальнейшем каждое изменение в проекте было с описанием действий. Для этого используется команда
git commit -m "комментарий"

Теперь все нужные изменения добавлены в наш локальный репозиторий.

¶ Добавление нового файла в удаленный репозиторий

Рассмотрим пример:
Создадим новый файл "text.txt" в папке "main" и выполним следующие действия:

Шаг 1. Добавим файл в нашу папку main;

Шаг 2. Зафиксируем изменения и узнаем текущее состояние файла;

Шаг 3. Отправим изменения в локальное хранилище (то есть выполним коммит).

С помощью команды git push отправим данные локального репозитория на удаленный репозиторий (Origin - это наш репозиторий).

Заходим в GitLab и видим, что отправка данных прошла успешно.

¶ Отмена действий

Если вы добавили файлы в состояние ожидания, но передумали и не хотите добавлять некоторые из них, то нужно использовать команду:
git rm --cached "название файла"

Укажите, какой файл необходимо удалить из ожидания на коммит.

Если вы ввели неправильно пароль (на Windows), а во второй раз ваши данные не запрашиваются, то вам нужно сделать следующие действия:
панель управления -> учетные записи -> диспетчер учетных данных -> удалить данные GitLab
После чего заново повторить первые шаги с вводом ваших данных.

По натуре своей многие разработчики слишком ленивые не любят делать одно и то же действие много раз. Нам проще научить компьютер, чтобы он делал монотонные действия за нас.

Как только кто-либо из нашей команды вносит изменения в код (читай «мерджит feature-ветку в develop»), наш билд-сервер:

Собирает исходный код и установщик приложения
- проставляет номер сборки, каждый раз увеличивая последнюю цифру. Например, текущая версия нашего ПО 3.3.0.202 – часть 3.3.0 когда-то ввёл разработчик (привет, SemVer), а «202» проставляется в процессе сборки.
- В процессе анализирует качество кода (с использованием SonarQube) – и отправляет отчёт во внутренний SonarQube,
Также, в зависимости от ветки, в которую были внесены изменения, могут быть выполнены:
- отправка сборки (вместе с changelog-ом) в один или несколько телеграм-каналов (иногда удобнее брать сборки оттуда).
- публикация файлов в систему автообновления ПО.
Под катом о том, как мы научили Gitlab CI делать за нас бОльшую часть этой муторной работы.

Чтобы настроить Gitlab Runner, выполните следующие шаги:

Далее надо ввести ответы на вопросы мастера регистрации Runner-а:

В процессе своей работы Gitlab CI берёт инструкции о том, что делать в процессе сборки того или иного репозитория из файла .gitlab-ci.yml , который следует создать в корне репозитория.

И последнее: если нам требуется передавать в скрипт значение параметра, который мы не хотим хранить в самом скрипте (например, пароль для подключения куда-либо), мы можем использовать для этого объявление параметров в gitlab. Для этого зайдите в проекте (или в группе проекта) в Settings > CI/CD и найдите раздел Variables. Прописав в нём параметр с именем (key) SAMPLE_PARAMETER, вы сможете получить его значение в в скрипте .gitlab-ci.yml через обращение $env:SAMPLE_PARAMETER.

Также в этом разделе можно настроить передачу введенных параметров только при сборке защищённых веток (галочка Protected) и/или скрытие значения параметра из логов (галочка Masked).

Подробнее о параметрах окружения сборки смотрите в документации к Gitlab CI.

Скрипт, приведённый выше, уже можно использовать для сборки и вызова тестов. Правда, присутствует НО: крайне неудобно прописывать абсолютные пути к разным установкам Visual Studio. К примеру, если на одной билд-машине стоит Visual Studio 2017 BuildTools, а на другой Visual Studio Professional 2019, то такой скрипт будет работать только для одной из двух машин.

К счастью, с версии Visual Studio 2017 появился способ поиска всех инсталляций Visual Studio на компьютере. Для этого существует утилита vswhere, путь к которой не привязан ни к версии Visual Studio, ни к её редакции. А в Visual Studio 2019 (в версии 16.1 или более новой) есть библиотека, которая умеет «трансформировать» консоль Powershell в режим Developer Powershell, в котором уже прописаны пути к утилитам из поставки VS.

Дописываем переменную к секции Variables:

Затем создаём новую секцию before_msbuild якорем enter_vsdevshell и следующим текстом:

И всюду, где нам надо использовать утилиты Visual Studio, добавляем этот якорь. После этого задача сборки начинает выглядеть намного более опрятно:

Результат: мы имеем путь к vswhere.

Результат: в переменную $visualStudioPath записан путь к Visual Studio или пустая строка, если инсталляций Visual Studio не найдено (обработку этой ситуации мы ещё не добавили).
1. Команда Import-Module загружает библиотеку Microsoft.VisualStudio.DevShell.dll, в которой прописаны командлеты трансформации консоли Powershell в Developer-консоль. А командлет Join-Path формирует путь к этой библиотеке относительно пути установки Visual Studio.
  На этом шаге нам прилетит ошибка, если библиотека Microsoft.VisualStudio.DevShell.dll отсутствует или путь к установке Visual Studio нужной редакции не был найден — Import-Module сообщит, что не может загрузить библиотеку.
Результат: загружен модуль Powershell с командлетом трансформации.
1. Запускаем «переделку» консоли в Developer Powershell. Чтобы корректно прописать пути к утилитам, командлету требуется путь к установленной Visual Studio (параметр -VsInstallPath ). А указание SkipAutomaticLocation требует от командлета не менять текущее расположение (без этого параметра путь меняется на <домашнаяя папка пользователя>\source\repos ).
Результат: мы получили полноценную консоль Developer Powershell с прописанными путями к msbuild и многим другим утилитам, которые можно использовать при сборке.

Раньше мы использовали t4 шаблоны для проставления версий: номер версии собиралась из содержимого файла в формате <major>.<minor>.<revision> , далее к ней добавлялся номер сборки из Gitlab CI и он передавался в tt-шаблон, добавляющий в решение везде, где требуется, номер версии. Однако некоторое время назад был найден более оптимальный способ — использование команд git tag и git describe .

Команда git tag устанавливает коммиту метку (тэг). Отметить таким образом можно любой коммит в любой момент времени. В отличие от веток, метка не меняется. То есть если после помеченного коммита вы добавите ещё один, метка останется на помеченном коммите. Если попробуете переписать отмеченный коммит командами git rebase или git commit --amend, метка также продолжит указывать на исходный коммит, а не на изменённый. Подробнее о метках смотрите в git book.

Команда git describe , к сожалению, в русскоязычном gitbook не описана. Но работает она примерно так: ищет ближайшего помеченного родителя текущего коммита. Если такого коммита нет — команда возвращает ошибку fatal: No tags can describe '<тут хэш коммита>' . А вот если помеченный коммит нашёлся — тогда команда возвращает строку, в которой участвует найденная метка, а также количество коммитов между помеченным и текущим.

Кстати, по этой же причине если вы используете gitflow, после вливания feature-ветки в develop требуется удалить влитую локальную ветку, после чего пересоздать её от свежего develop:

(обратите внимание на историю git в левой части картинки: из-за отсутствия пути из текущего коммита до коммита с меткой 1.0.5, команда git describe выдаст неверный ответ)

Но вернёмся к автопроставлению версии. В нашем репозитории царит gitflow (точнее его rebase-версия), метки расставляются в ветке master и мы не забываем пересоздавать feature-ветки от develop, а также merge-ить master в develop после каждого релиза или хотфикса.

Тогда получить версию для любого коммита и сразу передать её в msbuild можно добавив всего пару строк к задаче сборки:

Как это работает:
1. Мы проставляем метки в формате <major>.<minor>.<revision> .
2. Тогда git describe --long возвращает нам строку, описывающую версию в формате <major>.<minor>.<revision>-<количество новых коммитов>-g<хэш текущего коммита> .
3. Парсим полученную строку через регулярные выражения, выделяя нужные нам части — и записывем части в $versionGroup .
4. Преобразовываем четыре найденные подстроки в 4 числа и пишем их в переменные $major , $minor , $patch , $commit , после чего собираем из них строку уже в нужном нам формате.
5. Передаём указанную строку в msbuild чтобы он сам проставил версию файлов при сборке.
Обратите внимание: если вы, согласно gitflow, будете отмечать (тэгировать) ветку master после вливания в неё release или hofix, будьте внимательны: до простановки метки автосборка будет вестись относительно последней существующей ветки. Например, сейчас опубликована версия 3.4, а вы создаёте release-ветку для выпуска версии 3.5. Так вот: всё время существования этой ветки, а также после её вливания в master, но до простановки тэга, автосборка будет проставлять версию 3.4.

SonarQube — это мощный инструмент контроля качества кода.

SonarQube имеет бесплатную Community-версию, которая способна проводить полный анализ. Правда, только одной ветки. Чтобы настроить её на контроль качества ветки разработки (develop), требуется выполнить следующие шаги (разумеется, помимо установки и развёртывания сервера SonarQube):

Теперь при каждой сборке ветки develop в SonarQube будет отправляться подробный анализ нашего кода.

На заметку: вообще команда msbuild /t:rebuild полностью пересобирает решение. Вероятно, в большинстве проектов анализ можно было бы встроить прямо в стадию сборки. Но сейчас у нас анализ в отдельной задаче.

Пара слов об использованных параметрах:

Со сборкой более-менее разобрались — теперь приступаем к тестам. Доработаем код прогона тестов, чтобы он:
- сам находил библиотеки с тестами,
- прогонял их пачкой через xUnit,
- вычислял тестовое покрытие через OpenConver,
- отправлял результаты покрытия тестами в SonarQube.
На заметку: обычно в паре с OpenCover используют ReportGenerator, но при наличии SonarQube мы с тем же успехом можем смотреть результаты через его интерфейс.

Для настройки выполним следующие шаги:
1. Скачайте OpenCover в виде zip-файла с сайта github.
2. Распакуйте содержимое архива в папку. Например, в C:\Tools\OpenCover .
  На заметку: эту утилиту также можно скачать на сборочную машину через NuGet, но тогда надо будет чуть по-иному указывать её путь.
3. Допишите переменные к секции Variables:
4. Модифицируйте задачу тестирования ветки разработки (test_job), чтобы она включала и команды вызова OpenCover:
Для того, чтобы начать работать с системой контроля версий Git ее необходимо предварительно установить. Рассмотрим варианты установки этой VCS под MS Windows и Linux.

Установка Git под Windows

Если вы зашли из под операционной системы (ОС) Windows, главная страница сайта будет выглядеть примерно так, как показано на рисунке ниже. Для других ОС отличие будет заключаться в том, что изменится область для скачивания дистрибутива (см. правый нижний угол).

Для того чтобы скачать Git нужно нажать на кнопку Downloads for Windows, расположенную в правой части окна.

Процесс дальнейшей установки Git выглядит так.

1. Запустить установочный файл

2. Ознакомиться, если есть желание, с лицензионным соглашением и нажать на кнопку Next

3. Выбрать компоненты, которые следует установить

4. Указать способ использования Git

В этом окне доступны три возможных варианта:

Переменная PATH не модифицируется и работа с Git возможна только через специализированную оболочку, которая называется Git Bash.

В этом случае происходит минимальная модификация переменной окружения PATH, которая позволит работать с Git через командную стоку Windows. Работа через Git Bash также возможна.
- Use Git and optional Unix tools from the Windows Command Prompt
В переменную PATH вносится значительное количество модификаций, которые позволят, в рамках командной строки Windows, использовать как Git так и утилиты Unix, которые поставляются вместе с дистрибутивом Git.

Наша рекомендация: опция Use Git from the Windows Command Prompt.

5. Настройка правил окончания строки
- Checkout Windows-style, commit Unix-style line endings
Checkout (операция извлечения документа из хранилища и создания рабочей копии) производится в Windows стиле, а commit (операция отправки изменений в репозиторий) в Unix стиле.
- Checkout as-is, commit Unix-style line endigns
Checkout производится в том формате, в котором данные хранятся в репозитории, а commit осуществляется в Unix стиле.

Checkout и commit производятся без дополительных преобразований.

Наша рекомендация: опция Checkout Windows-style, commit Unix-style line endings.

6. Выбор эмулятора терминала, который будет использован с Git Bash

Возможен выбор из двух вариантов:

Git Bash будет использовать в качестве эмулятора терминала MinTTY.

Git будет использовать Windows консоль (“cmd.exe”).

Наша рекомендация: опция Use MinTTY (the defaul terminal of MSYS2).

7. Настройка дополнительных параметров

Доступны следующие параметры:

Включение операции кэширования при работе с файлами. Эта опция позволит значительно повысить производительность.

Предоставляет возможность работы с защищенным хранилищем.

Активирует работу с символьными ссылками.

Наша рекомендация: опции Enable file system caching и Enable Git Credential Manager.

8. Завершение установки

Установка Git под Linux

Solaris 11 Express

Читайте также: