Инструменты Git extensions linux sh не найдены

Обновлено: 21.11.2024

Git — наиболее часто используемая система контроля версий. С помощью Git вы можете отслеживать изменения, которые вы вносите в файлы, поэтому у вас есть запись о том, что было сделано, и вы можете вернуться к более ранним версиям файлов, если это необходимо. Git также упрощает совместную работу, позволяя объединять изменения, внесенные несколькими людьми, в один источник.

Git можно установить в Windows И на WSL

Важное соображение: когда вы включаете WSL и устанавливаете дистрибутив Linux, вы устанавливаете новую файловую систему, отделенную от диска Windows NTFS C:\ на вашем компьютере. В Linux дискам не присваиваются буквы. Им даются точки монтирования. Корень вашей файловой системы / — это точка монтирования вашего корневого раздела или папки в случае WSL. Не все под / является одним и тем же диском. Например, на моем ноутбуке я установил две версии Ubuntu (20.04 и 18.04), а также Debian. Если я открою эти дистрибутивы, выберите домашний каталог с помощью команды cd ~ , а затем введите команду explorer.exe . , откроется Проводник Windows и покажет путь к этому дистрибутиву.

Дистр Linux	Путь Windows для доступа к домашней папке
Ubuntu 20.04	\\wsl$\Ubuntu-20.04\home\username
Ubuntu 18.04	\\wsl$\Ubuntu-18.04 \home\username
Debian	\\wsl$\Debian\home\username
Windows PowerShell	C:\Users\имя_пользователя

Если вы пытаетесь получить доступ к каталогу файлов Windows из командной строки вашего дистрибутива WSL, вместо C:\Users\username , доступ к каталогу будет осуществляться с помощью /mnt/c/Users/username , потому что дистрибутив Linux просматривает ваш Файловая система Windows как смонтированный диск.

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

Установка Git

Git уже установлен в большинстве подсистем Windows для дистрибутивов Linux, однако вы можете обновить его до последней версии. Вам также потребуется настроить файл конфигурации git.

Чтобы установить Git, посетите сайт загрузки Git для Linux. Каждый дистрибутив Linux имеет собственный менеджер пакетов и команду установки.

Чтобы получить последнюю стабильную версию Git в Ubuntu/Debian, введите команду:

Вы также можете установить Git для Windows, если вы еще этого не сделали.

Настройка файла конфигурации Git

Чтобы настроить файл конфигурации Git, откройте командную строку для дистрибутива, в котором вы работаете, и задайте свое имя с помощью этой команды (заменив «Ваше имя» на предпочитаемое имя пользователя):

Установите адрес электронной почты с помощью этой команды (заменив "youremail@domain.com" на нужный адрес):

Если у вас еще нет учетной записи GitHub, вы можете зарегистрировать ее на GitHub. Если вы никогда раньше не работали с Git, руководства GitHub помогут вам начать работу. Если вам нужно отредактировать конфигурацию Git, вы можете сделать это с помощью встроенного текстового редактора, такого как nano: nano ~/.gitconfig .

Настройка Git Credential Manager

GCM интегрируется в процесс аутентификации для таких сервисов, как GitHub, и, как только вы проходите аутентификацию у своего хостинг-провайдера, запрашивает новый токен аутентификации. Затем он надежно сохраняет токен в диспетчере учетных данных Windows. После первого раза вы можете использовать Git для общения с вашим хостинг-провайдером без повторной аутентификации. Он просто получит доступ к токену в диспетчере учетных данных Windows.

Чтобы использовать GCM с WSL, вы должны использовать Windows 10 версии 1903 или более поздней версии. Это первая версия Windows, включающая необходимый инструмент wsl.exe, который GCM использует для взаимодействия с Git в дистрибутивах WSL.

Рекомендуется установить последнюю версию Git для Windows, чтобы обмениваться учетными данными и настройками между WSL и хостом Windows. Git Credential Manager входит в состав Git для Windows, а последняя версия включается в каждый новый выпуск Git для Windows. Во время установки вам будет предложено выбрать помощника по учетным данным, при этом GCM установлен по умолчанию.

