8-900-374-94-44
[email protected]
Slide Image
Меню

Как пользоваться tortoisegit: DVCS Git и TortoiseGit в картинках. Пособие для начинающих чайников.

Содержание

DVCS Git и TortoiseGit в картинках. Пособие для начинающих чайников.

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

Что такое 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. После того как вы будите записаны в список разработчиков проекта можно переходить к следующей фазе работы — получение исходников.

Работа со своим первым репозиорием Git

Доступ получен, исходники в Вашем распоряжении. Теперь переключаемся на работу с 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

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

Автор: Антон Григорьев

НазваниеО чем не пишут в книгах по Delphi

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

1 1 голос

Рейтинг статьи

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

GIT: Инструкция-шпаргалка для начинающих

GIT: Инструкция-шпаргалка для начинающих

Ссылка на оригинал

Время создания: 07.06.2012 23:37

Раздел: Компьютер — Программирование — Системы контроля версий (VCS) — Git

Запись: xintrea/mytetra_syncro/master/base/1339097829h0xmeapk1u/text.html на raw.github.com

Работа с Git репозиториями

Почему Git

Краткий ответ: потому что не появляются задержки от работы с системой контроля версий.

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

Авторизация в GIT производится по персональному ключу а не паролю, который кешируется на некоторое время на стороне клиента, а не запоминается навсегда в настройках клиента.

GIT позволяет легко работать с ветками, без видоизменений раскладки репозитория, и древесный просмотр изменений позволяет видеть что из какой ветки пришло.

Более подробно можно прочитать http://habrahabr.ru/blogs/Git/104198/

Общие сведения о Git

Подробно о работе с Git, что это такое можно прочитать в Git Book по адресу http://book.git-scm.com/

В классических VCS (Version Control System) (CVS, SVN), в рабочей копии хранится текущее состояние репозитория, и базовая копия текущей ревизии. На сервере хранятся все ревизии в виде изменений от предыдущей, либо в виде полных копий каждой ревизии с вычислением разницы по запросу. Все ревизии нумеруются по порядку начиная от первой.


В случае CVS хранятся изменения и нумерая по каждому файлу независимо, в случае SVN, нумеруются изменения репозитория.
Так как SVN хранит только изменения всего репозитория, «ветки» в нем реализуются через специальную организацию файлов в хранилище. Классически, это /trunk/ для последнего кода, /branch/somename/ для веток. Для создания ветки, делается копия /trunk/ в /branch/somename/, над которым уже работает разработчик.
При этом, при каждом коммите, идёт обращение к центральному репозиторию, для сохранения изменения, отрабатывают скрипты на сервере, идет непрерывная нумерация изменений, запрос истории так же требует обращения на сервер и т.д.

Git относится к классу DVCS (Distributed Version Control System). При этом рабочая копия содержит все коммиты, историю, ветки, всё необходимое для ведения разработки без обращения к какому-либо серверу. Для синхронизации изменений между разными копиями репозитория, в нужный момент делается pull чтобы скопировать изменения удалённого репозитория к себе, либо push чтобы скопировать локальные изменения в удалённый репозиторий.

В случае с Git, каждый коммит имеет уникальный ID в виде хеша, содержащий в себе все файлы, относящиеся к нему.

Каждый коммит имеет один коммит-родитель, и, возможно, коммит-источник слияния. Таким образом, коммиты представляют собой дерево наборов файлов. «Веткой» является указатель на какой-либо коммит. Таким образом, чтобы создать ветку, нужно просто дать имя какому-либо коммиту. Чтобы слить две ветки, одна из которых начинается с конца другой, можно просто передвинуть указатель второй ветки на новый коммит (это называется Fast-Forward).

Чтобы поддерживать «плоскую» основную ветку (master), используется техника ребейза веток перед слиянием, и слияение без fast-forward’а.

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

Если теперь сделать слияние этой ветки с исходной, указатель головы исходной ветки будет просто передвинут на новое место, и мы потеряем информацию о том, что вообще существовала новая ветка. Именно поэтому используется слияние без fast-forward’а. При этом, даже если новая ветка начинается с конца предыдущей, создаётся специальный merge-commit, содержащий информацию о том, что в этом месте сливается текущая ветка с дополнительной.

Подробнее о том, что такое rebase в картиках тут: http://book.git-scm.com/4_rebasing.html

Алгоритм работы над задачей

Стандартный алгоритм работы над какой-либо задачей выглядит так:

  1. Создаётся ветка, основывающаяся на последней копии master ветки. Название новой ветки содержит класс задачи, краткое описание, номер задачи в БТ. Например feature/sessions_add_datetime_filter.5503
  2. Все изменения производятся внутри этой ветки. При каждом атомарном логическом изменении (например, добавили плагин – закоммитили добавление; поправили API одной функции во всех местах – закоммитили и тп) создаётся свой коммит. Это позволяет разделять какие были изменения, упрощается чтение и проверка на ошибки процесса разработки.
  3. После того как код в ветке сделан и отлажен, все изменения закоммичены, данная ветка ребейзится относительно последнего мастера, и пушится в центральный репозиторий.
  4. Второй человек, работающий над тем же проектом, делает к себе pull центрального репозитория. Если он уже смотрел – то удаляет свою локальную копию ветки, после чего переключается на указанную ветку. Прочитывает код, проверяет его работоспособность, после чего либо отдаёт на доработку, если там обнаружены проблемы, либо делает еще раз rebase поверх мастера, и слияние ветки с мастером.
  5. После слияния с мастером, ревьюер пушит новый мастер в центральный репозиторий, удаляет у себя локальную ветку задачи, пушит в мастер удаление ветки задачи.
  6. Разработчик удаляет локальную ветку задачи после того как задача была закрыта и изменения попали в master.

