Tortoisegit руководство на русском

уважаемые посетители блога, если Вам понравилась, то, пожалуйста, помогите автору с лечением. Подробности тут.

Что такое git? git — это распределенная система управления версиями.

Не так давно проект «Google API в Delphi» успешно переехал на новый адрес и теперь находится под управлением распределенной системы контроля версий Git. Для чего и почему мы это сделали — это вопрос второстепенный, а вот работа с Git, по крайней мере для меня, стала основной. По сути этот пост ни что иное как шпаргалка для себя любимого по выполнению основных операций при работе Git, но может эта шпаргалка поможет кому-то как и мне начать работу с этой DVCS.

Небольшое введение. О чем вообще пойдет речь

Git — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux.

То обстоятельство, что система создавалась «под Linux» уже как бы намекает на то, что без консоли нам не обойтись. Но не стоит махать руками и кричать «консоль отстой, git — в печь» и все такое. Поверьте — консоль Linux и консоль Windows имеют для обычного пользователя только одно общее свойство — чёрный экран при первом запуске. Команды Linux (ИМХО) просты и запоминаются без проблем, а работать с консолью не составляет особого труда даже для такого чайника, как я.

Самым главным, на мой взгляд, отличием Git от того же SVN является то, что в Git нет такого понятия как главный репозиторий. Каждый разработчик использует свою локальную версию репозитория, в которую делает commit’ы и, при необходимости, синхронизирует все изменения с репозиторием, располагающимся на сервере.

Это обстоятельство и поставило меня в начале работы с Git в тупик.
Как это так commit и не в центральный репозиторий?
Как правильно отправлять данные на сервер?
Как вообще начинать работу?
Эти и ещё многие другие вопросы посещали меня на старте работы с Git. Сейчас я не буду углубляться далеко в теоретические вопросы Git, да и вообще любых систем контроля версия — всего этого полно в Сети. А затрону один практический момент — как начать работу вообще, чтобы потом не было мучительно больно за бесцельно потерянные исходники.

Качаем и устанавливаем софт

Для работы с Git под Windows имеются вполне работоспособные и юзабельные решения, например, msysgit. Однако если Вы ранее имели опыт работы с SVN и использовали в работе TortoiseSVN, то видимо, Вам захочется иметь аналог подобного интерфейса и для Git? Нет проблем вот аналог TortoiseSVN для Git — TortoiseGit.
По сути TortoiseGit после нажатия команды из контекстного меню запускает консольную команду из MSysGit и рисует в окошко ее вывод. Если вы не хотите или просто не хватает времени детально разобраться в консольных командах Git, то TortoiseGit — то, что Вам нужно.
Итак, если Вы работаете под 32-х битной Windows, то Вам необходимо скачать следующий софт:

1. msysgit — качаем Git-1.7.1-previewXXXXXXXX.exe (11,6 Mb) Git For Windows
2. TortoiseGit. На момент написания статьи последней была версия TortoiseGit-1.5.2.0-32bit.msi (19.6 MB). Новые версии Вы можете найти также по приведенной ссылке.

Получается, что скачать нам надо чуть больше 30 Mb.
Теперь устанавливаем скачанные программы.

Вначале ставим msysgit, а потом TortoiseGit.

При установке msysgit настройки по умолчанию можно не изменять.
При установке TortoiseGit выбираем в окне «Choose SSH Client» второе значение:

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

Получаем доступ к репозиторию

В качестве примера я буду рассматривать получение доступа к нашему репозиторию, который располагается на github.com.
Распишем все операции по шагам.

1. Регистрация на GitHub’e.

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

2. Генерируем ключ для доступа по SSH.
Вот тут хочешь-не хочешь, а надо запускать консоль. После установки msysgit у Вас на рабочем столе появился новый ярлык — Git Bush — вот с помощью него и запускаем консоль.

1. Набираем в консоли следующую команду
   

   ssh-keygen -t rsa -C «E-Mail из Вашего профиля»

2. На экране появится запрос «Enter file in which to save the key». Пока оставим значение по умолчанию. Жмем Enter.
3. Нас попросят ввести пароль. Эту часть тоже пропускаем — впоследствии пароль можно будет установить, а пока — учимся. Жмем опять Enter.
4. Сгенерируются два файла один из которых — публичный ключ для доступа.

Если Вы все делали с настройками по умолчанию то файлы будут располагаться в директории:

C:/Documents and Settings/UserName/.ssh/

Заходим в директорию, открываем с помощью «Блокнота» файл ida_rsa.pub и копируем все его содержимое в буфер обмена.

3. Заносим публичный ключ доступа в профиль.

Для записи публичного ключа в профиль:

1. Заходим в свой профиль github и жмем ссылку Account Settings (сверху)
2. Выбираем пункт «SSH Public Keys»
3. Жмем ссылку «Add another public key»

Перед вами появится форма добавления нового публичного ключа. Вставляем из буфере весь скопированный ранее текст (из файла ida_rsa.pub) только в поле key — поле Title оставляем пустым.

На этом работа с публичными ключами закончена.

4. Просимся в проект.

Для этого достаточно найти наш проект на github и отправить одному из администраторов запрос на предоставление доступа к репозиторию. Или просто отправить мне email с логином на github. После того как вы будите записаны в список разработчиков проекта можно переходить к следующей фазе работы — получение исходников.

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

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

1. Вызываем контекстное меню и выбираем пункт «TortoiseGit — Settings«:

В появившемся окне переходим сразу к пункту «Git — Config» и записываем свое имя и адрес электронной почты. Эти данные должны в точности совпадать с теми, что записаны в Вашем аккаунте на github, иначе ваш ключ просто не подойдет.

2. Клонируем репозиторий. Для этого заходим на страницу проекта, и копируем в буфер адрес:

Теперь жмем правой кнопкой мыши на директории, в которой будем хранить исходники и в меню выбираем «Git Clone..«:

В открывшемся окне в поле URL вставляем скопированный адрес и жмем «Ok»:

Начнется процесс клонирования репозитория.

Всё вышесказанное можно было бы заменить всего двумя командами в консоли:

cd path/to/dir
git clone URL

После клонирования репозитория Вы автоматически переключитесь на нашу главную ветку (master). Так как каждый из нас занят определенной работой в проекте, то у каждого своя ветвь в репозитории, поэтому и Вам придется создавать свой branch. Делается это достаточно просто.

3. Создаем свою ветку. Для этого жмем правую кнопку мыши на директории в которую мы клонировали репозиторий и выбираем в меню «TortoiseGit — Create Branch«:

В открывшемся оке задаем название новой ветки и указываем на основании какой ветки репозитория мы будем создавать новую. Жмем «Ок», подтверждая создание ветки. Теперь переключаемся на свой новый branch.

Выбираем в меню «TortoiseGit — Switch/Checkout…«:

В открывшемся окне выбираем нашу новую ветку и жмем «Ок». Убеждаемся, что мы успешно переключились:

По сути, все что касалось создания нового branch’a в консоли решилось бы всего одной командой:

checkout -b new-branch

4. Программируем. Теперь, когда мы все настроили — открываем необходимый проект в Delphi, вносим свои коррективы, изменяем модули и т.д. В общем ведем нормальную плодотворную работу с проектом.

5. Вносим изменения в репозиторий. После того как внесены какие-то изменения нам необходимо их закрепить в Git. И здесь опять же проявляется отличие этой системы контроля версий от того же SVN. Дело в том, что Commit в Git не сбрасывается сразу на сервер. Для того, чтобы внести изменения в удаленный репозиторий используется команда PUSH. В общем виде работа может быть построена следующим образом:

1. Вносятся изменения в проект

2. Изменения закрепляются в вашем локальном репозитории, используя команду Commit в меню или, используя консоль:

git commit

3. Когда Вам необходимо/удобно/требуется закрепить все изменения на сервере выполняем push в свою ветку (brunch). Команда консоли выглядит так:

git push origin <свое имя бранча>

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

Для этого выбираем новый файл, вызываем меню и выбираем «Add…»:

По рисунку можно видеть, что я вношу в индекс новый файл text.txt. Жмем «Ok».

После того как файл добавлен, можно сразу же сделать Commit — кнопка Commit появится в окне с выводом консоли. Жмем её и откроется окно для внесения Commit’a:

Заполняем поле с описанием, жмем «Ок»  и коммит готов. Если хотите сразу отправить эти изменения в репозиторий, то в окне с выводом консоли появится также кнопка PUSH. Если же Вас не устраивает таскать по 1 файлику туда-сюда или изменения столь незначительны, что их нет смысла отправлять на сервер, то просто продолжаете дальше кодить, а push выполним позднее.

Чтобы выполнить команду push можете поступить следующим образом:

1. Зажимаем Shift и вызываем контекстное меню. В меню должны появится дополнительные команды:

Выбираем команду Push. Перед Вами откроется окно следующего содержания:

Все, что от Вас требуется на данном этапе — нажать на кнопку (на рисунке она выделена красным) найти в списке удаленную ветку в которую вы делаете push и два раза нажать Ok. Все изменения, произведенные Вами в локальном репозитории отправятся в Сеть.

Вот пожалуй все, что мне пока потребовалось использовать при работе с новой для меня системой контроля версий. Надеюсь эта мини-шпаргалка поможет кому-нибудь кроме меня. А если Вас заинтересовала работа с консолью, то как раз сейчас я изучаю Вот такие топики на habrahabr.ru:
1. Git Workflow.
2. Git Wizardry
Статьи написаны понятным простым языком и касаются как раз работы с Git с нуля.

Книжная полка

	Описание: Рассмотрены практические вопросы по разработке клиент-серверных приложений в среде Delphi 7 и Delphi 2005 с использованием СУБД MS SQL Server 2000, InterBase и Firebird. Приведена информация о теории построения реляционных баз данных и языке SQL. Освещены вопросы эксплуатации и администрирования СУБД.
	Описание: Рассмотрены малоосвещенные вопросы программирования в Delphi. Описаны методы интеграции VCL и API. Показаны внутренние механизмы VCL и приведены примеры вмешательства в эти механизмы. Рассмотрено использование сокетов в Delphi: различные режимы их работы, особенности для протоколов TCP и UDP и др.

уважаемые посетители блога, если Вам понравилась, то, пожалуйста, помогите автору с лечением. Подробности тут.

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

Содержание

1. Установка git
2. Установка git-клиента TortoiseGit
3. Принципы работы с репозиторием
4. Типовая схема совместной разработки проекта
5. Создание и оформление commit-ов
6. Запросы на внесение изменений (Pull requests)
7. Именование документов
8. Использование Мarkdown

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":

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

URL:        https://github.com/savushkin-r-d/hello-tortoisegit.git
Directory:  P:/savushkin-r-d/hello-tortoisegit/

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

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

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

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

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

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

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

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

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