Если у вас есть причина не устанавливать Git для Windows, вы можете установить GCM как приложение Linux непосредственно в своем дистрибутиве WSL, но обратите внимание, что это означает, что GCM работает как приложение Linux и не может использовать аутентификацию или хранилище учетных данных. особенности основной операционной системы Windows. Инструкции по настройке WSL без Git для Windows см. в репозитории GCM.

Чтобы настроить GCM для использования с дистрибутивом WSL, откройте дистрибутив и введите следующую команду:

Использование GCM в качестве помощника по учетным данным для установки WSL Git означает, что любая конфигурация, заданная в WSL Git, НЕ соблюдается GCM (по умолчанию). Это связано с тем, что GCM работает как приложение Windows и, следовательно, будет использовать установку Git для Windows для запроса конфигурации.Это означает, что такие вещи, как настройки прокси для GCM, должны быть установлены в Git для Windows, а также в WSL Git, поскольку они хранятся в разных файлах (%USERPROFILE%\.gitconfig vs \\wsl$\distro\home\$USER\.gitconfig ). Вы можете настроить WSL так, чтобы GCM использовал конфигурацию WSL Git, но это означает, что настройки прокси-сервера будут уникальными для конкретной установки WSL и не будут доступны другим пользователям или хосту Windows.

Git с SSH

Дополнительная конфигурация для Azure

Если вы собираетесь работать с Azure Repos или Azure DevOps, потребуется дополнительная настройка:

Теперь любая операция git, которую вы выполняете в дистрибутиве WSL, будет использовать GCM. Если у вас уже есть кэшированные учетные данные для хоста, он получит к ним доступ из диспетчера учетных данных. В противном случае вы получите диалоговое окно с запросом ваших учетных данных, даже если вы находитесь в консоли Linux.

Если вы используете ключ GPG для безопасности подписи кода, вам может потребоваться связать ключ GPG с электронной почтой GitHub.

Добавление файла игнорирования Git

Мы рекомендуем добавлять в проекты файл .gitignore. GitHub предлагает набор полезных шаблонов .gitignore с рекомендуемыми настройками файлов .gitignore, организованными в соответствии с вашим вариантом использования. Например, вот шаблон GitHub gitignore по умолчанию для проекта Node.js.

Если вы решили создать новый репозиторий с помощью веб-сайта GitHub, доступны флажки для инициализации вашего репозитория с помощью файла README, файла .gitignore, настроенного для вашего конкретного типа проекта, и вариантов добавления лицензии, если вам нужно один.

Git и код VS

Visual Studio Code поставляется со встроенной поддержкой Git, включая вкладку управления исходным кодом, которая будет отображать ваши изменения и обрабатывать различные команды git. Узнайте больше о поддержке Git в VS Code.

Окончания строк

Если вы работаете с одной и той же папкой репозитория между Windows, WSL или контейнером, обязательно настройте одинаковые окончания строк.

Поскольку Windows и Linux используют разные окончания строк по умолчанию, Git может сообщать о большом количестве измененных файлов, которые не имеют различий, кроме окончаний строк. Чтобы этого не произошло, вы можете отключить преобразование конца строки с помощью файла .gitattributes или глобально на стороне Windows. См. этот документ VS Code о решении проблем с окончанием строки в Git.

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

Конфигурация Git

Как вы кратко видели в Per Iniziare, вы можете указать параметры конфигурации Git с помощью команды git config. Первое, что вы сделали, это указали свое имя и адрес электронной почты:

Теперь вы познакомитесь с несколькими наиболее интересными параметрами, которые можно настроить таким образом, чтобы настроить использование Git.

Во-первых, краткий обзор: Git использует набор файлов конфигурации, чтобы определить поведение не по умолчанию, которое может вам понадобиться. В первую очередь Git ищет эти значения в файле /etc/gitconfig, который содержит значения для каждого пользователя в системе и всех их репозиториев. Если вы передадите параметр --system в git config , он будет читать и писать именно из этого файла.

Следующее место, куда обращается Git, — это файл ~/.gitconfig (или ~/.config/git/config ), специфичный для каждого пользователя. Вы можете заставить Git читать и писать в этот файл, передав параметр --global.