Правила ведения чистых коммитов

Все коммиты, которые попадают в центральную ветку, должны следовать следующим правилам:

  1. Автором должен быть прописан разработчик – Имя, Фамилия, рабочий e-mail.
  2. Текст комментария должен содержать краткое описание изменения. Для зарубежных проектов описание обязано быть на английском языке, для проектов российского бранча приемлемо комментировать на русском.
  3. Коммит не должен содержать в себе файлы, не относящиеся к изменениям. Если ваша IDE, OS, какой-то плагин какому-либо софту использующемуся при разработке создают технические файлы, либо добавьте их в .gitignore, либо не добавляйте к коммиту, либо удаляйте перед коммитом.
  4. Коммит не должен добавлять/убирать пустые строки, менять пробелы на табы и наоборот, менять число пробелов и т. п. нигде, кроме случаев, относящихся к сути коммита. То есть при рефакторинге это нормально, но если ваш редактор поменял во всем файлые пробелы на табы или наоборот – меняйте настройки редактора или перед коммитом приводите всё к виду «как было».
  5. Стиль исходного кода и отступов должен совпадать с текстом вокруг. То есть, если всюду в файле используются табы для отступа, не следует вставлять еще один case выровненный пробелами.
  6. Минимизация конфликтов. При добавлении кода следует стараться форматировать код так, чтобы модификация его приводила к минимуму конфликтов при слиянии.

Работа под Windows

Для работы с Git под Windows самое удобное – использовать TortoiseGit. Однако следует знать, что на 2017 год есть более удобный инструмент — SmartGit.

Подготовка к работе

  1. Устанавливается putty со страницы http://www.chiark.greenend.org.uk/~sgtatham/putty/
    Лучше всего ставить полный пакет, со всеми программами. По надобятся как минимум plink, puttygen.
  2. Устанавливается msysGit из проекта http://code.google.com/p/msysgit/
    Выбрать опции при установке «Add “Git Bash here”», «Run Git from the Windows Command Prompt», «Use Windows style line endings», когда спросит – дать путь до plink.exe
  3. Устанавливается TortoiseGit из проекта http://code.google.com/p/tortoisegit/
    После установки зайти в TortoiseGit → Settings → Git → Config, убедиться что путь до msysgit задан, и что опции AutoCRLF и SafeCRLF установлены, настроены имя, фамилия, email разработчика.
  4. С помощью puttygen создаётся пара приватный+публичный ключ.
    Публичный ключ высылается админам для добавления в доступы репозиториев и серверов.
    Приватный ключ добавляется в pagent через клик правой кнопкой → add key.

Получение репозитория

В папке, где будут размещаться все рабочие проекты, жмём
Правой кнопкой→TortoiseGit→Clone, вводим адрес центрального репозитория
ssh://git@СЕРВЕР:ПОРТ/РЕПОЗИТОРИЙ.git
В поле «Load Putty Key» выбираем путь до приватного ключа.

Основные используемые функции

При работе используются либо консольные утилиты, аналогично linux, либо графический интерфейс.

  1. Обновление текущей ветки из центрального репозитория:
    В контекстном меню папки с исходниками TortoiseGit->Pull

  2. Отправка текущей ветки в центральный репозиторий:
    В контекстном меню TortoiseGit→Push
    Выбираем в Local сперва master, потом нашу текущую ветку.
    Remote заполняется при этом автоматически.
    Название remote ветки должно быть идентично local
  3. Переключение на некоторую ветку:
    В контекстном меню TortoiseGit→Switch/Checkout
    В меню Branch выбрать remotes/origin/<нужная ветка>
    [v] «Create new branch», название <нужная ветка>, [v] «Track»

  4. Создание новой ветки
    Контекстное меню→TortoiseGit→Create Branch
    В Name в Branch вводим нужное название ветки
    Чтобы ветка базировалась от текущей, в Base On выбираем HEAD
    Чтобы ветка базировалась от мастера, выбираем Branch, в списке master.
    Ставим [v] Switch to new branch чтобы сразу переключиться на ветку.

  5. Удаление веток
    Открываем меню зажав кнопку Shift → TortoiseGit → Browse Reference
    в разделе heads лежат локальные ветки, в разделе remotes\origin удалённые.
    Выбираем нужную ветку, жмём правой кнопкой → Delete Remote Branch
    Для локальной ветки, соответственно, Delete Branch.
  6. Слияние ветки с текущей
    Контекстное меню → TortoiseGit → Merge
    выбираем Branch который нужно слить с текущей веткой
    ставим обязательно галочку «No fast forward», Merge message не трогаем.
  7. Просмотр и сохранение изменений
    Файлы с изменениями помечены красными восклицательными знаками.
    Чтобы посмотреть общую картину изменений,
    Меню→Git Commit -> “ветка”
    Внизу список изменений в репозитории, обязательно нажимать галочку «View patch» и проверять изменения на предмет соответствия Правилам ведения чистых коммитов.

