Время на прочтение6 мин
Количество просмотров179K
Предисловие или от куда взялась «бредовая» идея ставить Git на Windows
Я работаю в одной не очень большой IT-компании, которая продает свои и чужие программные решения, занимается проектами внедрения, оказывает клиентскую поддержку, проводит обучение и далее все такое в том же духе. До недавнего времени в моей маленькой команде разработки все было неплохо организовано и у нас даже был свой собственный достаточно мощный сервер. Но случилось непредвиденное и по воле злого рока один из серверов фирмы полетел, а руководство решило вместо него в стойку поставить наш сервер отдела разработки. Нам предложили «временно» переехать на любой из серверов общего назначения.
А теперь внимание! Только мы одни во всей фирме работаем на Линуксе, а все остальные сидят исключительно на Windows и сервера у нас тоже под управлением серверных редакций ОС от Билла Гейтса. И если перенос базы Redmine не вызывает особых вопросов, то задача поднять на сервере Windows сервер для Git меня сразу поставила в тупик. Но несколько часов потраченных на поиски дали мне простое работающее решение.
Изучение матчасти
Первым делом я обратился к документации по Git’у, где вычитал следующее:
Git умеет работать с четырьмя сетевыми протоколами для передачи данных: локальный, Secure Shell (SSH), Git и HTTP.
Первый вариант я не стал рассматривать, так как он подразумевает наличие сетевой шары открытой для общего доступа. Допустим, что с помощью групповых политик домена можно обезопасить данные от случайного удаления продавцем-стажером. Но как работать из дому? Ради нескольких «коммитов выходного дня» поднимать VPN?
Читаем далее и видим:
SSH — единственный из сетевых протоколов, предоставляющий доступ и на чтение, и на запись. Два других сетевых протокола (HTTP и Git) в большинстве случаев дают доступ только на чтение, поэтому даже если они вам доступны, вам всё равно понадобится SSH для записи.
Путь к конечной цели уже стал менее туманным: сначала требуется поставить сервер SSH, а далее установить одну из многочисленных сборок Git для Windows (официальную msysgit, Git Extensions, TortoiseGit, QGit и т.д.)
Выбор сервера SSH для Windows
Воспользовавшись поисковиком по сети Internet, я сделал небольшую подборку текущих реализаций SSH под Windows. Не претендую на то, что смог найти все решения в этой области, но самые популярные точно не пропустил. Итак:
Cygwin. В рамках проекта переноса функциональности Linux на Windows был портирован в том числе и OpenSSH. Библиотека проекта cygwin1.dll с реализацией SSH так же используются в большинстве других решений. Простую инструкцию с картинками по установке и настройке можно посмотреть тут. А так же рекомендую к прочтению статью из журнала «Windows IT Pro» № 7 за 2001 год — SSH в Windows.
freeSSHd. Лидер среди упоминается на форумах. Характеризуется как легкий в использовании. Лицензия позволяет бесплатно использовать в коммерческих целях. Нашел инструкцию по установке и настройке на Win2008.
WInSSHD. Самое богатое по функциональности из увиденных мною реализаций. Это хорошее профессиональное решение для обеспечения безопасности. Но для моего гвоздя — это микроскоп. Если кого-то продукт заинтересовал, то у них есть 30-дневная ознакомительная полная версия и возможность бесплатного частного использования.
KpyM Telnet/SSH Server. Плохих отзывов не заметил. Но меня смущает, что их сайт не обновляется с 2009 года, а так же на официальном форуме как-то безжизненно. С другой стороны, если продукт бесплатный и выполняет свою работу, то нет смысла заниматься развитием. Понравилось наличие в их FAQ списка других решений для SSH под Windows. Рекомендую заглянуть.
Copssh. Продукт от норвежской компании ITeF!X, в котором они к windows-реализации OpenSSH добавили красивый GUI-интерфейс администратора и некие «best practices». Именно это решение, более всего рекомендуется в обсуждении поднятия сервера Git под Windows на StackOverflow.
Случайная находка
Собственно под впечатлением ответов на StackOverflow я уже расслабился и решил было пойти проторенной моими предшественниками дорожкой. Но при изучении сайта компании ITeF!X я обнаружил, что у них есть и более подходящий для моих целей продукт — gitwin. Это оказался тот самый требуемый мне сервер Git под Windows.
Я вначале не поверил глазам — если такой чудо продукт существует, то почему о нем до сих пор не трубят на каждом шагу. Ответ нашелся в новостях компании — как оказалось программный продукт только полмесяца назад (11 октября 2013 года) выложили в общий доступ. Точнее на днях выложили бесплатную для использования версию. Платная существовала и раньше, но видимо не пользовалась особым спросом (с января 2012 года на официальном форуме компании всего две созданные темы в разделе gitwin).
Итак, что же собой представляет этот gitwin? В состав свободной версии входят:
- Cygwin версии 1.7.25
- OpenSSH версии 6.3
- Git версии 1.8.4
- Инсталятор от Itefix
На сайте целый раздел посвящен установке пакета. Кроме описания словами процесса «запуск инсталятора» -> «далее» -> «далее» -> «готово», представители компании не поленились записать все это еще на видео и выложили на YouTube. Не совсем понятно зачем это сделано и самое главное не понятно для кого?
Еще один раздел выделили для описания использования. Тут описали активацию нового пользователя для доступа по SSH, создание пары ключей и пустого репозитория. И так же кроме описания текстом дают записанный обучающий ролик:
Установка, настройка и тестирование сервера Git
Я установил на наш сервер gitwin редакции «free edition» и могу поделится только этим опытом.
1. Начинаем со скачивания инсталятора со странички продукта.
2. Запускаем инсталятор и нас спрашивают куда устанавливать продукт. Я оставил по-умолчанию в «C:\Program Files (x86)\ICW». Зачем может понадобится менять путь? Дело в том, что этот каталог станет корнем для линуксовых утилит и домашний каталог пользователя git тоже будет создан тут же «C:\Program Files (x86)\ICW\home\git\». Если есть предчувствие проблем с правами доступа, то можете поменять на менее проблемный для вас каталог.
3. В процессе установки выводятся сообщения о создании двух пользователе «SvcCOPSSH» и «git». Под первым пользователем будет работать служба «OpenSSHServer», а второй нужен собственно для обслуживания репозиториев. Пароли к этим пользователям можно узнать в конце процесса установки, если нажать на «Show details». Советую по правому щелчку скопировать вывод в буфер и сохранить на всякий случай.
3.1. Перепроверка состава пользователей показала, что инсталятор втихую создал еще одного пользователя — «sshd» с описанием «copSSH privilege separation user» и сам же отключил его. Не понятно и подозрительно…
4. Скорее всего из-за редакции «free edition» дальнейшие шаги отличались от описанных на сайте. Вместо консоли администрирования в меню Пуск/copssh поместили два пункта «01. Activate a user» и «02. Deactivate a user». Но суть процесса от этого не изменилась. Запускаем «01. Activate a user» и указываем пользователя для активации (в моем случае все тот же git), выбираем командную оболочку (выбор из bash, sftponly и false) и ставим опциональные галочки. Тут читаем внимательно:
4.1. Если нам нужна пара ключей, то оставляем включенную по-умолчанию «Create keys for public key authentication». При парольной авторизации можете снять…
4.2. Если у пользователя планируется использование его родного пользовательского каталога из C:\Users\ (или может у кого-то до сих пор C:\Documents and Settings\) тогда оставляем включенные по-умолчанию галочки «remove copssh home directory if it exists» и «Create link to user’s real home directory». Я рискнул их снять и таким образом все репозитории у меня будут запрятаны глубоко в системном каталоге Program Files.
5. После активации пользователя и создания ключей можем протестировать всю систему на работоспособность. Выбираем в меню Пуск/copssh пункт «03. Start a Unix BASH Shell» и создаем пустой репозиторий. Я не стал блистать остроумием и повторил команду с официального сайта:
$ git init —bare /home/git/repo-a
Initialized empty Git repository in /home/git/repo-a/
6. Далее тестирование переехало на мой рабочий ноут. Я успешно склонировал пустой репозиторий, закинул в него несколько файлов и запушил назад. Проблем не возникло. Перешел в другой каталог и снова склонировал репозиторий — на этот раз он был уже не пустой и содержал мой коммит с файликами. Таким образом с моей рабочей станции различия между работой с репозиторием Git на предыдущем сервере Ubuntu и на новом сервере Windows замечено не было!
Заключение
Удачно найденный gitwin оказался именно тем решением, которое я искал — запускается под Windows и создает иллюзию для пользователей, что они работают с полноценным удаленным репозиторием. Глюков пока не заметил. Но если обнаружу, то обязательно дополню данную статью.
Надеюсь, что собранные материалы окажутся кому-нибудь полезными. И хочу пожелать не боятся потратить несколько часов на поиски, если вы не уверены, что в вашей голове наиболее актуальная информация. Ведь если бы я изначально зашел на StackOverflow и выполнил все по детальному пошаговому руководству от Тима Дэвиса, то не узнал бы о существовании более короткого пути, когда вся инфраструктура поднимается и настраивается буквально в десяток кликов мышкой. Успехов!
Послесловие. Истории успехов от хабраюзеров
Я подобно Сократу с каждым новым квантом знаний понимаю как еще много того, чего я все еще не знаю. В комментариях коллеги описывают положительный опыт на заданную мною тему, который грех игнорировать. Итак:
A1lfeG вместе со своей командой далеки от Linux’а, но тем не менее ихняя установка центрального репозитория Git’а была довольно простой. В этом им помог продукт SCM Manager.
dshster делится опытом по успешной установке на сервер исключительно msysgit. Если честно, то я читал это сообщение в Q&A, но это не мой случай. Инструкция больше касается использования Bitbucket и Github. Для общего использования в локальной сети предлагается общая папка, а для просмотра репозитория встроенный веб-сервер. Отмечу, что начиная с релиза 1.8.4 веб-сервер и часть других утилит удалена: «Some commands are not yet supported on Windows and excluded from the installation; namely: git archimport, git cvsexportcommit, git cvsimport, git cvsserver, git instaweb, git shell»
IamKarlson хорошо отзывается о решении Bonobo Git Server, которое используется у него на работе. Как плюс для себя отмечу использование веб-сервера IIS, который у нас уже работает.
You need to download and install:
- Win32_OpenSSH
- Git for Windows, selecting the «Run Git and included Unix tools from the Windows Command Prompt» when prompted. This option will install a bin folder in Program Files\git that will be placed into your path thus taking possibly taking precedence over other tools.
On Server
-
Set system environment variable for sshd to pick up the git commands
$gitPath = Join-Path -Path $env:ProgramFiles -ChildPath "git\mingw64\bin" $machinePath = [Environment]::GetEnvironmentVariable('Path', 'MACHINE') [Environment]::SetEnvironmentVariable('Path', "$gitPath;$machinePath", 'Machine')
-
Restart sshd so the changes to the
Pathenvironment variable can take effect. -
Create Windows users for all Git users.
-
Create a central Git repository. Go to where you want to create a central repo,
git clone --bare <source dir>. A directory with name<source dir>.gitwill be created. In it will be the .git contents of your source dir repo. for example:git clone --bare c:\git\newrepo.git -
If you already have user private and public keys, copy the user public key to
C:\Users\{user}\.ssh\and rename it to authorized_keys
On Client
-
Set environment variable for git to use Win32_OpenSSH
$env:GIT_SSH_COMMAND = '"C:\Program Files\OpenSSH\ssh.exe" -T' -
(Optional) For key based authentication to work, generate user private and public key. The generated public key need to copy to C:\Users{user}.ssh\authorized_keys as indicated in step 5 on Server
ssh-keygen.exe -t ed25519 -f c:\test\myprivatekey -
(Optional) Register the user private key for single sign on
ssh-add.exe c:\test\myprivatekey -
To check out a repository, go to where you want to put your local repo,
**Note that git clone user@domain@servermachine:C:/test/myrepo.git does not work due to known issue. Work around it to set powershell as default Shell in registry.
Or
by following steps when cmd is default shell:
cd c:\mygitrepros
# initialize a local repo folder
git init mylocalrepo
cd mylocalrepo
# add the remote repro
git remote add origin user@domain@servermachine:C:/test/myrepo.git
# work around the known issue by launching powershell to run the git commands
git config --local remote.origin.uploadpack "powershell git-upload-pack"
git config --local remote.origin.receivepack "powershell git-receive-pack"
git fetch origin
A Git server on Windows allows users to host and manage their Git repositories locally, enabling collaborative version control for development projects.
git init --bare C:\path\to\your\git\repository.git
What is a Git Server?
A Git server is a dedicated space that allows developers to host their Git repositories, manage access, and facilitate the collaborative process of software development. Unlike local repositories, which reside on individual machines, a Git server serves as a centralized location for teams to share and collaborate on code.
Benefits of Using a Git Server
Using a Git server brings several advantages:
- Centralized Control: Control over your repositories, ensuring all changes come from a single source.
- Enhanced Collaboration: Multiple team members can work on the same project simultaneously without conflicts.
- Backup and Recovery: Protecting against data loss by serving as a backup for your source code.
Master Git for Windows: Quick Commands Breakdown
Prerequisites
Before you dive into the setup, ensure that you have the following:
- Software Requirements: Download Git for Windows from the official website. If you plan to access your Git server over the web, you may also consider installing a web server like Apache or Nginx.
- System Requirements: You’ll need a Windows machine with adequate resources (CPU, RAM, and storage) to handle your anticipated load.
Step-by-Step Installation Guide
Download and Install Git for Windows
Start by downloading Git for Windows from the official Git SCM site. Follow the installation instructions to set it up on your machine.
Example Command:
winget install --id Git.Git -e --source winget
Configuring a Git Repository
Setting up a bare repository is essential for storing the code without working copies. Here’s how to do it:
-
Create a directory for your Git server:
mkdir my-git-server cd my-git-server -
Initialize a bare Git repository:
git init --bare
This will create a new Git repository without a working directory, making it suitable as a server repository.
Setting Up SSH for Secure Access
Security is paramount when managing a Git server. Using SSH (Secure Shell) ensures that only authorized users can access the repository.
-
Generate SSH keys:
ssh-keygen -t rsa -b 4096 -C "your_email@example.com" -
The command prompts you to set a file location for the key, generally the default is suitable. You can add a passphrase for added security.
-
After generating the SSH key, you need to add the public key to your Git server’s authorized keys:
- Locate your public key in `~/.ssh/id_rsa.pub`.
- Append its content to `~/.ssh/authorized_keys` on the server to allow your user to authenticate without entering a password each time.
Configuring User Access
Properly managing user access is crucial to maintaining the integrity of your repositories. You can create user accounts on your server and assign permissions to allow or restrict access to specific repositories.
Adding Users
To add users, create corresponding accounts on your Windows machine. This can be done through the User Accounts settings in the Control Panel. Once you have your users, you can specify access rights using Git’s permission settings.
Example of Configuring Access Rights
Configure user-specific settings by executing the following command in the repository:
git config --global user.name "Username"
git config --global user.email "user@example.com"
This allows Git to identify who made changes, which is essential for collaboration.
Mastering Git Serverless: A Quick Guide to Efficiency
Managing Repositories
Creating a New Repository
To create a new repository from an existing project, follow these steps:
-
Navigate to your project directory:
cd my-project -
Initialize it as a Git repository and link it to the remote server:
git init git remote add origin ssh://git@yourserver.com:/path/to/my-repo.git
This setup links your local project to the remote repository on your Git server, making it ready for collaboration.
Cloning a Repository
Users can clone the repository by executing the following command:
git clone ssh://git@yourserver.com:/path/to/my-repo.git
This command allows them to create a local copy of the specified repository, enabling them to work on their changes offline before pushing updates back to the server.
Mastering Git Server: A Quick Guide for Beginners
Git Server Maintenance
Regular Backups
It’s crucial to maintain regular backups of your Git server to prevent data loss. Utilize automated scripts to perform nightly backups of your repositories. Consider using the following command:
git clone --mirror /path/to/your/repo /path/to/backup/location
This will create a mirror backup of the repository that captures all branches and tags.
Monitoring Usage
Monitoring server performance and usage is vital for maintaining a responsive and efficient environment. Consider using tools built into Windows or third-party applications that provide insights into server performance and user access.
Updating and Upgrading
To keep your Git installation and server environment updated, regularly check for updates on the official Git website and apply them as necessary. Keeping software up-to-date helps maintain security and stability.
Mastering Git Bash for Windows: Quick Commands Guide
Tools and Alternatives
Git Server Hosting Options
There are several hosted solutions like GitHub, GitLab, and Bitbucket. These platforms offer a wealth of features including issue tracking, CI/CD pipelines, and community integration. They are excellent choices for teams looking to offload server maintenance.
Other Git Server Software for Windows
If you’re considering alternatives that run on Windows, look into self-hosted options like Gitea, GitLab CE, or Bitbucket Server. These solutions can provide additional features that may suit your project’s specific needs.
Git Install Windows: A Quick Guide for New Users
Conclusion
Setting up a Git server on Windows offers a powerful way for teams to collaborate effectively on software development projects. By following the steps outlined in this guide, you can create a manageable and secure environment for version control, ensuring your code is well-organized and accessible.
Mastering Git Windows Console: Quick Command Guide
Additional Resources
For further exploration, refer to the official Git documentation, online communities, or forums where experienced Git users share their best practices and advanced techniques for mastering Git commands.
Установка Git на сервер
Рассмотрим теперь установку сервиса Git с поддержкой этих протоколов на сервер.
|
Примечание |
Здесь мы приводим команды и шаги, необходимые для базовой, упрощённой установки на Linux-сервер, но эти сервисы можно запустить и на MacOS или Windows сервере. |
Для того чтобы приступить к установке любого сервера Git, вы должны экспортировать существующий репозиторий в новый голый репозиторий — репозиторий без рабочего каталога.
Делается это просто.
Чтобы создать новый голый репозиторий — во время клонирования используйте параметр --bare.
По существующему соглашению, каталоги с голыми репозиториями заканчиваются на .git, например:
$ git clone --bare my_project my_project.git
Cloning into bare repository 'my_project.git'...
done.Теперь у вас должна быть копия данных из каталога Git в каталоге my_project.git.
Грубо говоря, это эквивалентно команде:
$ cp -Rf my_project/.git my_project.gitТут есть пара небольших различий в файле конфигурации, но в нашем случае эту разницу можно считать несущественной.
В этом случае берётся репозиторий Git без рабочего каталога и помещается в отдельный каталог.
Размещение голого репозитория на сервере
Теперь, когда у вас есть голая копия вашего репозитория, осталось поместить её на сервер и настроить протоколы.
Предположим, что вы уже настроили сервер git.example.com, имеете к нему доступ по SSH и хотите разместить все ваши репозитории Git в каталоге /srv/git.
Считая, что /srv/git уже есть на сервере, вы можете добавить ваш новый репозиторий копированием голого репозитория:
$ scp -r my_project.git user@git.example.com:/srv/gitТеперь другие пользователи, имеющие доступ к серверу по SSH и права на чтение каталога /srv/git, могут клонировать ваш репозиторий выполнив команду:
$ git clone user@git.example.com:/srv/git/my_project.gitЕсли у пользователя есть права записи в каталог /srv/git/my_project.git, он автоматически получает возможность отправки изменений в репозиторий.
Git автоматически добавит права на запись в репозиторий для группы при запуске команды git init с параметром --shared.
Следует отметить, что при запуске этой команды коммиты, ссылки и прочее удалены не будут.
$ ssh user@git.example.com
$ cd /srv/git/my_project.git
$ git init --bare --sharedВидите, как это просто, взять репозиторий Git, создать голую версию и поместить её на сервер, к которому вы и ваши коллеги имеете доступ по SSH.
Теперь вы готовы работать вместе над одним проектом.
Важно отметить, что это практически всё, что вам нужно сделать, чтобы получить рабочий Git-сервер, к которому имеют доступ несколько человек — просто добавьте учетные записи с возможностью доступа по SSH на сервер и положите голый репозиторий в то место, к которому эти пользователи имеют доступ на чтение и запись.
И всё.
Из нескольких последующих разделов вы узнаете, как получить более сложные конфигурации.
В том числе как не создавать учётные записи для каждого пользователя, как сделать публичный доступ на чтение репозитория, как установить веб-интерфейс и др.
Однако, помните, что для совместной работы пары человек на закрытом проекте, всё что вам нужно ― это SSH-сервер и голый репозиторий.
Малые установки
Если вы небольшая компания или вы только пробуете использовать Git в вашей организации и у вас небольшое число разработчиков, то всё достаточно просто.
Один из наиболее сложных аспектов настройки сервера Git — это управление пользователями.
Если вы хотите, чтобы некоторые репозитории были доступны определённым пользователям только на чтение, а остальным на чтение и запись, то настроить доступ и привилегии будет несколько сложнее.
SSH доступ
Если у вас уже есть сервер, к которому все ваши разработчики имеют доступ по SSH, проще всего разместить ваш первый репозиторий там, поскольку вам не нужно практически ничего делать (как мы уже обсудили в предыдущем разделе).
Если вы хотите более сложного управления правами доступа к вашим репозиториям, вы можете сделать это обычными правами файловой системы, предоставляемыми операционной системой вашего сервера.
Если вы хотите разместить ваши репозитории на сервере, где нет учётных записей для членов команды, которым требуются права на запись, то вы должны настроить доступ по SSH для них.
Будем считать, что если у вас для этого есть сервер, то SSH-сервер на нём уже установлен и через него вы получаете доступ.
Есть несколько способов предоставить доступ всем участникам вашей команды.
Первый — создать учётные записи для каждого, это просто, но может быть весьма обременительно.
Вероятно, вы не захотите для каждого пользователя выполнять adduser (или useradd) и задавать временные пароли.
Второй способ — это создать на сервере пользователя git, попросить всех участников, кому требуется доступ на запись, прислать вам открытый ключ SSH и добавить эти ключи в файл ~/.ssh/authorized_keys в домашнем каталоге пользователя git.
Теперь все будут иметь доступ к этой машине используя пользователя git.
Это никак не повлияет на данные в коммите — пользователь, под которым вы соединяетесь с сервером по SSH, не воздействует на созданные вами коммиты.
Другой способ сделать это — настроить SSH сервер на использование аутентификации через LDAP-сервер или любой другой имеющийся у вас централизованный сервер аутентификации.
Вы можете использовать любой механизм аутентификации на сервере и считать что он будет работать для Git, если пользователь может получить доступ к консоли по SSH.
Git является одной из наиболее распространенных систем контроля версий (Version Control System — VCS), предназначенных для хранения и управления исходным кодом приложений, настроек системы и других текстовых файлов. В основном Git применяется в сфере информационных технологий, хотя его использование не ограничено только этой областью.
В Git каждое состояние файлов может быть зафиксировано (сделано коммитом), сохраняя его навсегда в истории репозитория. Это позволяет в любой момент просматривать историю изменений файлов, сравнивать различные версии и отменять отдельные изменения.
Кроме того, Git упрощает параллельное развитие проекта командой разработчиков с помощью ветвления. В основном ветке Git-репозитория хранится текущая стабильная версия исходного кода. Когда разработчику необходимо внести изменения в код, он создает отдельную ветку от основной и работает над своими изменениями. По завершении работы изменения сливаются в основную ветку, чтобы они были доступны другим участникам команды.
Описанные выше концепции представляются в упрощенном виде, поскольку работа с Git может быть предметом отдельной статьи. Для более подробной информации рекомендуется обратиться к официальному сайту. В данной статье мы сфокусируемся на процессе установки Git на Windows Server 2016, создания репозитория и первых коммитов в нём.
Дистрибутивы Git для Windows доступны на их официальной странице. Из нескольких вариантов приложения в нашем примере мы будем использовать версию Standalone. Для загрузки инсталлера данной версии перейдите по соответствующей ссылке.
После загрузки установочного файла запустите его на исполнение.
С самого начала выберите каталог, в который будет установлено приложение, либо согласитесь с предложенным по умолчанию.
Следующее окно мастера установки представляет собой окно выбора компонентов, предназначенных для установки.
На следующем шаге укажите каталог в стартовом меню, откуда будет запускаться приложение, либо согласитесь с предложенным по умолчанию, нажав Next не внося никаких изменений.
Далее, выберите текстовый редактор, который будет использовать приложение. По умолчанию мастер предлагает к использованию консольный текстовый редактор Vim. Вы можете указать другой редактор, доступный для выбора из списка.
В следующем окне укажите, как Git будет называть первую ветку в каждом из репозиториев. Раньше первая ветка всегда носила название master, но впоследствии многие проекты стали отказываться от такой практики и давать первым веткам другие названия. В связи с чем разработчики приложения добавили возможность присваивать первой ветке собственное имя.
Далее выберите способ использования Git. Здесь есть возможность указать следующие способы:
- Использовать Git только из командной строки.
- Работать с приложением из различных оболочек, а также интегрировать его с другими приложениями.
- Использовать Git вместе с некоторыми инструментами Unix.
В следующем окне выберите SSL/TLS-библиотеку, которую приложение будет использовать для HTTPS-подключений.
Затем выберите способ формирования конца строки в файлах. Основных способов существует два: LF и CRLF. Использование опции Checkout Windows-style, commit Unix-style line endings рекомендуется для применения в Windows-системах для кросс-платформенных проектов.
Далее укажите эмулятор терминала, который будет использован в Git Bash. По умолчанию это — эмулятор MinTTY .
В следующем окне выберите дефолтное поведение git pull. Опция, предлагаемая по умолчанию, в дальнейшем будет пытаться обновлять историю коммитов без создания коммитов слияния.
На следующем шаге выберите значение Git Credential Manager, если нужно, чтобы приложение сохраняло логины и пароли, которые используются при подключении к репозиториям. Для того, чтобы вводить учётные данные при каждом подключении, выберите значение None.
Далее, укажите дополнительные опции при необходимости.
Следующее окно содержит экспериментальные опции, которые пока не находятся в стабильной стадии. Используйте их, если в этом есть необходимость, и вы понимаете, что делаете. После чего нажмите Install для запуска процесса установки.
Создание репозитория
Приложение Git можно использовать в трёх разных вариациях:
- Windows-подобная командная строка — Git CMD;
- Linux-подобная командная строка — Git Bash;
- Графический интерфейс — Git GUI.
В качестве примера рассмотрим создание репозитория с помощью Git Bash.
Запустите Git Bash, и перед созданием первого репозитория укажите свои E-Mail и имя. Это нужно для того, чтобы в дальнейшем понимать, кто именно вносит изменения в репозиторий. Дело в том, что ваши E-Mail и имя приложение будут сохраняться в истории изменений при каждом коммите. Указать адрес электронной почты и имя можно с помощью следующих команд:
git config --global user.email "your-mail@your-domain.host"
git config --global user.name "Your Git User"
Здесь your-mail@your-domain.host — адрес электронной почты, а Your Git User — имя учётной записи. Используйте вместо них свои.
Перед созданием репозитория создайте директорию, в которой будут находиться его файлы:
mkdir your-rep
Теперь перейдите в созданный каталог:
cd your-rep
Для создания нового репозитория запустите следующую команду:
git init
Вывод команды должен выглядеть примерно следующим образом:
Теперь в этой же директории создайте файл README.md, содержащий любой текст. Для того, чтобы созданный файл попал в следующий коммит, необходимо проиндексировать внесённые изменения. Другими словами, нужно показать приложению, что данный файл Git должен учитывать в следующем коммите. Делается это командой:
git add README.md
Далее введите команду:
git commit
В результате файл README.md будет открыт при помощи выбранного при установке текстового редактора. Внесите в файл какой-либо комментарий для коммита, в котором лаконично опишите произведённое изменение.
Здесь следует обратить внимание на то, что Git добавляет сюда подсказку, которая при этом в коммит не войдёт, так как строки этой подсказки закомментированы при помощи символа # в начале строки. Вместе с тем, данная подсказка может быть полезна, поскольку содержит название ветки и список файлов, входящих в коммит.
По окончании редактирования файла закройте его с сохранением внесённых изменений. При этом следует иметь в в иду, что для редактирования файлов в Git Bash используется текстовый редактор vim. Вывод команды git commit будет выглядеть примерно следующим так:
Таким образом, вы сделали первый коммит.
Графический интерфейс
Git представляет собой утилиту командной строки. В то же время, довольно часто разработчики используют графический интерфейс Git.
Как было сказано выше, приложение Git в своём составе имеет графический интерфейс Git GUI. Чтобы на простейшем примере посмотреть его работу, запустите Git GUI.
При входе для того, чтобы подключиться к уже созданному репозиторию, перейдите в Open Existing Repository.
Затем при помощи кнопки Browse выберите каталог, содержащий файлы созданного репозитория и нажмите Open.
Теперь в любом текстовом редакторе внесите какие-либо изменения в уже существующий файл README.md, сохраните их и вновь перейдите в Git GUI. Для того, чтобы приложение увидело внесённые изменения нажмите Rescan.
В результате, Git покажет, что содержимое репозитория изменилось. Далее, нажмите Stage Changed, и приложение попытается добавить внесённые изменения в индекс Git. Данное действия является аналогом команды git add. А для того, чтобы данные изменения стали следующим коммитом, в поле Commit Message внесите комментарий для коммита и нажмите Commit.
Таким образом, вы сделали уже второй коммит в свой репозиторий.