Наконец, Git ищет значения конфигурации в файле конфигурации в каталоге Git ( .git/config ) любого репозитория, который вы используете в данный момент. Эти значения относятся к одному репозиторию.

Каждый из этих «уровней» (системный, глобальный, локальный) перезаписывает значения на предыдущем уровне, поэтому, например, значения в .git/config перевешивают значения в /etc/gitconfig .

Файлы конфигурации Git представляют собой обычный текст, поэтому вы также можете установить эти значения, отредактировав файл вручную и вставив правильный синтаксис. Однако, как правило, проще запустить команду git config.

Базовая конфигурация клиента

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

core.editor

По умолчанию Git использует выбранный вами текстовый редактор по умолчанию ( $VISUAL или $EDITOR ) или использует редактор vi для создания и редактирования сообщений фиксации и тегов.Чтобы изменить это значение по умолчанию на что-то другое, вы можете использовать параметр core.editor: <Р> Теперь, независимо от того, что установлено в качестве редактора оболочки по умолчанию, Git запустит Emacs для редактирования сообщений.

commit.template <Р> Если вы установите на путь к файлу в системе, Git будет использовать этот файл в качестве сообщения по умолчанию, когда вы совершаете. Например, предположим, что вы создаете файл шаблона в ~ / .gitmessage.txt, который выглядит следующим образом: <Р> Чтобы сказать Git, чтобы использовать его в качестве сообщения по умолчанию, который появляется в редакторе, когда вы запускаете мерзавец совершал, установить commit.template значение конфигурации: <Р> Затем, ваш редактор откроет что-то подобное для заполнителя сообщения фиксации при фиксации:
Если ваша команда имеет политику фиксации-сообщение, а затем положить шаблон для этой политики в системе и настройка Git, чтобы использовать его по умолчанию может помочь увеличить вероятность этой политики регулярно следовали.

core.pager <Р> Этот параметр определяет, какой пейджер используется, когда Git страниц вывода, такие как бревна и дифференциал. Вы можете установить его на более или ваш любимый пейджер (по умолчанию, это меньше), или вы можете отключить его, установив его в пустую строку: <Р> Если вы бежите, что GIT пейджинговое весь вывод всех команд, независимо от того, как долго они.

user.signingkey <Р> Если вы делаете подписанные аннотированные метки (как описано в подписи вашей работы), установка ключа подписи GPG в качестве параметра конфигурации делает вещи проще. Установите идентификатор ключа следующим образом: <Р> Теперь вы можете подписаться теги без указания ключ каждый раз, когда с помощью команды мерзавца тега:

core.excludesfile <Р> Вы можете поместить образцы в .gitignore файл вашего проекта, чтобы Git не видеть их как неотслеживаемых файлы или попытаться организовать их при запуске Git надстройку на них, как описано в Игнорирование файлов. <Р> Но иногда вы хотите игнорировать определенные файлы для всех хранилищ, с которыми вы работаете. Если ваш компьютер работает под управлением Mac OS X, вы, вероятно, знакомы с .DS_Store файлами. Если ваш предпочтительный редактор Emacs или Vim, вы знаете о файлах, которые заканчиваются с ~. <Р> Этот параметр позволяет писать своего рода глобальный файл .gitignore. Если создать ~ / .gitignore_global файл с этим содержимым: <Р> ... и запустить мерзавец конфигурации --global core.excludesfile ~ / .gitignore_global, Git никогда больше не беспокоить вас об этих файлах.

help.autocorrect <Р> Если вы ошиблись при вводе команды, он показывает вам что-то вроде этого: <Р> Git услужливо пытается выяснить, что вы имели в виду, но она до сих пор отказывается это сделать. Если вы установите help.autocorrect 1, Git будет на самом деле выполнить эту команду для вас: <Р> Обратите внимание, что «0,1 секунды» бизнес. help.autocorrect на самом деле целое число, которое представляет десятую долю секунды. Так что, если вы установите его на 50, Git даст вам 5 секунд, чтобы изменить свой ум перед выполнением autocorrected команды.