Стандартные процедуры работы

  1. «Начало работы над задачей»
    Выполняется перед началом работы над задачей. Дерево должно быть без изменений.
    Меню → TortoiseGit → Switch/Checkout,
    Branch: master
    Меню → TortoiseGit → Pull
    Меню → TortoiseGit → Create Branch
    Name Branch: название новой ветки
    Base On: HEAD (master)
    [x] Switch to new branch
  2. «Коммит очередного кусочка работы»
    Выполняется после выполнения некого изменения, суть которого целостная.
    Меню → Git commit -> “имя ветки”
    Отметить файлы, только нужные для данного конкретного коммита
    Обязательно щелкнуть на «View Patch», и убедиться
    в соответствии правилам ведения чистых коммита
    В message ввести описание изменения, соответствующее правилам
  3. «Отправка ветки на центральный репозиторий»
    Выполняется после завершения работы, либо в конце каждого дня (чтобы был бакап на сервере), либо если нужно какие-то изменения показать коллеге.
    Меню → TortoiseGit → Push
    Выбираем в Local сперва master, потом нашу текущую ветку.
    Remote заполняется при этом автоматически.
    Название remote ветки должно быть идентично local
    Не следует делать push после каждого коммита, так как это потребует доступа до удалённого сервера, и, соответственно, времени, потраченного впустую.
  4. «Ребейз относительно мастера»
    Выполняется перед заливкой на сервер законченной задачи, когда все изменения уже закоммичены.
    Меню → Git Sync
    Local branch: master
    Remote branch: master
    Правая стрелочка вниз у первой кнопки (Pull по умолчанию), Fetch
    Меню → TortoiseGit → *Rebase
    Branch: текущая ветка
    UpStream: master
    Если будут конфликты – разобраться с ними через вкладку «Conflict File»
    На выбор, правой кнопкой файла, утилиты
    Edit Conflicts – позволяет по каждому расхождению выбрать
    использовать версию какую блока
    Resolve Conflicts Using
    theirs – использовать версию мастера
    mine – использовать версию текущей ветки
    Open – открыть в редакторе, и исправить вручную
    После исправления сделать Resolve
    После исправления всех конфликтов нажать Commit
    После ребейза нажать Done
  5. «Кратковременное сохранение состояния изменений»
    Выполняется, если требуется временно приостановить работу над текущей веткой на короткое время (например, на ревью, или чтобы сделать какую-либо двухминутную задачу).
    Меню → TortoiseGit → Stash Save
    После этого дерево чисто, можно переключиться на другую ветку/мастер и так далее, поработать, после чего восстановить состояние, если переключиться обратно на рабочую ветку, и сделать
    Меню → TortoiseGit → Stash Pop
    Тем самым восстановив состояние изменения.
  6. «Длительное сохранение состояния изменений»
    Выполняется в конце рабочих суток, чтобы даже частичные изменения были забакаплены; либо при необходимости срочно переключиться на решение другой задачи, которая может занять значительно больше 5-10 минут.
    Меню → Git Commit -> “ветка”
    Отмечаем все-все изменения (Select/Deselect All)
    В текст сообщения пишем «Partial commit»
    Позже, для возврата к тому же состоянию как было до, переключаемся на рабочую ветку, и делаем
    Меню → TortoiseGit → Show Log
    Выделяем коммит, который идет в дереве сразу перед «Partial commit»
    Правой кнопкой → Reset <ветка> to this
    Reset type: Mixed
  7. «Ревью ветки»
    Выполняется на чистом дереве, временно сохраните изменения согласно пункта 5, если требуется.
    Меню → TortoiseGit → Switch/Checkout
    Branch: master
    Меню → TortoiseGit → Pull
    Меню → TortoiseGit → Switch/Checkout
    Branch: remotes/origin/нужнаяветка
    [x] Create new branch: нужнаяветка
    [x] Force
    [x] Track
    [x] Override branch if exists
    Меню → TortoiseGit → *Rebase
    Branch: нужнаяветка
    UpStream: master
    Ветка ветка должна быть «up to date» или заребейзится без конфликтов.
    == Анализируем изменения просмотром лога изменений через
    Меню → TortoiseGit → Show log
    и смотрим изменения от master до последнего
    == Смотрим общее изменение относительно мастера
    Меню → TortoiseGit → Diff with previous version
    Version 1: HEAD
    Version 2: master
    == если всё хорошо, делаем
    Меню → TortoiseGit → Switch/Checkout
    Branch: master
    Меню → TortoiseGit → Merge
    From: нужнаяветка
    [x] No fast forward
    Сообщение не редактируем.
    Меню → TortoiseGit → Push
    И удаляем ветки:
    Shift + Меню → TortoiseGit → Browser Reference
    в дереве слева Refs => heads => находим ветку, правой кнопкой, Delete branch
    в дереве слева remotes => origin => находим ветку, правой кнопкой,
    Delete remote branch

Работа под Linux

Подготовка к работе

  1. Устанавливаются системные пакеты ssh-client и git
  2. Создаётся приватный ключ:

    ssh-keygen -t dsa -C «Ivan Petrov <work@mail>»

  3. Настраивается ФИО и Емейл автора:

    git config —global user. name «Ivan Petrov»
    git config —global user.email work@mail»

  4. Админу отсылается файл ~/.ssh/id_dsa.pub для прописывания доступов до репозиториев и серверов.

Получение репозитория

Переходим в директорию для работы, и запускаем

