Как настроить tortoisegit для gitlab

Как установить / настроить TortoiseGit для работы с GitHub

Я только что установил Git Для Windows, и создал мой SSH-ключ, используя SSH через Cygwin. Кажется, он работает из командной строки и Git для Windows GUI, но теперь я хочу использовать TortoiseGit. TortoiseGit по умолчанию использует SSH-клиент, похожий на шпатлевку, но, по-видимому, GitHub принимает только (открытый)SSH, и я действительно не знаю, как действовать. Я буду делать чистую установку TortoiseGit, у меня уже установлены Cygwin и Git для Windows.

3 ответов

для тех, кто хочет изменить существующую установку TortoiseGit для использования шпаклевка, а не OpenSSH, просто щелкните правой кнопкой мыши, -> TortoiseGit ->настройки ->сеть, затем измените ‘ ssh.exe ‘to’ tortoiseplink.exe. С этого момента выполнение push / pull должно использовать Pageant (и любые ключи, которые вы настроили там), если у вас также есть это работает.

самый простой способ-сначала установить TortoiseGit, а затем msysgit с настройкой SSH-клиента на TortoisePLink. Используйте генератор Puttykey TortoiseGit для создания новой пары ключей добавьте свой открытый ключ в GitHub.

клонировать/создать новый репозиторий. В настройках репозитория Thee Tortoise установите свое полное имя и адрес электронной почты. Затем в удаленном меню в меню конфигурации Git введите URL-адрес клона и выберите ключ шпатлевки. GitHub отлично работает с замазкой. У меня есть друзья, которые используют он, и я сам им пользовался.

1) Cygwin

использовать подход, описанный в статье работа с паролями ключей SSH.

пароль будет запрашиваться только один раз при запуске сеанса Cygwin. . Перед выходом из сеанса Cygwin не забудьте убить процесс ssh-agent (используйте ps для поиска процесса PID и kill -9).

мы используем отдельный подход для Cygwin, потому что Cygwin по какой-то причине не видит процессов, запущенных извне в среда Windows.

2, 3) MsysGit, TortoiseGit

Установить MsysGit. Установите TortoiseGit (проверьте openssh вместо plink во время установки). . Проверьте системные переменные. Если присутствует переменная GIT_SSH — удалите ее.

установить git EXE путь к / bin. Задайте для внешнего пути DLL значение /mingw / bin.

на TortoiseGit ->настройки ->сеть. Задайте для свойства клиента SSH значение /bin / ssh.exe

определите системную переменную SSH_AUTH_SOCKS=C:\temp.ssh-socket

запустить cmd.exe и выполнить следующие команды (так как мы установили MsysGit все следующие команды доступны в cmd — / bin добавляется в системный путь переменная):

вот именно. С этого момента вы можете выполнять git push , git pull из TortoiseGit и MsysGit без подсказки парольной фразы.

когда ssh-agent больше не требуется, вы можете убить его через Windows Диспетчер Задач.

Источник

Русские Блоги

Процесс настройки Git и TortoiseGit для генерации ключей SSH

1 Введение

В мире программистов управление версиями является неотъемлемой частью, потому что в повседневной работе обычного программиста код подобен кирпичу, перенесенному строителем, их будет много, и накопятся тысячи строк кода. Без инструментов управления версиями это, несомненно, отнимает много времени. Когда возникает проблема, возможно, что ваш локальный код был изменен и его необходимо откатить. Также возможно, что вам нужно отправить слишком много кодов за один раз, и вы обнаружите, что слишком много конфликтов необходимо решить. Возможно, однажды вы захотите вернуться назад. Вернемся к конкретной версии, чтобы снова начать разработку, может быть, в локальной разработке, чем больше написано кода, тем более проблематичным вы захотите клонировать новый код из удаленного репозитория и продолжать его использовать. Возможно, код, который был разработан в течение долгого времени, не работает должным образом после того, как вы его изменили. Это очень вероятно, потому что нормальная рабочая версия кода очень важна. Git — это такой инструмент управления версиями для разработки программ. Git — это распределенная система контроля версий с открытым исходным кодом, которая может эффективно и эффективно управлять управлением версиями проекта от очень маленьких до очень больших. Git — это программное обеспечение для управления версиями с открытым исходным кодом, разработанное Линусом Торвальдсом для управления и развития в Linux. Функции Git, используемые обычными разработчиками:
1. Клонируйте полный репозиторий Git с сервера (включая информацию о коде и версии)
2. Создавайте ветки и изменяйте коды в соответствии с различными целями разработки на своем компьютере.
3. Создайте исправление и отправьте исправление основному разработчику.
4. Если конфликты включены в представление, сначала необходимо разрешить конфликты.
5. Извлеките новую ветку из главной ветки, разработайте несколько параллельных ветвей и, наконец, разрешите конфликт и объединитесь в основную линию.