Цвета в Git <Р> Git полностью поддерживает цветной вывод на терминал, который значительно помогает в визуально разбора вывода команды быстро и легко. Ряд вариантов может помочь вам установить раскраску по своему усмотрению.

color.ui
Git автоматически цвета большую часть своей продукции, но есть главный выключатель, если вам не нравится такое поведение. Чтобы отключить цветной вывод на терминал все Git, сделайте следующее: <Р> Значение по умолчанию автоматически, какие цвета выход, когда он идет прямо на терминал, но не включает коды цветового контроля, когда вывод перенаправляется в трубу или файл. <Р> Вы также можете установить его, чтобы всегда игнорировать разницу между клеммами и трубами. Вы редко будете хотеть этого; в большинстве случаев, если вы хотите, цветовые коды в вашем перенаправлены выходе, вы можете вместо этого передать --color флаг команды Git, чтобы заставить его использовать цветовые коды. Значение по умолчанию почти всегда то, что вы хотите.

цвет. * <Р> Если вы хотите, чтобы быть более точным, о которых команды окрашенные и как, Git предоставляет глагол-специфические окраски настройки. Каждый из них может быть установлен в True, False, или всегда: <Р> Кроме того, каждый из них имеет subsettings вы можете использовать для установки конкретных цветов для частей производства, если вы хотите заменить каждый цвет. Например, чтобы установить мету информации в своем выходе дифф на синий передний план, черный фон и жирный текст, вы можете запустить <Р> Вы можете установить цвет для любого из следующих значений: нормальный, черный, красный, зеленый, желтый, синий, пурпурный, голубой или белый. Если вы хотите, атрибут, как смелые в предыдущем примере, вы можете выбрать один из полужирных, тусклых, ула (подчеркивание), мигает, и обратный (своп передний план и фон).

Внешние Слить и Diff инструментов <Р> Хотя Git имеет внутреннюю реализацию дифф, которая является то, что мы были с указанием в этой книге, вы можете настроить внешний инструмент вместо этого. Вы также можете настроить графический инструмент слияния-разрешение конфликтов вместо того, чтобы разрешать конфликты вручную. Мы продемонстрируем настройки Perforce Визуальный Merge Tool (P4Merge), чтобы сделать ваши изменения и разрешения слияния, потому что это хороший графический инструмент, и это бесплатно.
Если вы хотите попробовать это, P4Merge работает на всех основных платформах, так что вы сможете это сделать. Я буду использовать имена путей в примерах, которые работают в системах Mac и Linux; для Windows вам придется изменить /usr/local/bin на путь к исполняемому файлу в вашей среде.

Для начала загрузите P4Merge из Perforce. Далее вы настроите внешние скрипты-оболочки для запуска ваших команд. Я буду использовать путь Mac для исполняемого файла; в других системах это будет место, где установлен ваш двоичный файл p4merge. Настройте сценарий оболочки слияния с именем extMerge, который вызывает ваш двоичный файл со всеми предоставленными аргументами:

Оболочка diff проверяет наличие семи аргументов и передает два из них сценарию слияния. По умолчанию Git передает программе сравнения следующие аргументы:

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

Вам также необходимо убедиться, что эти инструменты являются исполняемыми:

Теперь вы можете настроить свой конфигурационный файл для использования собственного разрешения слияния и инструментов сравнения. Для этого требуется ряд пользовательских настроек: merge.tool сообщает Git, какую стратегию использовать, mergetool. .cmd, чтобы указать, как запускать команду, mergetool. .trustExitCode, чтобы сообщить Git, указывает ли код выхода этой программы на успешное разрешение слияния или нет, и diff.external, чтобы сообщить Git, какую команду запускать для сравнения. Итак, вы можете запустить четыре команды конфигурации

или вы можете отредактировать файл ~/.gitconfig, добавив следующие строки:

После того, как все это установлено, если вы запускаете команды diff, такие как эта:

Вместо того, чтобы получать вывод различий в командной строке, Git запускает P4Merge, который выглядит примерно так:

Если вы попытаетесь объединить две ветки и впоследствии возникнут конфликты слияния, вы можете запустить команду git mergetool ; он запускает P4Merge, чтобы разрешить конфликты с помощью этого инструмента с графическим интерфейсом.

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