Remote: upstream
URL:    https://github.com/savushkin-r-d/hello-tortoisegit.git

для соответствующих полей и нажимаем кнопку 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:

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

  
git checkout master        # переключаемся на ветку master
git remote update          # обновляем все remote
git update upstream/master # переносим в наш локальный мастер все изменения
git push origin master     # пушим в наш форк свежий master
git checkout dev           # переключаемся на нашу рабочую ветку
git rebase master          # переносим изменения из мастера в нашу ветку
  

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

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

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

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

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

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

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

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

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

Ref
Local:  dev
Remote: dev

Destination
Remote: origin

(из локальной ветви 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;
• удаление ненужных файлов.

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

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

[метка] Содержание коммита (#issue)
[метка1][метка2] Содержание коммита (#issue)

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

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

Например:

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

[img][fix] Исправлена ошибка в изображении (#38)  // где #38 ссылка на issue

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

[img][test] Добавлено описание формата X

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

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

Официальная документация по созданию Pull request.

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

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

Рецензия:

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

;

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

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

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

• Description
• Manual
• Scheme
• Report

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

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

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

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

Перейти к содержимому (нажмите Enter)

AlexESD

Блог на тему ПК, Embedded, и разного другого.

Редактирование конфига

При установке git в первую очередь нужно указать имя пользователя и email. Для настройки параметров нужно нажать
ПКМ ⇒ TortoiseGit ⇒ Settings
в разделе Git можно настроить такие параметры как имя, почту, зайти в конфигурационные файлы.

Нужно поменять кодировку на utf-8, для этого нужно зайти в settings ⇒ Git ⇒ Edit glogal .gitconfig и указать encoding = utf-8.

Создать локальный, клонировать удаленный репозиторий

Создание репозитория
ПКМ ⇒ Git create repository here ⇒ Ok.

Для клонирования репозитория перейти в каталог, где будет храниться репозиторий, нажать
ПКМ ⇒ Git clone
Заполнить два обязательных поля:
URL — ссылка на репозиторий
Directory — каталог куда будет скачан репозиторий
Можно так же указать приватный ключ для доступа к репозиторию в поле Load Putty Key.

Кроме того можно клонировать из локального каталога, указав его в строке источника.

Отслеживание (индексация) файлов

Файлы находятся в двух состояниях: отслеживаемые и не отслеживаемые. Отслеживаемые файлы — это те файлы, о которых знает Git.

После редактирования файла git будет его рассматривать как измененный, нужно проиндексировать изменения и зафиксировать (сделать commit).

Посмотреть состояние файлов можно нажав
ПКМ ⇒ TortoiseGit ⇒ Check for modification
или
ПКМ ⇒ TortoiseGit ⇒ Diff

Для того чтобы начать отслеживать новый файл, нужно нажать
ПКМ ⇒ TortoiseGit ⇒ Add и выбрать нужные файлы
или можно не добавлять их таким образом, при этом их можно будет автоматически добавить при коммите.

Коммиты

Для выполнения коммита нужно нажать
ПКМ ⇒ Git Commit, в поле Message написать комментарий.
В нижнем поле будут выведены файлы, которые будут добавлены в коммит, если они небыли индексированы ранее можно отметить их галочками и они добавятся. Затем нужно нажать кнопку Commit.

Чтобы перейти к коммиту нужно зайти в
ПКМ ⇒ TortoiseGit ⇒ Show log
нажать ПКМ по нужному коммиту выбрать Reset to this.
В открывшемся окне, в разделе Reset Type можно выбрать тип перехода:
Soft — файлы и индекс не изменятся, отменится сам коммит
Mixed — файлы не изменятся, отменится индексация
Hard — файлы изменятся таким образом, как они были в коммите на который осуществляется переход

Или зайти зайти в
ПКМ ⇒ TortoiseGit ⇒ Git Switch/Checkout и выбрать Commit.

Для удаления последнего коммита нужно перейти к предыдущему коммиту, выше описано как это сделать, затем нажать ПКМ по нужному коммиту выбрать Revert change by this commit.

История коммитов

История коммитов в виде списка
ПКМ ⇒ TortoiseGit ⇒ Show RefLog
История коммитов с отображением графа
ПКМ ⇒ TortoiseGit ⇒ Show log

Удаление файлов

Выделить нужный файл/файлы/папки затем нажать
ПКМ ⇒ TortoiseGit ⇒ Delete

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

Отмена индексации файла и отмена изменений незакоммиченного файла (состояния файла будет как в последнем коммите) осуществляется одинаково
Нужно выбрать файл, нажать ПКМ ⇒ TortoiseGit ⇒ Revert

Ветки

Ветка — это файл, содержащий хэш коммита, на который она указывает. При этом файлы проекта не копируются.

Создание/переключение/слияние

Создание ветки
ПКМ ⇒ TortoiseGit ⇒ Create Branch

Переключение на ветку
ПКМ ⇒ TortoiseGit ⇒ Git Switch/Checkout
Можно выбрать не только ветку, но и коммит

Создание ветки и переход в нее
ПКМ ⇒ TortoiseGit ⇒ Git Switch/Checkout
Поставить галочку Create New Branch, ввести имя ветки

После окончания работы над веткой ее нужно слить с основной, для этого нужно перейти на основную ветку
ПКМ ⇒ TortoiseGit ⇒ Git Switch/Checkout
и сделать merge, при этом указать ветку которую нужно влить
ПКМ ⇒ TortoiseGit ⇒ Merge

Если ветка больше не нужна ее можно удалить зайдя
ПКМ ⇒ TortoiseGit ⇒ Browse references

Если сделать две ветки, работать в одной из них, потом сделать merge в мастер, то в другой ветке этих изменений не будет, если нужно чтоб эти изменения появились в другой ветке, то нужно сделать merge из мастера или из первой ветки
ПКМ ⇒ TortoiseGit ⇒ Git Switch/Checkout
ПКМ ⇒ TortoiseGit ⇒ Merge

Вывод веток

Вывод списка веток
ПКМ ⇒ TortoiseGit ⇒ Browse references
Для отображения всех веток нужно поставить галочку
All Branches внизу окна

Удаление

Все удаления осуществляются в окне
ПКМ ⇒ TortoiseGit ⇒ Browse references

Переименование

Осуществляется в окне
ПКМ ⇒ TortoiseGit ⇒ Browse references

Копирование коммита из одной ветки в другую

Сначала нужно переключится на ветку, в которую нужно перенести коммит
ПКМ ⇒ TortoiseGit ⇒ Git Switch/Checkout
Открыть лог
ПКМ ⇒ TortoiseGit ⇒ Show log
Нажать ПКМ по нужному коммиту, затем Cherry Pick this commit, в открывшемся окне нажать Contune, затем Done
Коммит будет скопирован

Удаленные репозитории

origin — имя по умолчанию для удаленного репозитория.

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

Еще можно посмотреть подключенные репозитории в
ПКМ ⇒ TortoiseGit ⇒ Browse references в выпадающем меню remotes

Получение изменений из удаленного репозитория
ПКМ ⇒ TortoiseGit ⇒ fetch связывается с указанным удаленным репозиторием и забирает данные, которых еще нет в локальном репозитории, но не сливает их с локальными данными.
После fetch нужно выполнить слияние
ПКМ ⇒ TortoiseGit ⇒ Merge

ПКМ ⇒ TortoiseGit ⇒ pull забирает данные из удаленного репозитория и сразу сливает их с локальными

Отправка изменений на удаленный репозиторий
Сначала нужно сделать коммит
ПКМ ⇒ Git Commit
и можно отправлять
ПКМ ⇒ TortoiseGit ⇒ push

Если после клонирования удаленного репозитория, в нем были произведены изменения другим человеком, выполнить push не получится, нужно сначала получить изменения через pull или fetch и смержить их с локальным репозиторием. После этого можно будет сделать push.

Git клиент

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

Для генерации SSH ключа скачайте и установите  https://gitforwindows.org
Запустите C:Program FilesGitgit-bash.exe или в контекстном меню проводника windows выберете «Git Bash Here».
В оболочке введите команду генерации ключа с вашим email адресом
ssh-keygen -t ed25519 -C «nafanasev@gitlab.local»
При создании ключа, будут заданы дополнительные вопросы, есть возможность оставить все опции по умолчанию, нажав Enter.
После окончания генерации, будет создан файл C:Usersnafanasev.sshid_ed25519.pub
Полностью скопируйте содержимое файла и вставьте его в настройки своего профиля gitlab, User Settings — SSH Keys — Add key.

TortoiseGit

Установите TortoiseGit, все настройки можно оставить по умолчанию.

Создайте структуру папок, например:
C:/gitlab/nafanasev/test
где C:/gitlab/ просто папка
nafanasev соответствует названию группы проектов в gitlab — https://gitlab.local/nafanasev
а /test сам репозиторий — https://gitlab.local/nafanasev/test.git

Загрузка репозитория.
В контекстном меню папки C:/gitlab/nafanasev/ выберите TortoiseGit — Settings, в открывшемся окне выберете меню Git и введите Name и Email (должен совпадать с email введенным при генерации ключа). Сохраните изменения.
Вызовите контекстное меню папки C:/gitlab/nafanasev/ и выберете Git clone, в поле URL введите адрес репозитория, в следующем формате: https://gitlab.local/nafanasev/test.git и нажмите ОК. Файлы репозитория загрузятся в указанную папку.

Разработка.
Внесите необходимые изменения в файлы. Для сохранения изменений выполните Git Commit -> «master», в данном случае master это локальная ветка.
И отправьте изменения в gitlab, TortoiseGit — Push, выбрав в поле Remote ветку, отличную от master, обычно dev.

gitforwindows

Если вам не нужна дополнительная программа в виде TortoiseGit, можно ограничится только одним gitforwindows.
В первую очередь, добавьте хранилище кода gitlab в списки репозиториев gitforwindows.
В контекстном меню папки C:/gitlab/nafanasev/test и выберите «Git GUI Here», в открывшемся окне нажмите «Create New Repository». Выберете папку C:/gitlab/nafanasev/test и нажмите Create.
В открывшемся окне выберете Remote — Add и заполните поля
name — nafanasev/test
Location — ссылка вида https://gitlab.local/nafanasev/test.git

Загрузите файлы из репозитория.
Запустите C:Program FilesGitgit-bash.exe и выполните git pull git@gitlab.local:nafanasev/test.git

Разработка.
Создайте новую ветку Branch — Create, и введите ее имя.
Внесите необходимые изменения в файлы
Нажмите последовательно
Rescan
Stage Changed
заполните Commit Message
Commit
Push
Далее необходимо в gitlab создать merge request и смержить ветки.

IntelliJ IDEA

Откройте IntelliJ IDEA выберете VCS — Checkout from Version Control — Git
в поле URL введите ссылку на проект https://gitlab.local/nafanasev/test.git
выбирете папку для хранения проекта в поле Directory C:gitlabnafanasevtest
нажмите кнопку Test для проверки соединения
нажмите кнопку Clone
во всех появившихся окнах, выберете Yes и Next
дял commit нажмите Ctrl+K
для push нажмите Ctrl+Shift+K

1. Создайте репозиторий

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

1, 1 Создано с помощью GitBash
Сначала выберите подходящее место и создайте пустой каталог (D: temp git repository).
Щелкните правой кнопкой мыши текущий каталог и выберите Git Bash для запуска.


или запустите его в меню «Пуск». Обратите внимание, что если gitbash запускается из меню «Пуск», вам необходимо переключить каталог на каталог, в котором находится склад.

Создать команду выполнения хранилища:
$ git init
1, 2 Создано с помощью TortoiseGit
При использовании TortoiseGit просто щелкните контекстное меню в каталоге и выберите «Создать здесь репозиторий».



Репозиторий успешно создан, и в этом каталоге будет создан скрытый каталог .git, как показано ниже:

концепция:
Репозиторий: каталог «.git» является репозиторием. В будущем все файлы необходимо будет сохранять в репозитории.
Рабочий каталог: каталог, содержащий каталог «.git», то есть каталог верхнего уровня каталога .git является рабочим каталогом. В библиотеку версий можно сохранить только файлы в рабочем каталоге.

2. Добавьте файлы

Создайте файл mytest.txt в каталоге D: temp git repository



Текстовый файл становится значком со знаком «+»:

Отправить файл: еще раз щелкните правой кнопкой мыши файл mytest.txt и выберите «Отправить», затем сохраните файл в репозиторий.

3. Рабочая зона и зона временного хранения

Одно различие между Git и другими системами контроля версий, такими как SVN, заключается в концепции промежуточной области.
 Что такое рабочая область (рабочий каталог)?
 Рабочая область - это каталог, который вы можете видеть на компьютере. Например, моя папка с репортерами - это рабочая область.
 Некоторые студенты могут сказать, что репозиторий - это не репозиторий, а как это рабочее пространство? Фактически, каталог репозитория - это рабочая область, а скрытая папка «.git» в этом каталоге - это репозиторий. На этот раз концепция ясна.
 В репозитории Git хранится много вещей, наиболее важными из которых являются промежуточная область, называемая этапом (или индексом), первый мастер ветки, автоматически созданный Git для нас, и указатель на мастер, называемый HEAD.
 Как показано ниже: 

Когда мы добавляем файлы в репозиторий Git, мы выполняем его в два этапа:
 Первый шаг - добавить файл с помощью git add, что на самом деле должно добавить модификацию файла во временную область хранения;
 Второй шаг - отправить изменения с помощью git commit, что фактически означает отправку всего содержимого промежуточной области в текущую ветку.
 Потому что, когда мы создали репозиторий Git, Git автоматически создал для нас единственную главную ветвь, поэтому теперь git commit должен отправлять изменения в главную ветку.
 Вы можете просто понять, что все модификации файлов, которые необходимо отправить, помещаются во временную область хранения, а затем все изменения во временной области хранения отправляются сразу.

4. Измените файлы.

После изменения щелкните правой кнопкой мыши файл mytest.txt и выберите «Отправить».

5. Просмотрите историю изменений.

Вы можете щелкнуть файл правой кнопкой мыши и выбрать «Показать журнал», чтобы просмотреть историю изменений файла.

6. Сравнение различий

7. Восстановить изменения

Когда файл изменяется, вы не хотите отправлять измененный контент, но также хотите восстановить состояние до изменения. Теперь вы можете использовать функцию «Восстановить»



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

8. Удалите файлы.

9. Случай: отправьте Java-проект в репозиторий.

Шаг 1. Скопируйте проект-тест проекта Java из справочного материала в рабочий каталог.

Шаг 2. Добавьте проект во временное хранилище.



Игнорировать файлы или папки




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

Отправить код
Добавьте код в главную ветвь, и файл .gitignore также нужно добавить в промежуточную область, а затем отправить в репозиторий.

10. Игнорировать спецификации синтаксиса файлов.

Пустые строки или строки, начинающиеся с символа #, то есть строки комментариев, будут игнорироваться.
 Вы можете добавить косую черту / впереди, чтобы избежать рекурсии.В следующем примере вы можете четко увидеть отличие от следующего.
 Вы можете добавить косую черту / в конце, чтобы игнорировать папку, например, build / игнорирует папку сборки.
 Вы можете использовать! Чтобы отменить игнорирование, то есть, если вы использовали * .apk раньше, а затем использовали! A.apk, a.apk не будет проигнорирован.
 * Используется для сопоставления нуля или более символов, например *. [Oa] игнорировать все файлы, заканчивающиеся на «.o» или «.a», * ~ игнорировать все файлы, заканчивающиеся на ~ (этот тип файлов обычно отмечается многими editors Temporary files); [] используется для соответствия любому символу в скобках, например [abc], и в скобках также можно добавить дефис, например, [0-9] соответствует числу от 0 до 9 ;? Используется для сопоставления одного символа. 
 Увидев столько, у меня все равно должен быть каштан:
 # Игнорировать файлы .a
*.a
 # Но пренебречь игнорированием lib.a, хотя ранее файл .a игнорировался
!lib.a
 # Игнорировать только файлы TODO в текущем каталоге, но не включать подкаталог / TODO в подкаталоги
/TODO
 # Игнорировать все файлы в папке build /
build/
 # Игнорировать doc / notes.txt, не включать doc / server / arch.txt
doc/*.txt
 # Игнорировать все файлы .pdf в каталоге doc /
doc/**/*.pdf

11. Добавить удаленную библиотеку

Теперь, когда мы создали хранилище Git локально и хотим позволить другим людям развиваться совместно, мы можем синхронизировать локальный склад с удаленным и добавить резервную копию локального хранилища.
 Обычно используемым удаленным хранилищем является github: https://github.com/. Далее мы продемонстрируем, как синхронизировать локальный код с github.

11.1 Создать склад на github

Нажмите кнопку «создать репозиторий», чтобы успешно создать репозиторий.

 Github поддерживает два метода синхронизации: https и ssh.
 Если использовать https очень просто, вы можете использовать его в основном без конфигурации, но вам нужно вводить имя пользователя и пароль каждый раз, когда вы отправляете и загружаете код.
 Если вы используете ssh, клиенту необходимо сначала сгенерировать пару ключей, то есть открытый ключ и закрытый ключ. Затем вам нужно разместить открытый ключ на сервере githib.
 Оба эти метода используются в реальной разработке, поэтому нам необходимо их освоить. Затем мы сначала рассмотрим метод ssh.

 протокол ssh
 SSH - это сокращение от Secure Shell (Secure Shell Protocol), разработанное сетевой рабочей группой IETF.
 SSH в настоящее время является более надежным протоколом, предназначенным для обеспечения безопасности сеансов удаленного входа в систему и других сетевых служб.
 Использование протокола SSH может эффективно предотвратить утечку информации при удаленном управлении.

11. Генерация ключей 2ssh
В Windows мы можем использовать Git Bash.exe для генерации ключа и открывать Git Bash через меню «Пуск» или меню, вызываемое правой кнопкой мыши.

git bash выполнить команду, жизненный открытый ключ и закрытый ключ
Команда: ssh-keygen -t rsa

После завершения выполнения команды в локальном каталоге user.ssh окна C: Users username.ssh сгенерируйте открытый и закрытый ключи со следующими именами:

11. Конфигурация клавиш 3ssh
После того, как ключ сгенерирован, вам необходимо настроить ключ локально на github для беспрепятственного доступа.


Добавьте содержимое файла id_rsa.pub в раздел ключей, а затем нажмите кнопку «Добавить ключ SSH», чтобы завершить настройку.
11.4 Синхронизация с удаленным складом
Для синхронизации с удаленным хранилищем можно использовать git bash или tortoiseGit
11, 4, 1 используйте git bash
В каталоге, где расположен склад (D: temp git repository), щелкните правой кнопкой мыши и выберите «Git Bash Here», чтобы запустить программу git bash.

Затем выполните следующую инструкцию в git bash:
git remote add origin [email protected]:sublun/mytest.git
git push -u origin master
Примечание. Красная часть шрифта должна быть заменена личным именем пользователя.
Как получить следующую ошибку:

Вы можете сначала выполнить следующую команду, а затем выполнить указанную выше команду
$ git remote rm origin

11, 4, 2 используйте TortoiseGit для синхронизации
1. Поскольку инструмент ssh, используемый TortoiseGit, — это «PuTTY», инструмент ssh, используемый git Bash, — это «openSSH», если вы хотите, чтобы TortoiseGit также использовал только что сгенерированный ключ, вы можете выполните следующую настройку:



Url: адрес удаленного склада.
URL для отправки: то же самое
Putty key: выберите закрытый ключ в только что сгенерированном ключе.
2. Синхронизируйте. Щелкните правой кнопкой мыши папку локального хранилища и выберите «Git Sync».

12. Клонирование с удаленного склада.

Клонирование удаленного хранилища — это копирование копии хранилища с удаленного на локальный, и после клонирования будет создан новый локальный склад. Выберите каталог любого хранилища развертывания, а затем клонируйте удаленный склад.
12.1 Используйте git bash:
$ git clone [email protected]:sublun/mytest.git
12.2 Используйте TortoiseGit:
Щелкните правой кнопкой мыши в любом каталоге:

13. Получить код с удаленного склада

В Git есть две команды для получения последней версии из удаленной ветки на локальную:
 1. Git fetch: это эквивалентно получению последней версии с удаленного на локальный, а не автоматическому слиянию (слияние кода)
 2. git pull: эквивалент получения последней версии с удаленного компьютера и слияния с локальной.
 Приведенная выше команда фактически эквивалентна git fetch и git merge.
 На практике git fetch безопаснее
 Потому что перед слиянием мы можем проверить статус обновления, а затем решить, нужно ли слить
 Если вы используете TortoiseGit, вы можете щелкнуть «pull» или «fetch» ​​из контекстного меню.

14. Создайте частный сервер Git.

14.1 конструкция сервера

Удаленный склад на самом деле ничем не отличается от местного склада, только 7x24 часа для запуска и обмена вашими изменениями.
 GitHub - это удаленный репозиторий с бесплатным открытым исходным кодом. Но для некоторых коммерческих компаний, которые рассматривают исходный код как жизнь,
 Если вы не хотите раскрывать исходный код и не хотите платить за защиту GitHub, вы можете создать только Git-сервер для использования в качестве частного хранилища.
 Для создания сервера Git вам необходимо подготовить машину под управлением Linux, здесь мы используем CentOS. Ниже приведены шаги по установке:
 1. Установка подготовки служебной среды git (онлайн-установка, сервер Linux должен иметь доступ к Интернету)
yum -y install curl curl-devel zlib-devel openssl-devel perl cpio expat-devel gettext-devel gcc cc
 2. Загрузите git-2.5.0.tar.gz
 1) Распаковать
2）cd git-2.5.0
 3) autoconf (выполнить команду)
 4) ./ configure (выполнить команду)
 5) make (выполните эту команду, чтобы скомпилировать исходный код)
 6) make install (выполните эту команду, чтобы установить git в соответствующий каталог)
 После завершения выполните git --version, чтобы просмотреть текущую версию git.
 3. Добавьте пользователей