2 Материалы

При использовании Git для управления кодом программы список загружаемых файлов выглядит следующим образом:
1. Git-2.18.0-64-bit
2. TortoiseGit-2.6.0.0-64bit
3. TortoiseGit-LanguagePack-2.6.0.0-64bit-zh_CN
Эти файлы можно получить одним щелчком мыши по следующему URL-адресу:

Примечание. Поскольку текущая компьютерная система имеет 64 бита, предоставляется только 64 бита, и версию необходимо загрузить самостоятельно. Вышеупомянутые три файла были развернуты на нескольких компьютерах и могут работать нормально.
TortoiseGit — это клиент с открытым исходным кодом системы управления версиями Git, как и обычный файловый сервер, поскольку он имеет интерфейс и может отображать изменения файлов и каталогов указанным способом и может Это очень удобно, чтобы напомнить вам, когда вы изменили эти исторические данные и кто вы есть.
Git — основная функция управления версиями. Используя интерфейс командной строки Git, почти все функции могут быть реализованы в командной строке Bash. Единственным недостатком является то, что это не интуитивно понятно.
TortoiseGit на самом деле является упакованной программой для Git, используемой для упрощения работы Git. Язык — это китайский пакет TortoiseGit.

3 шага настройки

3.1 Установка программы

Убедитесь, что установка программы Git, TortoiseGit, TortoiseGit-LanguagePack-2.6.0.0-64bit-zh_CN.
Процесс установки не является большой проблемой, вы можете установить его по умолчанию в соответствии с запросом.

3.2 Генерация ключей SSH

Ssh keys — это файл секретного ключа для удаленного ssh-соединения, основанный на соединении с секретным ключом. ssh keys — это проверка безопасности на основе ключей в ssh. Вы можете выполнить проверку ключей ssh, создав пару открытого и закрытого ключей. Первая операция, которую необходимо выполнить, — это создать пару секретных ключей на локальном компьютере разработчика и поместить содержимое открытого ключа на сервер, к которому необходимо получить доступ. Если вы подключаетесь к серверу ssh, клиентское программное обеспечение отправит на сервер запрос с просьбой использовать ваш ключ для проверки безопасности.
После того как сервер получает запрос, он сначала ищет ваш открытый ключ в домашнем каталоге на сервере, а затем сравнивает его с открытым ключом, который вы отправили. Если два ключа совпадают, сервер шифрует «вызов» с помощью открытого ключа и отправляет его клиентскому программному обеспечению. После получения запроса клиентское программное обеспечение может расшифровать его с помощью своего закрытого ключа и отправить на сервер. Метод проверки входа в систему на основе ключей ssh ​​позволяет избежать проблемы подделки сервера, поскольку проблема подделки не может получить ваш секретный ключ. Это более безопасно, чем пароли на основе пользовательских паролей.

3.2.1 Создание ключей SSH для TortoiseGit

Нажмите PuTTYgen. Если вы установили «Все» или «Список» на работающий компьютер, просто найдите файл напрямую. Каталог по умолчанию для этого файла находится по адресу:

Следуйте инструкциям в области ключей

Быстро перемещайте мышь, чтобы сгенерировать случайное число для генерации открытого ключа. После генерации ключа сохраните файл открытого ключа в текущем каталоге [TortoiseGit \ bin], нажав Сохранить открытый ключ с именем id_rsa.pub, а затем нажмите Сохранить закрытый ключ, чтобы сохранить личный файл в текущем каталоге с именем id_rsa.pri. может.

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