Теперь Git будет использовать инструмент KDiff3 для просмотра различий и разрешения конфликтов слияния.

Git предустановлен для использования ряда других инструментов разрешения слияния без необходимости настраивать конфигурацию cmd. Чтобы просмотреть список поддерживаемых инструментов, попробуйте следующее:

Если вы не заинтересованы в использовании KDiff3 для сравнения, а хотите использовать его только для разрешения слияния, и команда kdiff3 находится в вашем пути, вы можете запустить

Если вы запустите это вместо настройки файлов extMerge и extDiff, Git будет использовать KDiff3 для разрешения слияния и обычный инструмент Git diff для сравнения.

Форматирование и пробелы

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

core.autocrlf

Если вы программируете в Windows и работаете с людьми, которые этого не делают (или наоборот), вы, вероятно, в какой-то момент столкнетесь с проблемами окончания строки. Это связано с тем, что Windows использует как символ возврата каретки, так и символ перевода строки для новой строки в своих файлах, тогда как системы Mac и Linux используют только символ перевода строки. Это малозаметный, но невероятно раздражающий факт кроссплатформенной работы; многие редакторы в Windows молча заменяют существующие окончания строк в стиле LF на CRLF или вставляют оба символа конца строки, когда пользователь нажимает клавишу ввода.

Git может справиться с этим, автоматически преобразовывая окончания строк CRLF в LF, когда вы добавляете файл в индекс, и наоборот, когда код извлекается в вашу файловую систему. Вы можете включить эту функцию с помощью параметра core.autocrlf. Если вы работаете на компьютере с Windows, установите для него значение true — это преобразует окончания LF в CRLF при извлечении кода:

Если вы работаете в системе Linux или Mac, в которой используются окончания строк LF, вы не хотите, чтобы Git автоматически преобразовывал их при извлечении файлов; однако, если случайно появляется файл с окончаниями CRLF, вы можете захотеть исправить это с помощью Git. Вы можете указать Git конвертировать CRLF в LF при фиксации, но не наоборот, установив core.autocrlf для ввода:

Эта настройка должна оставить вам окончания CRLF при извлечении Windows, но окончания LF в системах Mac и Linux и в репозитории.

Если вы программист Windows и работаете над проектом только для Windows, вы можете отключить эту функцию, записав возврат каретки в репозиторий, установив для параметра конфигурации значение false :

core.whitespace

Git предустановлен для обнаружения и исправления некоторых проблем с пробелами. Он может искать шесть основных проблем с пробелами: три включены по умолчанию и могут быть отключены, а три по умолчанию отключены, но их можно активировать.

Те, которые включены по умолчанию, — это blank-at-eol , который ищет пробелы в конце строки; Blank-at-eof , который замечает пустые строки в конце файла; и space-before-tab, который ищет пробелы перед табуляцией в начале строки.

Три из них отключены по умолчанию, но их можно включить: indent-with-non-tab , который ищет строки, начинающиеся с пробелов, а не с табуляции (и управляется параметром tabwidth); tab-in-indent, который следит за табуляцией в отступе строки; и cr-at-eol , который сообщает Git, что возврат каретки в конце строк допустим.

Вы можете указать Git, какие из них вы хотите включить, задав для core.whitespace нужные значения, разделенные запятыми. Вы можете отключить настройки, либо исключив их из строки настроек, либо добавив - перед значением. Например, если вы хотите установить все, кроме cr-at-eol, вы можете сделать это:

Git обнаружит эти проблемы, когда вы запустите команду git diff, и попытаетесь выделить их цветом, чтобы вы могли исправить их перед фиксацией. Он также будет использовать эти значения, чтобы помочь вам при применении исправлений с помощью git apply . Когда вы применяете исправления, вы можете попросить Git предупредить вас, если он применяет исправления с указанными проблемами с пробелами:

Или вы можете сделать так, чтобы Git попытался автоматически исправить проблему перед применением исправления:

Эти параметры также применимы к команде git rebase. Если вы зафиксировали проблемы с пробелами, но еще не отправили их в основной поток, вы можете запустить git rebase --whitespace=fix, чтобы Git автоматически исправлял проблемы с пробелами по мере перезаписи исправлений.