adduser -r -c 'git version control' -d /home/git -m git
 После выполнения этой команды каталог / home / git будет создан как домашний каталог пользователя git.
 5. Установите пароль.
passwd git
 Введите пароль дважды
 6. Переключитесь на пользователя git.
su git
 Создать складскую папку repo1

7, создайте репозиторий git
git --bare init /home/git/first
 Примечание. Если параметр «--bare» не используется, при отправке главной ветви после инициализации хранилища будет сообщено об ошибке. Это из-за git
 По умолчанию операция push отклонена, и в .git / config необходимо добавить следующий код:
[receive]
      denyCurrentBranch = ignore
 Рекомендуемое использование: git --bare init для инициализации хранилища.

14, 2 подключиться к серверу

После настройки частного сервера git его можно подключить и использовать как github, но наш сервер git не настроен с использованием ключа входа в систему, поэтому вам нужно вводить пароль каждый раз при подключении.
 Используйте команду для подключения:
$ git remote add origin ssh://[email protected]/home/git/first
 Кажется, эта форма отличается от той, что использовалась только что. У нее есть префикс ssh: //, поэтому вы также можете написать ее так:
$ git remote add origin [email protected]:first

 Чтобы использовать TortoiseGit для синхронизации, см. Метод использования выше.

15. Используйте TortoiseGit для реализации управления ветвями.