Затем вам нужно скопировать сгенерированный файл открытого ключа, просто выберите все содержимое в области 2. Добавьте этот контент в личные настройки веб-страницы Git-сервера. Смотрите раздел 3.3

3.2.2 Генерация открытого ключа для Git

Важной проблемой является то, что открытый ключ, сгенерированный git, не согласуется с открытым ключом, сгенерированным TortoiseGit.

Ключ, сгенерированный в разделе 3.2.1, предназначен для клиента TortoiseGit. Следовательно, для Git необходимо сгенерировать открытый ключ.
Сначала вам нужно подтвердить, есть ли у вас ключ Git. По умолчанию ключ SSH пользователя сохраняется в каталоге

/ .ssh, введите каталог и перечислите его содержимое. Вы можете быстро подтвердить, есть ли у вас этот ключ:

Вам нужно найти пару имен файлов, названных в честь id_dsa или id_rsa, одно из которых имеет расширение pub, а другое — закрытый ключ. Файл .pub является открытым ключом, а другой — закрытым ключом. Если вы не можете найти такой файл, вы можете выполнить следующие операции для генерации пары ключей. Запустите приведенную выше команду на моей рабочей машине

Вы можете увидеть пару ключевых файлов id_rsa и id_rsa.pub
После установки программного обеспечения Git установочный пакет автоматически установит три приложения.

Пара ключей может быть сгенерирована через Git Bash или Git GUI.

3.2.2.1 Git UI генерирует ключ SSH

Нажмите на приложение Git GUI, появится следующий интерфейс

Нажмите Справка-> Показать ключ SSH.

После нажатия кнопки «Создать ключ» появятся два диалоговых окна, просто введите их напрямую. Выберите сгенерированный секретный ключ и скопируйте его. Вам необходимо добавить это содержимое в настройку личных ключей SSH на веб-сайте Git-сервера. Видно, что через этот интерфейс программа автоматически сохранит содержимое ключа в каталоге

То есть секретный ключ, сгенерированный таким образом, имеет тот же эффект, что и ключ SSH, сгенерированный Git Bash. Обратитесь к 3.3 для процесса копирования личных настроек на сервер Git.

3.2.2.2 Git Bash генерирует ключ SSH

В обеспечении каталога

После того как файлы id_rsa и id_rsa.pub не существуют, вы можете сгенерировать файл пары ключей через ssh-keygen через командную строку Git bash.
Сначала щелкните на рабочем столе или в любом каталоге файлов

Появится следующий интерфейс:

Вы можете видеть входы приложений Git GUI и Git Bash. Просто нажмите Git Bash.

Сначала ssh-keygen подтвердит место хранения ключа (по умолчанию ./ssh/id_rsa), затем попросит вас ввести пароль ключа дважды. Если вы не хотите вводить пароль при использовании ключа, оставьте его пустым.
Затем скопируйте все содержимое файла id_rsa.pub в персональные настройки сервера Git, см. 3.3.

3.3 Добавление ключей SSH на сайт Git

3.3.1 Войдите в Git

Используйте свою личную учетную запись Git для входа на URL-адрес Git-сервера, щелкните настройки под аватаром и выберите ключ SSH, который появится в левой части страницы.

3.3.2 Добавить ключ SSH

Скопируйте содержимое двух файлов с открытым ключом, созданных TortoiseGit и Git.

Сохраните содержимое двух файлов с открытым ключом в своих личных настройках.

3.4 Проверка результатов

3.4.1 Копировать Git URL

Войдите на сервер Git и скопируйте URL-адрес проекта SSH.

3.4.2 Использование Git Bash для клонирования проекта

Введите каталог файлов проекта, который вы хотите скопировать, например

Затем щелкните правой кнопкой мыши на пустом месте и выберите Git Bash. Введите команду git clone следующим образом:

3.4.3 Клонировать проект с помощью Tortoise Git