Конфигурация сервера

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

получить.fsckObjects

Git может убедиться, что каждый объект, полученный во время отправки, по-прежнему соответствует контрольной сумме SHA-1 и указывает на допустимые объекты. Однако он не делает этого по умолчанию; это довольно дорогая операция и может замедлить ее, особенно при больших репозиториях или при отправке. Если вы хотите, чтобы Git проверял непротиворечивость объектов при каждой отправке, вы можете заставить его делать это, установив для Receive.fsckObjects значение true:

Теперь Git будет проверять целостность вашего репозитория перед принятием каждой отправки, чтобы убедиться, что неисправные (или вредоносные) клиенты не вносят поврежденные данные.

receive.denyNonFastForwards

Если вы перебазируете уже отправленные коммиты, а затем попытаетесь отправить их снова или иным образом попытаетесь отправить коммит в удаленную ветку, не содержащую коммит, на который в данный момент указывает удаленная ветка, вы будете отклонен. Обычно это хорошая политика; но в случае перебазирования вы можете решить, что знаете, что делаете, и можете принудительно обновить удаленную ветку с помощью флага -f в вашей команде push.

Чтобы указать Git отказаться от принудительной отправки, установите Receive.denyNonFastForwards :

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

receive.denyDeletes

Одним из способов обхода политики denyNonFastForwards является удаление пользователем ветки, а затем отправка ее обратно с новой ссылкой. Чтобы избежать этого, установите для параметра receive.denyDeletes значение true:

Это запрещает любое удаление ветвей или тегов — ни один пользователь не может этого сделать. Чтобы удалить удаленные ветки, необходимо вручную удалить ref-файлы с сервера. Есть также более интересные способы сделать это для каждого пользователя с помощью ACL, как вы узнаете из примера Git-Enforced Policy.

Настройка Git в Windows может оказаться сложной задачей по сравнению с Linux или Mac, но если вы выполните действия, описанные в этом руководстве, у вас не должно возникнуть проблем с использованием Git в Windows. Мы проделали тяжелую работу и выбрали один из нескольких вариантов на ключевых этапах, чтобы упростить вам задачу. В этом руководстве вы узнаете, как установить и настроить Git, а также подключить его к удаленным репозиториям для клонирования, отправки и извлечения. Если у вас его еще нет, создайте учетную запись Beanstalk.

Выбор дистрибутива Git

Существует два конкурирующих пакета Git для Windows: Git на основе Cygwin и версия под названием msysGit. Мы опишем, как установить пакет msysGit. Мы рекомендуем установить msysGit, поскольку мы обнаружили, что с ним проще работать, чем с установкой на основе Cygwin.

Установка Git

Загрузив исполняемый файл msysGit, дважды щелкните его, чтобы запустить мастер установки. Оставьте параметры каталога по умолчанию. Когда вы перейдете к настройке «Настройка среды пути», выберите параметр «Запустить Git из командной строки Windows».Выбор этого параметра облегчит вам запуск команд Git из командной строки Windows (командной строки), если вы выберете. Командная строка — это простой инструмент, с помощью которого вы можете запускать команды, переключаться между папками, управлять файлами, и его можно запустить, выбрав «Выполнить…» в меню «Пуск» и выполнив команду cmd.

Вы заметите, что в оставшейся части этой статьи мы будем использовать Git Bash для выполнения команд Git. Инструмент Git Bash работает так же, как командная строка Windows по умолчанию, но имеет некоторые особенности. С помощью Git Bash вы сможете использовать ряд инструментов командной строки UNIX вместе с доступом к Git, и мы рекомендуем его, поскольку зачастую его проще использовать, чем командную строку Windows.

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

Если вы используете более старую версию msysGit, вы можете столкнуться с шагом под названием «Выбор исполняемых файлов SSH». Если вы столкнулись с этим диалоговым окном, мы рекомендуем выбрать вариант «Использовать OpenSSH».

После того, как вы успешно установили Git в Windows, вам необходимо обеспечить безопасную связь с вашими репозиториями Git, создав и установив ключи SSH.

Установка ключей SSH в Windows