15, 1 создать ветку
Щелкните правой кнопкой мыши папку локального хранилища и выберите в меню «Создать ветвь»:

Если вы хотите переключиться на новую ветку сразу после создания, вы можете установить флажок «Переключиться на новую ветку» или выбрать «Переключить / оформить» в меню, чтобы переключить ветку:

15, 2 слияния веток
После того, как ветвь переключена на dev, файлы в рабочей области могут быть изменены, а затем отправлены в основную ветвь принципа ветвления dev не будут затронуты. Например, мы изменяем содержимое mytest.txt и затем отправляем его в ветку dev.


После переключения на основную ветвь основным содержимым по-прежнему остается:

Объединяет содержимое ветки dev с ветвью master, и текущая ветвь является главной. В контекстном меню выберите «Объединить»:

Еще раз проверьте содержимое mytest.txt, и он был обновлен:

15, 3 разрешение конфликтов
Содержимое, редактируемое в двух ветвях, не зависит друг от друга и не мешает друг другу, поэтому, если один и тот же файл редактируется в обеих ветвях, а затем объединяется, может возникнуть конфликт.
Например, отредактируйте mytest.txt в главной ветке:

Затем отправьте в репозиторий.

Переключитесь на ветку dev и отредактируйте mytest.txt:


Наконец, слияние веток, например, слияние ветки dev с веткой master. Вам нужно сначала переключиться на главную ветку, а затем объединить ветки.