В текущем каталоге щелкните правой кнопкой мыши пустое пространство и выберите Git clone [Use Tortoise Git]. Рабочий интерфейс выглядит следующим образом:

После нажатия кнопки ОК: работающий интерфейс выглядит следующим образом:

Примечание: обязательно проверьте ключ Load Putty

4 Заключение

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

Источник

Как настроить tortoisegit для gitlab

Разработка с использованием сервиса GitHub

1. Установка git

Скачать и установить с официального сайта Git.

Git (произносится «гит») — распределённая система управления версиями. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux, первая версия выпущена 7 апреля 2005 года.

2. Установка git-клиента TortoiseGit

Скачать и установить с официального сайта TortoiseGit.

TortoiseGit — визуальный клиент системы управления исходными кодами программ Git для ОС Microsoft Windows. Реализован как расширение проводника Windows (shell extension). Подрисовывает иконки к файлам, находящимся под управлением Git, для отображения их статуса в Git.

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

3. Принципы работы с репозиторием

Прежде чем начать работу с репозиторием, необходимо сделать его собственное ответвление (fork — произносится «форк»). Для этого необходимо нажать кнопку Fork в правом верхнем углу экрана:

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

После этого клонируем собственное ответвление (fork) репозитория:

Для этого используем контекстное меню (длительное нажатие правой клавишей мыши) для требуемого каталога (рекомендуется использовать путь «p:\savushkin-r-d\» ), далее выбираем пункт «Git Clone» :

Задаем параметры клонирования:

в диалоговом окне:

Далее нажимаем кнопку OK и наблюдаем за ходом операции:

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

Чтобы удобно было работать, сразу стоит сделать себе ветку dev для работы (также используя контекстное меню):

Задаем название ветви, комментарий и указываем, что хотим далее работать с ней (активная галочка «Switch to new branch» ):

Теперь можно работать с версией в своей ветке dev . Настоятельно рекомендуется использовать ветку для разработки, а не master .

Добавим наш основной репозиторий, чтобы с него можно было обновляться (более подробно про команды):

Нажимаем OK для окна с описанием подхода для хранения настроек:

Далее добавляем основной репозиторий. Задаем имя и путь для основного репозитория:

для соответствующих полей и нажимаем кнопку Add New/Save :

и соглашаемся отключить обновление данного репозитория (нажимаем кнопку «Да» ). Также отменяем получение ветвей добавленного репозитория:

(нажимаем кнопку «Нет» ).

Важно: используйте следующие имена для remote ссылок:

• upstream — основной репозиторий (центральный), на нем всегда стабильная версия в master ;
• origin — ваш fork основного репозитория.

Разделение на upstream и origin позволяет вам не бояться «сломать» что-либо в основном репозитории. Так как вся ваша работа будет происходить с fork -ом.

4. Типовая схема совместной разработки проекта

Типовая схема совместной работы состоит из следующих этапов:

1. Обновление текущей версии до актуального состояния
2. Внесение изменений
3. Фиксация изменений (commit) в своем репозитории
4. Создание запроса на внесение изменений (Pull request) в основной репозиторий
5. Доработка по итогам рецензирования
6. Удаление ветви после принятия запроса (завершение разработки)

1. Обновление текущей версии до актуального состояния

Далее будет ряд команд, которые позволят получать обновления и работать с основным репозиторием. Предполагается, что для разработки создана ветвь dev (смотри 3. Принципы работы с репозиторием). Для их выполнения необходимо через контекстное меню для каталога репозитория вызвать консоль git:

Отобразится окно консоли для текущего репозитория:

Результат выполнения данных команд:

Для переноса изменений мы используем rebase — это позволяет сделать историю изменений легкой для чтения (более подробно можно почитать тут или тут). Если интересно чем это лучше merge то можно почитать эту статью.

2. Внесение изменений

Используя редактор (рекомендуется использовать Visual Studio Code) вносим изменения в файлы репозитория.

3. Фиксация изменений (commit) в своем репозитории

Вызываем через контекстное меню команду «Git Commit» :

Далее в окне фиксации изменений заполняем комментарий, проверяем корректность вносимых изменений для списка изменяемых файлов и нажимаем кнопку «Commit» :