Для доступа к репозиториям Git вам потребуется создать и установить ключи SSH. Это можно сделать двумя способами:

Мы рекомендуем OpenSSH вместо PuTTY, и он устанавливается вместе с вашей копией Git. PuTTY рекомендуется только для опытных пользователей, которые уже знакомы с тем, как работает Git с ключами SSH.

Использование OpenSSH и генерация ключей SSH с помощью ssh-keygen

Для связи с удаленным репозиторием Git в вашей учетной записи Beanstalk с компьютера Windows вам потребуется сгенерировать пару ключей SSH для этого компьютера. Этот процесс требует всего несколько шагов, но сначала вам нужно установить msysGit с помощью полной программы установки, как описано выше.

Создание пары ключей

Для этого вам нужно запустить Git Bash, который можно найти в меню "Пуск". Выполните команду:

Он запросит местоположение и парольную фразу. Примите расположение по умолчанию (обычно C:\Documents and Settings\username\.ssh\ или C:\Users\username\.ssh ), нажав Enter . После этого не забудьте установить надежный пароль для ключа.

Теперь, когда ключи сгенерированы, откройте файл id_rsa.pub (найденный в папке по умолчанию из предыдущего шага) с помощью текстового редактора. Содержимое этого файла — ваш новый открытый ключ. Если вы скопируете его в буфер обмена, вы сможете добавить его в свой профиль Beanstalk (в разделе «Профиль и настройки» → «Ключи=»).

Проверка подключения

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

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

Во время аутентификации или позже при попытке подключения к репозиторию Git, скорее всего, вы увидите сообщение, похожее на это:

Если вы прошли аутентификацию правильно, вы увидите сообщение, похожее на это:

Если вы установили TortoiseGIT

Windows XP: Панель управления → Свойства системы → Дополнительно → Переменные среды.
Windows 7: Панель управления → Система → Дополнительные параметры системы → Переменные среды.

Возникли проблемы с подключением к репозиторию Git в Windows 7?

Альтернатива OpenSSH — использование PuTTY для доступа к вашему репозиторию Git

Установка Git и использование PuTTY для подключения к вашему репозиторию Git могут быть проблематичными, поэтому мы рекомендуем вам использовать метод OpenSSH, который мы описали в шагах выше. Использовать OpenSSH просто и понятно, но если OpenSSH не подходит или по какой-то другой причине вы предпочитаете использовать PuTTY для подключения к своим репозиториям, вот пошаговое руководство о том, как это сделать.

Как и OpenSSH, вы будете генерировать ключи SSH и использовать их для связи с вашими удаленными репозиториями Git, только теперь вы будете использовать инструменты PuTTY для создания, хранения и использования ключей.

Установка PuTTY

Вы можете загрузить установочный пакет PuTTY и запустить его. Последним установочным пакетом на момент написания этой статьи является putty-0.60-installer.exe, который можно найти в разделе «Установщик Windows для всего, кроме PuTTYtel».

Установите PuTTY в рекомендуемое по умолчанию расположение, обычно это c:\Program Files\PuTTY\ . После установки перейдите в папку установки, где вы найдете:

plink — интерфейс командной строки для серверной части PuTTY
puttygen — утилита для создания ключей RSA и DSA
pageant — агент аутентификации SSH для PuTTY, PSCP и Plink, в котором мы будем хранить ключи
putty — клиент Telnet и SSH

Вы также найдете некоторые другие файлы, но для этого руководства вам нужно знать только о plink, puttygen, pageant и putty.

Добавление переменной GIT_SSH в среду

После того, как вы установили пакет PuTTY, вам необходимо добавить переменную GIT_SSH в переменные среды, которая должна указывать на файл plink.exe (включая полный путь к нему). Принимая наши значения по умолчанию, указанные выше, это, вероятно, будет: GIT_SSH=c:\Program Files\Putty\plink.exe

Здесь можно найти и создать/изменить переменные среды, в зависимости от вашей версии Windows:

Windows XP: Панель управления → Свойства системы → Дополнительно → Переменные среды.
Windows 7: Панель управления → Система → Дополнительные параметры системы → Переменные среды.

Создание ключа SSH с помощью puttygen