git clone ssh://git@СЕРВЕР:ПОРТ/РЕПОЗИТОРИЙ.git

Основные используемые функции

  1. Обновление текущей ветки из центрального репозитория:

    git pull

  2. Отправка текущей ветки в центральный репозиторий:

    git push origin branchname

  3. Переключение на некоторую ветку:

    git checkout branchname

    При переключении на ветку, которой еще нет в локальном репозитории, будет создана локальная ветка, связанная с удалённой.

  4. Создание новой ветки, базирующейся на текущей

    git checkout -b branchname

  5. Удаление веток

    git branch -d branchname == удаление локальной уже слитой ветки
    git branch -D branchname == принудительное удаление локальной ветки
    git push origin :branchname == удаление ветки с центрального репозитория

  6. Слияние ветки с текущей

    git merge —no-ff branchname

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

    git status

  8. Просмотреть текущие изменения:

    git diff

  9. Сохранение текущих изменений:

    git add именафайлов == добавить измененные/созданные файлы/директории
    git rm именафайлов == добавить удаление файла/директории
    git commit == сохранить добавленные изменения. Откроется редактор, чтобы ввести комментарий к коммиту
    git commit -a == сохранить все добавленные изменения и все измененные файлы. Позволяет сохранять все изменения, если файлы не добавлялись.

Стандартные процедуры работы

  1. «Начало работы над задачей».
    Выполняется перед началом работы над задачей. Дерево должно быть без изменений.

    git checkout master
    git pull
    git checkout -b branchname

  2. «Коммит очередного кусочка работы».
    Выполняется после выполнения некого изменения, суть которого целостная.

    # проверяем, какие файлы изменились к текущему моменту
    # удаляем если что-то попало совсем лишее
    git status

    # смотрим текст изменений, на предмет соответствия
    # правилам ведения чистых коммитов. удаляем, если какой-либо мусор попал
    git diff

    # если какие-либо файлы не должны попасть в коммит (например,
    # относятся к другому атомарному изменению.)
    # то помечаем только те файлы, изменения которых нужно сохранить
    git add …
    git rm …

    # сохраняем. -m можно опустить, тогда комментарий через редактор
    git commit -m «Some commit message»

    # если все на текущий момент созданные изменения нужно сохранить, то
    # через git add добавляем новые файлы, а всё остальное сохраняем через
    git commit -a -m «Some commit message»

  3. «Отправка ветки на центральный репозиторий»
    Выполняется после завершения работы, либо в конце каждого дня (чтобы был бакап на сервере), либо если нужно какие-то изменения показать коллеге.

    git push origin branchname

    Не следует делать push после каждого коммита, так как это потребует доступа до удалённого сервера, и, соответственно, времени, потраченного впустую.

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

    git checkout master
    git pull
    git checkout branchname
    git rebase master

    При возникновении конфликтов, нужно:

    (*)
    git status == проверить файлы, для которых есть неразрешенные конфликты.

    Редактируем первый файл с конфликтом: находим в нем «<<<<<». То, что между <<<<< и ==== – содержит копию текста из master ветки, то что между ===== и >>>>> содержит текст из нашей ветки. Нужно на этом месте оставить одну единую версию, содержащую общий код и мастера и нашей ветки

    git add измененный_файл

    перейти на (*)

    После исправления конфликтов во всех файлах, запускаем

    git rebase —continue

    Если конфликты несовместимые с дальнейшим продолжением ребейза

    git rebase —abort == прерывает ребейз и возвращает ветку в исходное

    состояние (до начала ребейза)

    После ребейза обновляем состояние ветки в центральном репозитории

    git push origin branchname -f

  5. «Кратковременное сохранение состояния изменений».
    Выполняется, если требуется временно приостановить работу над текущей веткой на короткое время (например, на ревью, или чтобы сделать какую-либо двухминутную задачу).
    git reset HEAD .

    Важно! После такой процедуры сохранения/восстановления, при следующем

    git push origin branchname

    Будет выдано предупреждение о непоследовательном изменении. Чтобы принудительно отправить изменения, следует добавить опцию -f.

    git push -f origin branchname

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

  6. «Ревью ветки».
    Выполняется на чистом дереве, временно сохраните изменения согласно пункта 5, если требуется.

    git checkout master
    git pull
    git branch -D branchname
    git checkout branchname
    git rebase master == ветка обязана наложиться без конфликтов
    git diff master == изучаем разницу от мастера или общим диффом, или
    git log master..HEAD == смотрим какие коммиты были между мастером и текущей веткой

    Если всё хорошо, делаем:

    git checkout master
    git merge —no-ff branchname
    git push origin master
    git push origin :branchname
    git branch -d branchname