Отображается окно с результатами выполнения операции, далее фиксируем их в своем ответвленном репозитории (fork) — кнопка «Push» :

В появившемся окне проверяем корректность параметров:

(из локальной ветви dev переносим изменения в удаленный репозиторий на сервер Github):

Нажимаем «ОК» и получаем результат выполнения данной операции:

Далее, если все необходимые изменения внесены, можно создать запрос на внесение изменений (Pull request) для того, чтобы данные изменения попали в основной (upstream) репозиторий.

4. Создание запроса на внесение изменений (Pull request) в основной репозиторий

После фиксации изменений (смотри предыдущий рисунок) переходим по активной ссылке на страницу Github для ветви dev :

В браузере отображается следующая страница, для создания запроса на внесение изменений нажимаем соответствующую кнопку:

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

После заполнения всех полей нажимаем на кнопку «Create pull request» для создания запроса. Созданный запрос будет отображаться на соответствующей вкладке «Pull requests» .

5. Доработка по итогам рецензирования

Во время рецензирования могут быть выявлены ошибки, предложены улучшения — данные изменения необходимо фиксировать в свою ветку origin/dev — они автоматически отобразятся на странице запроса внесения изменений.

6. Обновление ветви после принятия запроса (завершение разработки)

После принятия запроса необходимо обновить ветвь master (см. пункт Обновление текущей версии до актуального состояния) и переключиться на неё. Для следующей разработки, пересоздать ветвь dev (активная галочка «Force» ):

И далее по рассмотренной ранее схеме продолжать разработку.

5. Создание и оформление commit-ов

Каждый commit в репозиторий должен быть атомарным и иметь комментарий. Атомарность коммита заключается в том, что в нем находятся изменения в рамках одной задачи. Например: не стоит делать в одном коммите две такие вещи — переименование термина x в термин y ; удаление ненужных файлов.

Стоит из этого сделать два отдельных коммита:

• переименование термина x в термин y ;
• удаление ненужных файлов.

Каждый коммит НЕ должен приводить систему в «сломанное» состояние. После каждого из них она должна работать.

Чтобы упростить навигацию по истории к коммитам необходимо приписывать метки:

Возможные варианты меток:

• fix — когда были исправления в имеющихся исходниках;
• test — добавление и изменения в unit-тестах;
• doc — изменения в документации;
• img — изменения в фотографиях;
• config — изменения в конфигурационных файлах и файлах поддержки репозитория (например: .gitignore );
• review — изменения по комментариям после review.

• исправили ошибки в поясняющей картинке, тогда коммит выглядит так:

• добавили новые файлы и тесты к ним:

Таким образом разработчик, глядя на историю будет понимать, что меняется и где.

6. Запросы на внесение изменений (Pull requests)

К pull requests применяются следующие правила:

• создается из своей ветки на ветку master в основном репозитории;
• автор НЕ имеет права делать merge своему merge request;
• pull request должен быть просмотрен как минимум 2-мя людьми;
• если имеются автоматические тесты, то мержить pull request с НЕ работающими автоматическими тестами строго запрещено;
• просматривать pull request могут все желающие и высказывать свое мнение по нему или отдельным его частям;
• pull request принимается, когда все кто участвует в дискуссии пришли к «общему знаменателю».

• для написания комментариев к исходникам в pull request, необходимо перейти на вкладку Changes и добавлять комментарии к необходимым строкам:

• если ревьювер считает что merge request можно мержить и нет необходимых правок, то он делает Approve . Если же требуются изменения, то Request changes :

7. Именование документов

Все документы (файлы) должны находится в каталоге с кратким точным названием (на английском языке), отражающее содержимое документа. Примеры названий каталогов:

Непосредственно документы должны иметь название readme и расширение .md (используется язык разметки Мarkdown).

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

8. Использование Мarkdown

Данный облегчённый язык разметки повсеместно используется (для написания документации — *.md файла, комментариев и т.д.). Его подробное описание находится здесь.

About

Описание работы с репозиториями GitHub с помощью клиента TortoiseGit

Источник