Конфликт версий.


Конфликты необходимо разрешать вручную.

Щелкните правой кнопкой мыши файл конфликта и выберите пункт меню «Разрешить конфликт»:


Просто отправьте файл с устраненным конфликтом в репозиторий.

TortoiseGit Manual

Теперь будем рассматривать комплексные утилиты оболочки работы с Git. Начнем TortoiseGit.

Качаем тут.

Скачиваем сам дистриб

Я выбрал под свою разрядность вы выбираете под свою.

И если надо там же можно скачать языковый пакет русского языка для TortoiseGit

Устанавливаем

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

Жмем старт и идем в настройки

И видим это

Далее идем в раздел Git и видим предупреждение на враждебном нам буржуйском языке

Что в переводе означает

Это нам говорят про это. Ставим галку чтобы нам это больше не показывали. Мы и так про это знаем.

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

На скрине ниже я показал этот пункт и весь раскрытый пункт контекстного меню TortoiseGit

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

Из всего этого добра мне понравилось красивый просмотр логов (как раз пункт меню который я оставил):

Ну и сравнение файла из различных коммитов. Правда это чуток заморочено тут, но все же можно сделать.

И так сравним версии файла из коммита 2 и коммита 4. На коммите 2 делаем правый клик мышью

Далее видим скрин что ниже и убираем там все эти нули. Если не убрать то вылетит ошибка и жмем раскрывающийся список RefBrowse

Далее видим это и выбираем четвертый коммит

Жмем Compare revisions и видим сравнение файла test.txt из коммитов 2 и 4

Так же можно воспользоваться графическим интерфейсом для слияния веток. Но как то оно мне там не очень понравилось. Привычней уже при помощи командной строки это делать и разрешать конфликт уже при помощи графических утилит. Кстати, TortoiseGitMerge можно, так же настроить в Git, как внешние утилиты сравнения и слияния. Что я и сделаю. Об этом читайте в следующем посте.

Цель этого была просто познакомить с TortoiseGit.

Содержание

	Введение
	Установка Git Bash
	Установка Tortoise Git
	TortoiseGit и GitLab
	Другие статьи про Git

Введение

Обычно

git

не установлен по умолчанию, поэтому нужно установить

Git Bash
,

Tortoise Git

или какое-то другое решение.

Установка Git Bash

Про установку и настройку Git Bash в Windows вы можете прочитать в статье

Git Bash

TortoiseGit

После установки Git for Windows появится консоль

TortoiseGit и GitLab

После утомительного движения мышью в течении ~ 30 секунд Вы
увидите результат.

Проще всего скопировать его из окна putty

В случае успеха Вы попадёте на

Чтобы получить точный url который Вы хотите клонировать зайдите в нужную ветку
(branch) и нажмите на кнопку Clone.

Выберите Clone with SSH. Чтобы скопировать этот адрес нужно нажать на значок копирования.

Создадим папку Gitlab_test_HeiHei.ru

Кликаем правой кнопкой и выбираем Git Clone

В случае успеха TortoiseGit покажет сообщение Success

Ветки — Branches

Посмотреть на список всех веток можно в разделе Repository → Branches

Чтобы поменять ветку, с которой Вы синхронизировали папку на
Вашем компьютере.

Похожие статьи

	Git
	Установка в Linux
	Установка в Windows

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

О чём же я расскажу? Я расскажу о том как:

• как создавать, клонировать, удалять репозиторий
• как создавать бренчи (ветки)
• как работать добавлять контребьютеров (участников) в репозиторий

Итак, для начала установите

,

, а также зарегистрируйтесь на

. Я пропущу этап установки, так как гайд не об этом, благо инструкций по установке много. Да и вообще, когда запустить и прокликать «Далее» стало неимоверно сложным процессом? Давайте лучше приступим к настройке ПО.

Первым делом сделаем «самую грязную» работу в консоли. Запустите терминал Git Bush и введите следующую команду:
ssh-keygen -t rsa -C “e-mail” //e-mail - мыло, на которое зарегистрирован аккаунт github
Далее консоль от вас потребует ключ и пароль, но мы не будем лишний раз использовать терминал (СТРАШНО, ВЫРУБАЙ), поэтому оба раза нажимаем Enter.
Если вы всё сделали правильно, то у вас должен появиться ssh-ключ в следующем каталоге:
C:/Documents and Settings/ИмяПользователя/.ssh/

Теперь перейдём на github, чтобы привязать наш аккаунт к этому ключу.

Нажимаем на кнопку «New SSH key» и вставляем содержимое файла ida_rsa.pub. Вот и всё, осталось разобраться с TortoiseGit.

Заходим в каталог, где вы будете хранить репозитории. Нажимаем ПКМ и заходим в настройки TortoiseGit. Указываем логин и пароль от github.

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

Создаём репозиторий
Тут всё просто, заходим в свой профиль, и нажимаем кнопку New, указываем нужные параметры.

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

Клонируем репозиторий
Тут уже немного сложнее. Если вы создали репозиторий сначала на github (что гораздо удобнее), то чтобы вам в нем работать, требуется клонировать его к себе на диск. Для этого кликаем ПКМ по директории и нажимаем Git Clone, вставляем ссылку на репозиторий, полученную на его странице GitHub.

Учимся коммитить, пушить, а также создавать pull-запрос
Разберемся в терминологии: коммитить — делать некую запись, означающую последние изменения в исходном коде, пушить — заливать изменения на github, создавать pull-запрос — загружать последние изменения с github к себе на диск. Если вам не удается запушить изменения, то попробуйте очистить локальный репозиторий командой Clean Up, ну а если вы хотите откатиться назад, используйте Revert:

Чтобы сделать commit, для начала внесите какие-либо изменения в проекте. Далее ПКМ по директории и выберите Git Commit -> «master». В открывшемся окне напишите об изменениях (кратко и понятно, мемуары (от слова мем) писать не нужно), а также выберите нужные файлы. Нажмите Commit & Push (сразу закоммитите и запушите).

Создаем бренч для других разработчиков
Для командной разработки необходимо создавать ветки. То есть у каждого разработчика будет своя ветвь разработки, в которой он будет работать над определенной частью кода (желательно не менять один и тот же кусок кода двум разработчикам одновременно). Также у вас могут быть ветви для каких-то эксперементальных версий исходника. Кстати, до этого мы работали в главной ветви master, в которую как раз и будут вноситься изменения из некоторых бренчей. То есть некая ветвь «Vasya19» будет объединена с основной ветвью «master».
Чтобы создать ветвь, перейдите на главную страницу репозитория и в следующем поле введите название новой ветки:

Нажимаем Create Brench. Далее в настройках репозитория GitHub добавьте контребьютера (участника) репозитория. Для этого вам надо знать его имя, после добавления ему придёт приглашение на почту.

Приглашенный человек должен клонировать репозиторий к себе и свичнуть ветку:

Кстати, совсем не обязательно создавать ветки только на сервере. Вы можете создать локальную ветку, которая будет только у вас на компьютере. Она может быть предназначена для чего угодно.

Вот и всё, введение в основы использования Git я вас посвятил, теперь вы немножечко (множечко) умнее. Надеюсь, что после этой стать вам захотелось использовать Git.

Гайд — мой, написан мною для другого борда, не реклама