Перед выходом из puttygen скопируйте открытый ключ в буфер обмена и вставьте его в свою учетную запись хостинга системы управления версиями (в Beanstalk в разделе «Профиль и настройки» → «Ключи»).

Обратите внимание, что при создании ключа с помощью puttygen открытый ключ, который вы копируете из puttygen, и открытый ключ, который вы сохраняете в файл для последующего использования, имеют разные форматы. На картинке ниже видно, что открытый ключ был сохранен с новыми строками и без ключевого слова «ssh-rsa». Чтобы скопировать и вставить открытый ключ в Beanstalk, вам нужно скопировать его в том же формате, в котором он был сгенерирован puttygen. Этот формат должен быть: «ssh-rsa keycodegenerated». Все, что вам нужно сделать, это изменить свой ключ в редакторе, таком как Блокнот, а затем добавить его в Beanstalk.

Добавление закрытого ключа на конкурс

Проверка подключения

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

Если вы еще не установили Git, загрузите исполняемый файл msysGit, дважды щелкните его, после чего должен запуститься мастер установки. Оставьте параметры каталога по умолчанию. Когда вы дойдете до настройки «Настройка среды пути», выберите параметр «Использовать только Git Bash». Выбор этого параметра поможет вам избежать конфликтов путей.

После того, как вы установили Git, запустите Git Bash и перейдите в каталог, в который вы установили PuTTY, и попробуйте получить доступ к своему репозиторию, набрав следующее:

Если вы не прошли аутентификацию правильно, появится сообщение, подобное следующему снимку экрана:

Если вы прошли аутентификацию правильно, появится новое окно с таким сообщением:

Всплывающее окно закроется вскоре после завершения аутентификации, что означает, что аутентификация прошла успешно, и теперь вы сможете управлять своими репозиториями Git.

Настройка профиля Git

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

Обзор

Чтобы иметь возможность использовать ваш репозиторий, вам необходимо:

Что теперь?

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

— отличное пошаговое руководство по использованию Git и печатной версии — узнайте о концепциях Git с помощью простой истории Тома Престона-Вернера.

Игорь Балош — инженер по контролю качества из Нови-Сада, Сербия.

Хотя у Mercurial есть четко определенный (хотя и внутренний) API, который можно использовать для написания расширений, расширяющих функциональность Mercurial, модель расширений git следует философии Unix, заключающейся в создании небольших простых программ для достижения аналогичного эффекта. Это означает, что «расширения» git могут быть написаны на любом языке, и, следуя нескольким простым правилам, можно добавлять команды, которые выглядят так, как если бы они были встроенными.

Пример: активность git

Чтобы увидеть активность во всех ветках репозитория, я реализовал команду git activity. git показывает последнюю фиксацию в каждой ветке, отсортированную по давности.

При выполнении в репозитории Rails он показывает следующий вывод:

Сценарий написан на bash и довольно прост. Мы устанавливаем цвета и анализируем некоторые параметры командной строки, поддерживаемые сценариями (например, чтобы отключить цвета, чтобы ограничить вывод), а затем запускаем git for-each-ref для вывода информации о каждой ссылке.

Он должен называться git-COMMANDNAME , в данном случае он называется git-activity
и он должен быть исполняемым и доступным в $PATH. В моем примере пользовательский скрипт git-activity находится в каталоге /usr/local/bin, но он может находиться в любом каталоге, который находится в $PATH:

Предоставление руководства/справочной страницы

Если пользовательская команда имеет сопровождающую справочную страницу, команда git help также покажет справочную информацию. Например. справочная страница для команды activity находится в /usr/local/share/man/man1/git-activity.1 и может быть отображена с помощью man git-activity или git help activity .

Команду manpath можно использовать для отображения местоположений, которые система использует для поиска справочных страниц:

Дополнительный совет Справочные страницы можно легко создать из Markdown с помощью Pandoc:

Заключение

Следуя нескольким простым правилам и применяя модель Unix, заключающуюся в составлении функциональности из небольших специализированных программ и скриптов, оказывается, что на удивление легко расширить функциональность git и сделать пользовательские команды частью набора команд git. .

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