Так же в этом разделе:

  • Бесплатные сервиса размещения репозитариев Git
  • Git workflow — Теория
  • Git workflow — Краткое введение по основным инструкциям
  • Git Wizardry
  • Про Git на пальцах (для переходящих с SVN)
  • Git на двоих
  • Ежедневный Git
  • Удачная модель ветвления для Git
  • Синхронизация через GIT
  • Git stash — работа с «карманом» в Git
  • Как посмотреть настройки репозитария Git и как их изменить
  • GIT: Инструкция-шпаргалка для начинающих
  • Как перенести локальный GIT-репозитарий на сервер вместе со всей историей
  • git reset — возврат к определенному коммиту, откат изменений, «жесткий» или «мягкий»
  • git revert — отмена изменений, произведенных в прошлом отдельным коммитом
  • Git — работа с ветками
  • Git: Путь Github. Цикл разработки — Простое объяснение
  • Машина времени в GIT
  • Git Rebase: руководство по использованию
  • Git: просмотр лога (истории) в консоли в виде дерева
  • Git: понимание команды git merge
  • Git: Опции слияния для команд merge и pull — определение стратегии слияния
  • Git: как переключиться на нужный коммит
  • Git: как смержить изменения из experimental в master
  • Git: как посмотреть изменения, внесенные определенным коммитом
  • Git: как посмотреть историю изменения одного файла
  • Git: как вернуть один файл в состояние, которое было в определенном коммите
  • git log — особенности данной команды при навигации по истории через git checkout
  • Git: Как исправить HEAD detached from
  • Git: что делать в состоянии detached head
  • Работа в команде с использованием Git на примере проекта в среде Blender 3D
  • Git: Как внести изменения в последний коммит
  • Как в Git создать новую ветку в условиях, когда что-то уже было изменено после последнего коммита
  • Как в Git залить новую локальную ветку в удаленный репозитарий
  • Git: Как подключить новую ветку с удаленного сервера
  • Git: Как узнать текущую ветку
  • Git: В чем разница между Fetch и Pull?
  • GIT: Как исправить ошибочный комментарий к коммиту или файлы в коммите
  • Как настроить git на использование proxy-сервера
  • Использование Git через HTTP-proxy
  • Настройка работы Git через Proxy-сервер
  • Git через proxy
  • Использование git за прокси с аутентификацией
  • Что делать, если в России заблокирован GitHub — быстрое решение
  • Как в Git смержить изменения до конкретного коммита?
  • Самый удобный визуальный клиент Git под основные платформы — SmartGit
  • Основы системы управления версиями Git для новичков на примере SmartGit
  • Как сделать подключение к репозитарию Git через Socks Proxy в условиях отсутствия DNS
  • Как сделать подключение к репозитарию Git через проксирующее SSH соединение
  • Как работать с незавершенными изменениями в коде? Как их коммитить в Git?
  • Как в Git посмотреть незакоммиченные изменения в текстах исходников?
  • Как поместить на GitHub уже существующий репозитарий
  • Что происходит при откате изменений через git reset —soft
  • Не бойся хардресета! Он твой друг и помощник. (Как пользоваться git reset)
  • Как пометить определенный коммит тегом версии
  • Как в Git удалить файлы из индекса, не удаляя их в рабочей директории
  • Как настроить GIT, чтобы при конфликте слияния он прописывал в файл не только различия, но и «базу» этих различий
  • Git: Разрешение конфликтов объединений
  • Git: Извлечение старой версии файла
  • Git stash: временный отказ от проделанной работы
  • Git: проверка состояния репозитария, поддержание репозитария в рабочем состоянии
  • Как в Git отменить локальные изменения и получить новое состояние из удаленного репозитария
  • Как искать изменения в нужных файлах с помощью интерфейса gitk?
  • Как выбрать одну из версий бинарного файла при возникновнии конфликта слияния?
  • Как в Git посмотреть старый коммит, а потом вернуться обатно к самому последнему коммиту
  • Получение хеша последнего коммита и его даты в Git (для версионирования)
  • Памятка по неочевидным деталям использования Git
  • Как синхронизировать форк на Github с основным репозитарием через веб-интерфейс
  • Как пользоваться GitHUb: форки, ветки, запросы на добавление кода
  • Как отменить (сбросить) еще не закоммиченные изменения в Git
  • Первоначальная настройка имени пользователя и Email в Git-проекте
  • Можно ли принимать изменения через git pull если не закоммичены изменения рабочей директории
  • Как посмотреть какие команды генерирует git gui
  • Как удалить файл в Git-репозитарии с изменением истории

MyTetra Share v. 0.58

Глава 2. Руководство по ежедневному использованию Tortoisegit — Tortoisegit — Документация — Tortoisegit — интерфейс оболочки Windows для GIT

Содержание

Начало работы
ICON Oald
Context Menus
и Drop
70007 Ярлыки
Аутентификация
Развернуть Windows
Создать репозиторий
Клонировать репозиторий
Извлечение рабочего дерева (переключение для фиксации)
, совершив ваши изменения в репозитории
Диалог Commit
Списки изменений
За исключением элементов из списка комплектов
. Сделайте только части файлов
Сообщения для посвящения
Прогресс
Наложение значков
Свойства проводника
Статус
Просмотр различий
Извлечение и получение изменений
Push
Branch
Destination
Options
Sync
Branch
Destination
Options
Daemon
Browse All Refs
Submodules
Change Lists
Log Диалоговое окно
Вызов диалогового окна журнала изменений
Действия в журнале изменений
Граф изменений
Сообщения фиксации и индикаторы ветвей/тегов
Получение дополнительной информации
Сообщения журнала фильтрации
Навигация
Статистическая информация
Обновления View
РЕСПРАВЛЕНИЯ Графики
Граф. Журнал
Браузер репозитория
Просмотр различий
Различия файлов
Параметры конца строки и пробела
Сравнение версии
Дифференциальные подмодулы с использованием диалога подмодулей Diff
Дифференциальные изображения с использованием Tortoisegitidiff
Внешние инструменты Diff/Merge
Добавление новых файлов
Копение/перемещение файлов и папки
Agistoring
.
Поиск по образцу в списках игнорирования
Удаление, перемещение и переименование
Удаление файлов и папок
Перемещающие файлы и папки
Изменение случая в имене файла
, работая с конфликтами имени файла
Удаление безотверженных файлов
undo изменение
Создание ветки или тега
Слияние
Выбор вишни
Перебазирование
Разрешение конфликтов
Специальные случаи конфликта
Создание и применение исправлений и запросов на вытяжение
Создание патча сериала
Отправка исправлений по почте
Применение одного файла
. Применение патча
.
Кто какую строку изменил?
Авторство файлов
Экспорт рабочего дерева Git
Интеграция с системами отслеживания ошибок / системами отслеживания проблем
Добавление номеров выпусков к сообщениям журнала
Git
Скрипты хуков на стороне клиента
Настройки TortoiseGitBlame
Настройки TortoiseGitUDiff
Дополнительные настройки
Exporting TortoiseGit Settings
Working with worktrees
Creating a worktree
git svn dcommit
Git LFS Locking
Setting up the repository
Locking a file
Unlocking a file
Показать диалоговое окно блокировки
Последний шаг

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

