Tortoise git for windows как работать

TortoiseGit Manual

This document describes day to day usage of the TortoiseGit client. It is not an introduction to version control systems, and not an introduction to Git. It is more like a place you may turn to when you know approximately what you want to do, but don’t quite remember how to do it.

For hints where to find more information about doing version control with Git see the section called “Reading Guide”.

This document is also a work in progress, just as TortoiseGit and Git are. If you find any mistakes, please report them to the mailing list so we can update the documentation. Some of the screenshots in the Daily Use Guide (DUG) might not reflect the current state of the software. Please forgive us. We’re working on TortoiseGit in our free time.

In order to get the most out of the Daily Use Guide:

  • You should have installed TortoiseGit already.

  • You should be familiar with version control systems.

  • You should know the basics of Git.

  • You should have set up a server and/or have access to a Git repository.

Getting Started

Icon Overlays

Figure 2.1. Explorer showing icon overlays

Explorer showing icon overlays

One of the most visible features of TortoiseGit is the icon overlays which appear on files in your working tree. These show you at a glance which of your files have been modified. Refer to the section called “Icon Overlays” to find out what the different overlays represent.

Context Menus

Figure 2.2. Context menu for a directory under version control

Context menu for a directory under version control

All TortoiseGit commands are invoked from the context menu of the windows explorer. Most are directly visible, when you right click on a file or folder. The commands that are available depend on whether the file or folder or its parent folder is under version control or not. You can also see the TortoiseGit menu as part of the Explorer file menu.

Tip

Some commands which are very rarely used are only available in the extended context menu. To bring up the extended context menu, hold down the Shift key when you right-click.

In some cases you may see several TortoiseGit entries. This is not a bug!

Figure 2.3. Explorer file menu for a shortcut in a versioned folder

Explorer file menu for a shortcut in a versioned folder

This example is for an unversioned shortcut within a versioned folder, and in the Explorer file menu there are two entries for TortoiseGit. One for the shortcut itself and the second for the object the shortcut is pointing to. To help you distinguish between them, the icons have an indicator in the lower right corner to show whether the menu entry is for a file, a folder, a shortcut or for multiple selected items.

Drag and Drop

Figure 2.4. Right drag menu for a directory under version control

Right drag menu for a directory under version control

Other commands are available as drag handlers, when you right drag files or folders to a new location inside working trees or when you right drag a non-versioned file or folder into a directory which is under version control.

Common Shortcuts

Some common operations have well-known Windows shortcuts, but do not appear on buttons or in menus. If you can’t work out how to do something obvious, like refreshing a view, check here.

F1

Help, of course.

F5

Refresh the current view. This is perhaps the single most useful one-key command. For example … In Explorer this will refresh the icon overlays on your working tree. In the commit dialog it will re-scan the working tree to see what may need to be committed. In the Revision Log dialog it will contact the repository again to check for more recent changes.

Ctrl-A

Select all. This can be used if you get an error message and want to copy and paste into an email. Use Ctrl-A to select the error message and then …

Ctrl-C

… Copy the selected text.

Ctrl-F

Search

Authentication

SSH (URLs look like git@example.com)

TortoiseGitPlink is recommended as SSH client because it better integrates with Windows. By default TortoiseGitPlink does not store passwords, you can use the PuTTY authentication agent for caching the password (done automatically if a PuTTY key is configured for a remote). For advanced tips & tricks see Appendix F, Tips and tricks for SSH/PuTTY. Note, however, that TortoiseGitPlink does not respect ~/.ssh/config which is OpenSSH specific (see PuTTY tips & tricks or configure OpenSSH as SSH client, see next paragraph). If you also want to use TortoiseGitPlink on Git Bash, create an environment variable called GIT_SSH with the path to the PuTTY plink.exe or preferably to TortoiseGitPlink.exe. This can be done by re-executing the Git for Windows installer (there you can choose which SSH client to use), on the command line by executing set GIT_SSH=PATH_TO_PLINK.EXE" (C:\Program Files\TortoiseGit\bin\TortoiseGitPlink.exe on default installations) or configure the environment variables permanently .

It is also possible to use OpenSSH (shipped with Git for Windows, Cygwin, and MSYS2). Just open TortoiseGit settings and open the Network page and enter ssh.exe as SSH client, see the section called “Network Settings” and this answer on StackOverflow . When OpenSSH is used, you can also make use of ~/.ssh/config (cf. this answer on StackOverflow ).

Maximizing Windows

Many of TortoiseGit’s dialogs have a lot of information to display, but it is often useful to maximize only the height, or only the width, rather than maximizing to fill the screen. As a convenience, there are shortcuts for this on the Maximize button. Use the middle mouse button to maximize vertically, and right mouse to maximize horizontally.

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

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

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

Если Вы работаете в Delphi, то в этой статье представлено пошаговое руководство по настройке и работе с Git непосредственно из IDE Delphi

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

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 который мы указывали при регистрации. Этот адрес можно видеть на главной странице своего профиля:

Профиль на GitHub.com

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 на ЛитРес

Описание: Рассмотрены малоосвещенные вопросы программирования в Delphi. Описаны методы интеграции VCL и API. Показаны внутренние механизмы VCL и приведены примеры вмешательства в эти механизмы. Рассмотрено использование сокетов в Delphi: различные режимы их работы, особенности для протоколов TCP и UDP и др.

купить книгу delphi на ЛитРес

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

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

AlexESD

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

AlexESD

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

Добавить комментарий

Разработка с использованием сервиса 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 в правом верхнем углу экрана:

Repository fork

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

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

Clone repository

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

Clone repository

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

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

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

Clone repository

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

Clone repository

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

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

Clone repository

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

Clone repository

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

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

Clone repository

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

Clone repository

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

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

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

Clone repository

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

Clone repository

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

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

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

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

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

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

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

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

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

Clone repository

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

Clone repository

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

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

Clone repository

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

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

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

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

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

Clone repository

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

Clone repository

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

Clone repository

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

Ref
Local:  dev
Remote: dev

Destination
Remote: origin

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

Clone repository

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

Clone repository

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

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

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

Clone repository

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

Clone repository

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

Clone repository

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

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

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

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

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

Clone repository

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

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 и добавлять комментарии к необходимым строкам:

Comment PR;

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

Approve PR

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

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

  • Description
  • Manual
  • Scheme
  • Report

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

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

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

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

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

При установке 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.

  • Torrserver matrix скачать для windows
  • Torrent windows 10 x64 repack
  • Torrent windows 10 pro oem
  • Torrent windows 10 pro english torrent
  • Torrent скачать 4pda windows 10