Подсказки, где найти дополнительную информацию об управлении версиями с помощью Git, см. в разделе «Руководство по чтению».

Этот документ также находится в стадии разработки, как и TortoiseGit и Git. Если вы обнаружите какие-либо ошибки, пожалуйста, сообщите о них в список рассылки, чтобы мы могли обновить документацию. Некоторые снимки экрана в Руководстве по ежедневному использованию (DUG) могут не отражать текущее состояние программного обеспечения. Пожалуйста, простите нас. Мы работаем над TortoiseGit в свободное время.

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

  • Вы уже должны были установить TortoiseGit.

  • Вы должны быть знакомы с системами контроля версий.

  • Вы должны знать основы Git.

  • У вас должен быть настроен сервер и/или доступ к репозиторию Git.

Наложения значков

Рисунок 2.1. Проводник с наложением значков


Одной из наиболее заметных функций TortoiseGit являются наложения значков, которые появляются на файлах в вашем рабочем дереве. Они сразу показывают, какие из ваших файлов были изменены. Обратитесь к разделу «Наложения значков», чтобы узнать, что представляют собой различные наложения.

Контекстные меню

Рисунок 2.2. Контекстное меню для каталога под контролем версий


Все команды TortoiseGit вызываются из контекстного меню проводника Windows. Большинство из них видны сразу, когда вы щелкаете правой кнопкой мыши файл или папку. Доступные команды зависят от того, находится ли файл, папка или ее родительская папка под контролем версий или нет. Вы также можете увидеть меню TortoiseGit как часть файлового меню Проводника.

Совет

Некоторые редко используемые команды доступны только в расширенном контекстном меню. Чтобы вызвать расширенное контекстное меню, удерживайте нажатой клавишу Shift при щелчке правой кнопкой мыши.

В некоторых случаях вы можете увидеть несколько записей TortoiseGit. Это не ошибка!

Рисунок 2.3. Меню файла проводника для ярлыка в версионной папке


Этот пример относится к неверсионному ярлыку в версионной папке, а в меню файлов проводника есть две записи для TortoiseGit. Один для самого ярлыка, а второй для объекта, на который указывает ярлык. Чтобы помочь вам различать их, значки имеют индикатор в правом нижнем углу, показывающий, предназначен ли пункт меню для файла, папки, ярлыка или для нескольких выбранных элементов.

Перетаскивание

Рисунок 2.4. Меню перетаскивания правой кнопкой мыши для каталога с контролем версий


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

Общие ярлыки

Некоторые общие операции имеют хорошо известные ярлыки Windows, но не отображаются на кнопках или в меню. Если вы не можете понять, как сделать что-то очевидное, например обновить представление, проверьте здесь.

F1

Помощь, конечно.

F5

Обновить текущий вид. Это, пожалуй, самая полезная одноклавишная команда. Например… В Проводнике это обновит наложения значков на вашем рабочем дереве. В диалоговом окне фиксации он повторно просканирует рабочее дерево, чтобы увидеть, что может потребоваться зафиксировать. В диалоговом окне журнала изменений он снова свяжется с репозиторием, чтобы проверить наличие более свежих изменений.

Ctrl-A

Выбрать все. Это можно использовать, если вы получили сообщение об ошибке и хотите скопировать и вставить его в электронное письмо. Используйте Ctrl-A, чтобы выбрать сообщение об ошибке, а затем …

Ctrl-C

. .. Скопируйте выделенный текст.

CTRL-F

Поиск

Аутентификация

SSH (URL-адреса выглядит как [email protected])

Tortoisegitplink рекомендуется, потому что SSH Client. Потому что SSH-Client. По умолчанию TortoiseGitPlink не хранит пароли, вы можете использовать агент аутентификации PuTTY для кэширования пароля (выполняется автоматически, если ключ PuTTY настроен для удаленного доступа). Дополнительные советы и рекомендации см. в Приложении F, 9.0433 Советы и рекомендации по SSH/PuTTY . Обратите внимание, однако, что TortoiseGitPlink не учитывает ~/.ssh/config , который специфичен для OpenSSH (см. советы и рекомендации по PuTTY или настройте OpenSSH в качестве клиента SSH, см. следующий абзац). Если вы также хотите использовать TortoiseGitPlink в Git Bash, создайте переменную среды с именем GIT_SSH с путем к PuTTY plink.exe или, что предпочтительнее, к TortoiseGitPlink.exe. Это можно сделать, повторно запустив установщик Git для Windows (там вы можете выбрать, какой SSH-клиент использовать), в командной строке, выполнив установите GIT_SSH=PATH_TO_PLINK.EXE" ( C:\Program Files\TortoiseGit\bin\TortoiseGitPlink.exe при установке по умолчанию) или настройте переменные среды на постоянной основе .

Также можно использовать OpenSSH (поставляется с Git для Windows, Cygwin и MSYS2). Просто откройте настройки TortoiseGit, откройте страницу «Сеть» и введите ssh.exe в качестве клиента SSH, см. раздел «Настройки сети» и этот ответ на StackOverflow . Когда используется OpenSSH , вы также можете использовать ~/.ssh/config (см. этот ответ на StackOverflow ).

HTTP/HTTPS (URL-адреса начинаются с https:// или http://)

По умолчанию Git не сохраняет и не кэширует учетные данные. Однако вы можете настроить помощник по учетным данным (рекомендуется, см. также раздел «gitcredentials(7)») или вручную использовать %HOME%/_netrc .

Если вы настроили хранилище учетных данных и хотите очистить некоторые сохраненные учетные данные, см. этот ответ на StackOverflow .

Развертывание Windows

Многие диалоговые окна TortoiseGit содержат много информации для отображения, но часто бывает полезно максимизировать только высоту или только ширину, а не максимизировать до заполнения экрана. Для удобства на кнопке «Развернуть» есть ярлыки. Используйте среднюю кнопку мыши для увеличения по вертикали и правую кнопку мыши для увеличения по горизонтали.

© TortoiseGit и участники; Патчи, предложения и комментарии к этому руководству приветствуются на GitLab. Выходные данные/Политика конфиденциальности

Фиксация ваших изменений в репозитории — TortoiseGit — Документация — TortoiseGit — Интерфейс оболочки Windows для Git

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

Диалоговое окно фиксации

Если конфликтов нет, вы готовы зафиксировать изменения. Выберите любой файл и/или папку, которые вы хотите зафиксировать, затем TortoiseGit → Зафиксировать….

Рисунок 2.9. Диалоговое окно фиксации

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

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

Много неверсионных файлов в диалоговом окне фиксации

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

Прочтите раздел «Игнорирование файлов и каталогов» для получения дополнительной информации.

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

Вы можете выбрать или отменить выбор элементов, установив флажок слева от элемента.

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

Цветовой код различных предметов описан в разделе «Статус».

Обратите внимание, что в диалоговом окне фиксации всегда отображаются промежуточные файлы, даже если они были запущены в другой папке (это сделано для того, чтобы не забыть их зафиксировать, например, в случае слияния). Также в левом нижнем углу есть галочка Показать весь проект. Используйте это, чтобы переопределить фильтр файлов/папок и показать все измененные файлы для всего репозитория. Этот параметр запоминается для репозитория, даже если вы запустили диалог фиксации для одного файла.

Перетаскивание

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

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

Коммиты являются только локальными

Обратите внимание, что все коммиты являются только локальными и влияют только на ваше локальное рабочее дерево. Чтобы поделиться ими с другими, вам нужно отправить их в удаленный репозиторий. Дополнительную информацию см. в разделе «Push» и в разделе «Sync».

Списки изменений

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

Исключение элементов из списка фиксации

Иногда у вас есть версии файлов, которые часто изменяются, но вы действительно не хотите их фиксировать. Иногда это указывает на ошибку в процессе сборки — почему эти файлы имеют версии? следует ли использовать файлы шаблонов? Но иногда это неизбежно. Классическая причина заключается в том, что ваша среда IDE изменяет отметку времени в файле проекта каждый раз при сборке. Файл проекта должен иметь версию, так как он включает все параметры сборки, но его не нужно фиксировать только потому, что отметка времени изменилась.

Чтобы помочь в подобных неудобных случаях, для файлов Git существует флаг skip-worktree — тогда файлы рассматриваются как неизмененные, и Git также отказывается объединять файлы при слиянии/вытягивании (см. раздел «ПРОПУСТИТЬ -РАБОЧИЙ БИТ»). В качестве еще одного способа справиться с подобными случаями мы зарезервировали список изменений под названием ignore-on-commit . Любой файл, добавленный в этот список изменений, будет автоматически снят с отметки в диалоговом окне фиксации. Вы по-прежнему можете фиксировать изменения, но вам нужно выбрать их вручную в диалоговом окне фиксации.

Зафиксировать только части файлов

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

Щелкните файл правой кнопкой мыши и выберите Контекстное меню → Восстановить после фиксации. Это создаст копию файла как есть. Затем вы можете отредактировать файл, например. в TortoiseGitMerge и отмените все изменения, которые вы не хотите фиксировать. После сохранения этих изменений вы можете зафиксировать файл.

Использование TortoiseGitMerge

Если вы используете TortoiseGitMerge для редактирования файла, вы можете либо отредактировать изменения, как вы привыкли, либо отметить все изменения, которые вы хотите включить. щелкните правой кнопкой мыши измененный блок и используйте контекстное меню → Отметить этот блок, чтобы включить это изменение. Наконец, щелкните правой кнопкой мыши и используйте контекстное меню → Использовать левый файл, кроме отмеченных блоков, которые инвертируют ваши изменения (неотмеченные блоки), которые вы не хотите, чтобы они отображались в текущей фиксации.

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

Сообщения журнала фиксации

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

К сообщениям журнала можно применить простое форматирование, используя соглашение, аналогичное тому, которое используется в электронных письмах. Чтобы применить стиль к 9 для курсива.

Рисунок 2.10. Диалоговое окно фиксации Проверка орфографии


TortoiseGit включает в себя проверку орфографии, которая поможет вам правильно отображать сообщения журнала (см. раздел «Проверка орфографии»). Это подчеркнет любые слова с ошибками. Используйте контекстное меню для доступа к предлагаемым исправлениям. Конечно, он не знает каждого технического термина , который вы знаете, поэтому правильно написанные слова иногда будут отображаться как ошибки. Но не волнуйтесь. Вы можете просто добавить их в свой личный словарь с помощью контекстного меню.

Окно сообщения журнала также включает в себя имя файла и функцию автоматического завершения. При этом используются регулярные выражения для извлечения имен классов и функций из (текстовых) файлов, которые вы фиксируете, а также самих имен файлов. Если слово, которое вы вводите, соответствует чему-либо в списке (после того, как вы ввели не менее 3 символов или нажали Ctrl+Space ), появится раскрывающийся список, позволяющий выбрать полное имя. Регулярные выражения, поставляемые с TortoiseGit, хранятся в установке TortoiseGit 9.Папка 0435 бин . Вы также можете определить свои собственные регулярные выражения и сохранить их в %APPDATA%\TortoiseGit\autolist.txt . Конечно, ваш личный автосписок не будет перезаписан при обновлении установки TortoiseGit. Если вы не знакомы с регулярными выражениями, ознакомьтесь с введением по адресу https://en. wikipedia.org/wiki/Regular_expression , а также с онлайн-документацией и учебным пособием по адресу https://www.regular-expressions.info. / .

Получение правильного регулярного выражения может быть сложной задачей, поэтому, чтобы помочь вам выбрать подходящее выражение, существует тестовый диалог, который позволяет вам ввести выражение, а затем ввести имена файлов для его проверки. Запустите его из командной строки с помощью команды TortoiseGitProc.exe /command:autotexttest .

Вы можете повторно использовать ранее введенные сообщения журнала. Просто используйте команду Контекстное меню → Вставить последние сообщения, чтобы просмотреть список последних нескольких сообщений, которые вы ввели для этого рабочего дерева. Количество сохраняемых сообщений можно настроить в диалоговом окне настроек TortoiseGit.

Окно сообщения журнала также содержит средство фрагмента сообщения фиксации. Эти фрагменты отображаются в раскрывающемся списке автозаполнения, когда вы вводите ярлык фрагмента и выбираете фрагмент в раскрывающемся списке автозаполнения, а затем вставляете полный текст фрагмента. Фрагменты, поставляемые с TortoiseGit, хранятся в установке TortoiseGit 9.Папка 0435 бин . Вы также можете определить свои собственные фрагменты и сохранить их в %APPDATA%\TortoiseGit\snippet.txt . # — символ комментария. Используйте управляющие последовательности \t , \r , \n и \\ .

Вы можете добавить свое имя и адрес электронной почты в конец сообщения журнала, нажав кнопку «Добавить подпись».

Вы можете очистить все сохраненные сообщения фиксации на странице «Сохраненные данные» настроек TortoiseGit или очистить отдельные сообщения в диалоговом окне «Последние сообщения», используя кнопку Удалить ключ .

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

Другой способ вставить пути в сообщение журнала — просто перетащить файлы из списка файлов в поле редактирования.

Использование клавиатуры

Вы можете получить доступ к кнопке OK с клавиатуры, нажав Ctrl+return .

Интеграция со средствами отслеживания ошибок

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

Отрегулируйте размер текстового поля сообщения

Наведите указатель мыши на зазор между групповым полем «Сообщение» и групповым полем «Внесенные изменения», затем перетащите разделитель.

Зафиксировать новую ветку

Если вы хотите зафиксировать новую ветку (на основе текущей ветки), вы можете установить флажок новой ветки и ввести имя ветки в отображаемом текстовом поле.

Подтвердить несколько раз подряд и напрямую отправить изменения

Главная кнопка Подтвердить имеет раскрывающееся меню. Есть варианты ReCommit и Commit & push. Опция ReCommit фиксирует ваши изменения и оставляет диалоговое окно Commit открытым, так что вы можете продолжить фиксацию. Последний вариант «Зафиксировать и отправить» зафиксирует ваши изменения и немедленно отправит их. Если для текущей активной ветви не настроена ветка удаленного отслеживания, открывается диалоговое окно push (см. раздел «Push»).

Ход выполнения фиксации

После нажатия кнопки «Подтвердить» появляется диалоговое окно, отображающее ход выполнения фиксации.

Рисунок 2.11. Диалоговое окно «Ход выполнения», показывающее выполнение фиксации

В левом нижнем углу есть кнопка меню, которая обеспечивает ярлыки для дальнейших шагов, таких как «Повторная фиксация» (сбрасывает диалоговое окно фиксации и позволяет продолжить фиксацию) или «Отправить», чтобы нажать коммит в удаленный репозиторий.

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *