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

Как пользоваться tortoisegit – GIT: Инструкция-шпаргалка для начинающих

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

Работа с 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 stash save

    После этого дерево чисто, можно переключиться на другую ветку/мастер и так далее, поработать, после чего восстановить состояние с помощью

    git checkout originalbranch
    git stash pop

    Тем самым восстановив состояние изменения.

  6. «Длительное сохранение состояния изменений».
    Выполняется в конце рабочих суток, чтобы даже частичные изменения были забакаплены; либо при необходимости срочно переключиться на решение другой задачи, которая может занять значительно больше 5-10 минут.

    git add .
    git commit -m «Partial commit»
    git push origin branchname

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

    git checkout branchname
    git reset —soft HEAD^
    git reset HEAD .

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

    git push origin branchname

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

    git push -f origin branchname

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

  7. «Ревью ветки».
    Выполняется на чистом дереве, временно сохраните изменения согласно пункта 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

webhamster.ru

Как начать работать с GitHub: быстрый старт / Habr

Распределенные системы контроля версий (DVCS) постепенно замещают собой централизованные. Если вы еще не используете одну из них — самое время попробовать.

В статье я постараюсь показать, как можно быстро начать экспериментировать с git, используя сайт github.com.

В статье не будут рассмотрены различия между разными DVCS. Также не будет детально рассматриваться работа с git, по этой теме есть множество хороших источников, которые я приведу в конце статьи.

Итак, сайт github.com позиционируется как веб-сервис хостинга проектов с использованием системы контроля версий git, а также как социальная сеть для разработчиков. Пользователи могут создавать неограниченное число репозиториев, для каждого из которых предоставляется wiki, система issue tracking-а, есть возможность проводить code review и многое другое. GitHub на данный момент является самым популярным сервисом такого рода, обогнав Sourceforge и Google Code.

Для open-souce проектов использование сайта бесплатно. При необходимости иметь приватные репозитории, есть возможность перейти на платный тарифный план:

Начнем с регистрации. Идем по ссылке github.com/signup/free и вводим свои данные.
После регистрации мы попадаем на Dashboard нашего аккаунта:

Сейчас у нас нет ни одного репозитория, и мы можем либо создать новый репозиторий, либо ответвиться (fork) от уже существующего чужого репозитория и вести собственную ветку разработки. Затем, при желании, свои изменения можно предложить автору исходного репозитория (Pull request).

Но для начала установим git и настроим его для работы с сайтом.

Если вы работаете в Windows, качаем и устанавливаем msysgit. Это консольная версия git для Windows (далее расказ будет вестись на примере этой ОС).
Инструкция для MacOS X (eng)
Инструкция для Linux (eng)
Проблем возникнуть не должно, просто везде жмем Next. После установки выбираем в контекстном меню Проводника Git Bash:

или через Git Bash.lnk в папке с установленой программой:

Прописываем в консоли свои данные и настройки переносов строк:
git config --global user.name "ваше имя"
git config --global user.email "ваша почта"
git config --global core.autocrlf true
git config --global core.safecrlf true

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

Для тех, кто предпочитает gui — для Windows существует несколько таких инструментов для работы с git. Два основных — это SmartGit (кроссплатформенный) и TortoiseGit. Оба неплохие, и какой использовать — дело вкуса. Я опишу работу с TortoiseGit.
Для маков выбор giu тоже имеется.

  • официальный клиент от GitHub — на мой взгляд пока достаточно сыроват.
  • GitX — лично мне не приглянулся
  • GitBox — наиболее следует mac-way, очень рекомендую попробовать именно его

Качаем по ссылке code.google.com/p/tortoisegit/downloads/list. При установке везде жмем Next.

Теперь возвращаемся к github и создадим новый репозиторий. Находясь на Dashboard, жмем New Repository (https://github.com/repositories/new), вводим данные и жмем Create Repository.

GitHub позволяет работать с репозиториями тремя способами: SSH, HTTP и Git Read-Only, соответственно предоставляя ссылки трех видов для нашего репозитория:
1. [email protected]:habrauser/Hello-world.git
2. [email protected]/habrauser/Hello-world.git
3. git://github.com/habrauser/Hello-world.git

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

Если же мы захотим внести изменения в репозиторий на github, нужно пользоваться HTTP или SSH.
Работа по http никаких трудностей не вызывает, в нужный момент просто используется пароль учетной записи на github.

Чтобы использовать SSH, нам нужно создать специальную пару ключей: публичный и приватный. Публичный будет размещен в настройках аккаунта на github, а приватный сохранен на локальной машине.

Для генерации ключей, можно воспользоваться инструментом ssh-keygen, который идет в комплекте с git (описание этого способа можно почитать тут). Мы же будем использовать PuTTY (а точнее небольшую программку puttygen, входящую в его состав). PuTTY — это такой клиент для удаленного доступа, в том числе и с использованием SSH.

Качаем последнюю версию с официального сайта (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html). Кстати, puttygen более старой версии (2007 год) идет в составе TortoiseGit.

После установки PuTTY, запускаем puttygen из папки с установленной программой:

Жмем Generate, двигаем некоторое время курсором мыши, для получения случайных данных, необходимых алгоритму

Вводим пароль, защищающий наш приватный ключ в поле Key passphrase, вводим подтверждение, жмем Save private key, сохраняем.

Далее копируем публичный ключ в формате OpenSSH из текстовой области «Public key for pasting…» и идем в настройки нашего аккаунта на github (Account Settings) в раздел SSH Public Keys:

жмем Add another public Key, вставляем наш публичный ключ:

нажимаем Add key. Все, теперь мы готовы работать с github по ssh. Попробуем забрать наш пустой рерозиторий на локальную машину с использованием TortioшseGit. В контекстном меню проводника выбираем Git Clone…

В поле Url вставляем SSH-адрес нашего репозитория, в поле Load Putty Key указываем путь к нашему приватному ключу, жмем OK.

Pageant запросит у наc пароль для приватного ключа (потом этого делать не потребуется)

Pageant — это агент SSH-аутентификации в составе PuTTY, он позволяет управлять закрытыми ключами.
В трее висит его значек:

Репозиторий успешно склонирован на локальную машину

Теперь попробуем изменить локальный репозиторий и отправить изменения на github. Добавим в локальный репозиторий файл README (файл с именем README обрабатывается github специальным образом — его содержимое будет отображаться в качестве описания репозитория на соответствующей странице)

Закоммитим изменения в локальный репозиторий

и синхронизируем его с репозиторием на github:

нажимаем Push

Теперь зайдя на страницу нашего репозитория мы увидим следующее:

Для каждого репозитория сайт предлагает wiki:

а также простую систему issue tracking-a:

кстати, для тех, кто использует в работе Eclipсe — есть соответствующий mylyn-коннектор для github:

и плагин EGit:

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

Резюмируя хочется сказать, что если вы начинающий разработчик, планирующий начать пользоваться системами контроля версий, или же более опытный и присматривающийся к распределенным VCS, но не знающий как начать, то есть смысл попробовать git, используя такой замечательный инструмент как github.com.

Полезные ссылки

Для работы с git:
code.google.com/p/msysgit git для windows
www.syntevo.com/smartgit/index.html SmartGit
code.google.com/p/tortoisegit TortoiseGit
http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY

Про git на русском:
habrahabr.ru/blogs/Git/106912 «Удачная модель ветвления для git» — перевод хорошей англоязычной статьи
githowto.com интерактивный курс по работе с git из консоли
habrahabr.ru/blogs/Git/106912 «Почему git» + обсуждение
habrahabr.ru/blogs/development/68341 «Git для переходящих с SVN» + обсуждение
habrahabr.ru/blogs/Git/75990 «Командная работа в git» + обсуждение
progit.org/book/ru русский перевод книги «Pro Git» (переведено не до конца)
habrahabr.ru/blogs/Git/123111 инструкция-шпаргалка для начинающих
los-t.livejournal.com/tag/git%20guts цикл постов «внутренности git»
lib.custis.ru/%D0%9B%D0%B8%D0%BD%D1%83%D1%81_%D0%A2%D0%BE%D1%80%D0%B2%D0%B0%D0%BB%D1%8C%D0%B4%D1%81_%D0%BE_GIT_%D0%BD%D0%B0_Google_Talks Линус Торвальдс о git
habrahabr.ru/blogs/Git/80909 книга «Волшебство git»

Про git на английском:
книги


видео
другое

habr.com

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

Если в один прекрасный момент вам ударило в голову желание насадить разумное, доброе, вечное, и пересадить всех с SVN на GIT, сразу встают три проблемы:
  • Объяснить зачем это нужно разработчикам и руководству
  • Ввести в обиход новую схему работы с кодом
  • Научить ничего не подозревающих девелоперов новым техникам

Поскольку мы пользуемся весьма эффективной схемой работы с кодом через git в одном из проектов, я решил её внедрить всюду, до куда дотянулись руки, для чего оформил в небольшую инстркуцию-шпаргалку, включающую в себя краткие ответы на «Зачем», описание схемы работы и список команд и телодвижений для разработчика с новой системой.

Основные постулаты работы с кодом:

  • Каждая задача решается в своей ветке.
  • Коммитим сразу, как что-то получили осмысленное.
  • В master мержится не разработчиком, а вторым человеком, который производит вычитку и тестирование изменения
  • Все коммиты должны быть осмысленно подписаны.
  • Репозиторий должен держаться сухим и шелковистым

Так как некоторые разработчики почему-то работают под Windows, пришлось описать в том числе и установку-настройку-рецепты при работе под Windows.

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

Предупреждаю сразу, инструкция отвечает на вопрос «зачем» разработчику, незнакомому с DVCS, а не начальству.
Так же, предполагается, что master ветку никогда не трогают с —force, желательно, чтобы это было невозможно вообще (зарезано на уровне gitolite).
Инструкция — начинающих разработчиков, а не Tips & Tricks, из этих соображений я опустил моменты «выхода из самосозданной задницы». Все случаи не упомнишь, гораздо проще разрулить на месте по факту если что-то из ряда вон выходящее.

Собственно инструкция: Работа с Git.pdf (135Kb).
Для желающих адаптировать её к своей ситуации, исходник: Работа с Git.odt (90Kb).
p.s.: Забыл сказать о лицензии: Public Domain. Делайте что хотите, только в терновый куст не бросайте.

Буду благодарен каким-либо полезным комментариям, указанием на очепятки и прочему фидбеку.

habr.com

Инструменты для работы с Git – TortoiseGit

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

Качаем тут.

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

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

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

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

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

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

И видим это

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

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

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

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

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

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

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

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

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

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

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

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

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

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

pr0git.blogspot.com

Установка Git под Windows — 2. Основы трансляции

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

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

  1. Устанавливается putty putty.zip. Распаковываем архив. Понадобятся как минимум plink, puttygen. Можно этот шаг пропустить, поскольку необходимые программы входят в комплект TortoiseGit. Но putty очень мощная программа и ее использование никогда не будет лишним.
  2. Скачиваем и устанавливаем TortoiseGit — https://code.google.com/p/tortoisegit/. Это мощная графическая среда управления вашими репозиториями. Через нее очень удобно грузить любые файлы с вашего компьютера в любые репозитории (будь то локальные, либо удаленные) При установке выбираете SSH клиент TortoiseGitPlink. Это программа Plink из состава пакета putty, которая устанавливает SSH соединение с удаленным центральным репозиторием (для защищенного и авторизованного соединения).
  3. Устанавливается Git из проекта http://git-scm.com/download/win. Выбрать опции при установке «Git Bash here», «Use Git from the Windows Command Prompt», «Use (Tortoise)Plink» – там должен быть указан путь до программы plink, например C:\Program Files\TortoiseGit\bin\TortoiseGitPlink.exe (plink устанавливается либо вместе с tortoisegit, либо с putty). Все остальные настройки оставляем по умолчанию.
  4. Затем заходим в настройки tortoisegit. Пуск → TortoiseGit → Settings. Далее находим вкладку Git где убедимся, что опции AutoCRLF и SafeCRLF установлены (если будет вылетать ошибка, снимите эти опции), настроены имя, фамилия, email разработчика. Учтите, чтобы имя разработчика отображалось корректно в хранилище, email должен совпадать с email, указанным при регистрации на civnote.ru.
  5. Далее нам нужно будет подключить удаленные репозитории. Сначала с помощью puttygen (программа из каталога TortoiseGit) создаётся пара приватный+публичный ключ (без парольной фразы!!!):

    При генерации ключа случайным образом двигаем мышью, а затем сохраняем приватный и публичный ключи на жестком диске.
  6. Публичный ключ добавляется в Ваш профиль на сайте для доступа к репозиториям (как это сделать — читать Управление репозиториями).
  7. Далее закоммитим необходимые файлы. Это вы делать уже умеете. Затем нажимаем правой кнопкой мыши по папке, в которой создан репозиторий, выбираем настройки TortoiseGit затем вкладка Git → Remote. Создаем удаленный репозиторий для этой папки. Сначала копируем адрес репозитория из вашего проекта с сайта civnote.ru, затем указываем путь до приватного ключа и создаем адрес удаленного репозитория:
  8. Теперь мы можем залить содержимое нашего репозитория на удаленный репозиторий. Для этого вновь нажимаем правой кнопкой мыши по папке, в которой создан репозиторий, затем TortoiseGit → Push… Настройки можно выбрать следующие:
  9. Приватный ключ добавляется в pageant (это программа, которая автоматически запускается TortoiseGit и висит в контекстном меню Windows справа внизу; если не запущена, находим в Пуск TortoiseGit и запускаем ее, ищите ее в папке с TortoiseGit) через клик правой кнопкой → add key. При этом в самой Тортилле можно не указывать ссылку на закрытый ключ. И можно убрать из нее опцию при Push-е «Autoload Putty key».

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

Получение существующего репозитория¶

В папке, где будут размещаться все рабочие проекты, жмём
Правой кнопкой → TortoiseGit → Git clone, вводим адрес центрального репозитория (как создать центральный репозиторий для проекта написано в следующей части Управление репозиториями)

ssh://[email protected]/РЕПОЗИТОРИЙ.git

или просто

[email protected]/РЕПОЗИТОРИЙ.git

В поле «Load Putty Key» выбираем путь до приватного ключа. Здесь самое главное не устроить путаницы с разными ключами. Лучшим решением является удаление всех созданных ранее вами ключей и использование одного ключа.
Кстати, каждый раз, как происходит запрос к внешнему хранилищу TortoiseGit автоматически запускает программу pageant и добавляет туда ваш приватный ключ. Данная программа бывает глючит, особенно при использовании нескольких ключей. Здесь могу дать только один совет — принудительно вырубать ее и заново обращаться к внешнему репозиторию через TortoiseGit.

После настройки Git вы можете перейти к настройке репозитория, как описано в статье Управление репозиториями.

puttygen.png (34,523 КБ) Александр Дмитриев, 17.12.2014 22:30

origin.png (53,232 КБ) Александр Дмитриев, 17.12.2014 22:30

push.png (29,315 КБ) Александр Дмитриев, 17.12.2014 22:30

civnote.ru

Как пользоваться Git для начинающих

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

Это мощная система, которая позволяет оптимизировать работу над вашими проектами. Здесь нет каких-либо требований к языку или структуре файлов, поэтому у разработчиков полная свобода действий. В этой статье мы рассмотрим как пользоваться git для начинающих пользователей. Рассмотрим все очень подробно, начиная от настройки, и до ветвей проектов.

Содержание статьи:

Команда git

Уже по традиции, перед тем, как перейти к примерам и работе с командой давайте рассмотрим ее основные опции и параметры. Синтаксис git очень прост:

$ git опции команда аргументы

Сначала рассмотрим опции, они влияют на работу всей утилиты:

  • -C — использовать указанную папку репозитория вместо текущей папки;
  • -c параметр=значение — использовать указанное значение параметра конфигурации;
  • -p — прокручивать весь вывод с помощью less;

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

  • add — добавить файл или папку в репозиторий git;
  • am — применить все патчи из email;
  • archive — создать архив файлов;
  • bisect — использовать бинарный поиск для поиска нужного коммита;
  • branch — управление ветками проекта;
  • bundle — перемещение объектов и ссылок в архиве;
  • checkout — переключение между ветками;
  • cherry-pick — внести изменения в уже существующие коммиты;
  • clean — удалить все неотслеживаемые файлы и папки проекта;
  • clone — создать копию удаленного репозитория в папку;
  • commit — сохранить изменения в репозиторий;
  • diff — посмотреть изменения между коммитами;
  • fetch — скачать удаленный репозиторий;
  • init — создать репозиторий;
  • merge — объединить две ветви;
  • pull — интегрировать удаленный репозиторий с локальным;
  • push — отправить изменения в удаленный репозиторий;
  • tag — управление тегами;
  • worktree — управление деревями разработки.

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

Как работает git?

Перед тем как идти дальше и рассматривать использование git для управления своими проектами, я бы хотел сказать несколько слов о том, как же работает эта технология, так сказать, основы работы git.

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

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

Как пользоваться Git?

Дальше я буду предполагать, что вы выполнили установку и базовую настройку git. Кроме установки, вам нужно указать правильный адрес электронной почты и имя пользователя для доступа к серверу Git, например, на GitHub. Если вы этого еще не сделали смотрите инструкцию установка Git в Ubuntu 16.04.

Обычно, структура проекта в Git будет зависеть от масштаба и сложности вашей программы. Но для начала мы будем использовать проект, состоящий только из одной ветви. Каждый проект содержит одну ветку по умолчанию, она называется master. Наш первый проект будет называться test.

Создание проекта

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

mkdir -p ~/git/testing ; cd ~/git/testing

Эта команда создаст нужную структуру папок и переводит текущий каталог в только что созданный. Теперь создадим первый файл нашего проекта:

touch file

 

Проект готов, но система контроля версий git еще не знает об этом.

Настройка проекта в git

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

git init

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

git add .

Если все прошло хорошо, то команда ничего не выведет.

Фиксация изменений

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

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

git commit -m "Initial Commit" -a

Команде необходимо передать два параметра, первый — это -m, ваш комментарий, второй -a, означает, что нужно применить действие ко всем измененным файлам. Для первого раза используется этот параметр, но обычно вам нужно указать измененные файлы или каталоги. Например, можно делать так:

git commit -m "Changed file" file

 

Отправка изменений

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

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

 git remote add origin https://github.com/Seriyyy95/testing.git

Затем можно посмотреть список удаленных репозиториев:

git remote -v

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

git push origin master

Команда push указывает, что нужно отправить данные в удаленный репозиторий, origin — наш настроенный репозиторий, а master — ветвь.

Управление ветвями

Для простых проектов достаточно одной ветви. Но если проект большой и он имеет несколько версий, в том числе тестовую, то может понадобиться создать для каждой из них отдельную ветвь. Сначала смотрим доступные ветви:

git branch -a

 

 

Опция -a указывает что нужно вывести все ветви, даже не синхронизированные. Звездочка указывает на активную ветвь. Теперь создадим ветвь для разработки с помощью команды checkout:

git checkout -b develop

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

git checkout master
$ git checkout develop

Теперь создадим еще один файл:

touch develop

И добавим его в нашу новую ветвь develop:

git add develop

 

 

Сделаем коммит для внесенных изменений:

git commit -m "develop file" develop

Дальше проверим существует ли этот файл в основной ветке master или только в дополнительной. Смотрим текущую ветку:

git branch
$ ls

Затем переключаемся на ветку master и снова смотрим:

git checkout master
$ git branch
$ ls

Здесь файла нет, так и должно быть. В git есть такая полезная вещь, как слияние. С помощью нее вы можете объединить две ветви. Например, переместить код из рабочей ветки в стабильную. Для этого достаточно выполнить команду merge:

git merge develop --no-ff

Перед тем как будет выполнено слияние вам нужно ввести комментарий, зачем это нужно. Затем если вы еще раз выполните ls, то увидите, что здесь уже есть нужный файл. Наши примеры git подошли к концу.

Выводы

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

losst.ru

Разработка в Caché Studio с использованием TortoiseGit / InterSystems corporate blog / Habr

Caché-Git — это модуль контроля версий для Caché Studio, который обеспечивает вызов диалоговых окон TortoiseGit непосредственно из Studio и полуавтоматическую синхронизацию рутин между Caché и локальным репозиторием.

В каждой области выбираются пакеты, проекты, классы, рутины, dfi-файлы, csp-страницы, csp-приложения которые будут остлеживаться Caché-Git.

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

Caché-Git работает только на компьютерах, на которых установлен и сервер и клиент Caché. Caché-Git не будет работать при соединении с удалённым сервером.

Где взять

Репозиторий с Caché-Git находится по адресу github.com/intersystems-ru/cache-tort-git. Там же есть wiki, в которой описаны шаги по установке и использованию

Установка Caché-Git

Коротко

На время установки отключить read-only на CACHELIB и импортировать файл с проектом в область %SYS. Для нужных областей (например SAMPLES и USER) назначить класс %SourceControl.Git как класс контроля версий.
Подробно

На время установки вы должны включить возможность записи в базу CACHELIB. Это делается через «Портал управления системой». Выберите «Администрирование системы > Конфигурация > Конфигурация системы > Локальные базы данных». Щёлкните на ссылке «редактировать» в строке с CACHELIB и в выпадающем списке «Только чтение?» выберите «Нет». После установки Caché-Git флаг можно будет вернуть обратно.

В Caché Studio выберите область %SYS и импортируйте («Инструменты > Импортировать локально») файл c Caché-Git. Всё, можно опять запрещать запись в CACHELIB.

Теперь нужно установить области, в которых для контроля версий будет использоваться Caché-Git. Для этого в «Портале управления системой» выберите «Администрирование системы > Конфигурация > Дополнительные настройки > Система контроля версий». Для нужных вам областей отметьте класс %SourceControl.Git и нажмите «OK». Пример в этом туториале будет работать с областью SAMPLES, поэтому выберите класс %SourceControl.Git как класс системы контроля версий для неё.

***

После установки, в Caché Studio при выборе области, в которой Caché-Git назначен как система контроля версий, появится меню «Git».

Настройка

Чтобы настроить Caché-Git выберите меню «Git > Settings» в Caché Studio и укажите два параметра:
  • Путь к файлу tortoiseproc.exe. Это файл из программы TortoiseGit
  • Путь к временной папке, в которой будут создаваться локальные репозитории.

Эти параметры общие для всех областей.

Настройки TortoiseGit вызываются через меню «Git > Tortoise Git Settings».

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

Откройте область SAMPLES. Чтобы проинициализировать репозиторий в области, выберите меню «Git > Create repo» и нажмите пару раз «OK». Меню Git приобретёт полный вид.

В инспекторе выберите элемент, который вы хотите добавить в Git, щёлкните по нему правой кнопкой и в контекстном меню Git выберите «Add to SourceControl».

Затем выберите пункт меню «Git > Commit». В нижней части открывшегося окна выберите все файлы и добавьте (щелчок правой кнопкой > Add) их к версионным. Если файлов нет — поставьте галочку Show Unversioned Files. Напишите комментарий к коммиту. Нажмите OK, а затем Close.

Файл sc-list.txt содержит список элементов, которые отслеживаются Caché-Git. Он нужен для того, чтобы передавать между двумя репозиториями информацию о программах, которые контролируются Git.

Два важных параграфа

Всякий раз, когда вы добавляете новый элемент к Caché-Git или сохраняете уже существующий, этот элемент экспортируется во временную папку, поэтому при вызове команд TortoiseGit (таких как, например, commit, push, revert и так далее) нет необходимости выгружать все программы (Git >Export All), которые отслеживаются Caché-Git.

При импорте наоборот. Во-первых, при pull или revert может измениться значительная часть программ. Во-вторых, вызов окон TortoiseGit из Caché Studio асинхронный и нет возможности узнать, когда то или иное окно закрыто и закончилась операция обновления файлов. ПОЭТОМУ. После всех операций, выполненных TortoiseGit, которые могут менять содержимое рабочей папки, выберите пункт меню «Git > Import All». Это команды — Clone, Pull, Fetch, Revert. Всякий раз, когда при выполнении одной из этих команд в окне вывода будет появляться напоминание «Choose Import All menu after work with Git»

Работа с удалённым репозиторием

Загрузить содержимое своего репозитория на сервер можно, выбрав пункт меню «Git > Push» и указав в поле «Arbitrary URL» адрес репозитория.
Подключение к репозиторию

Каждый локальный репозиторий Caché-Git хранится внутри подпапки папки указанной как временной при настройке (обычно, это c:\temp). Имя этой подпапки совпадает с именем области (namespace), например c:\temp\USER или c:\temp\SAMPLES.

Чтобы подключиться к удалённому репозиторию — выберите меню «Git > Clone». Введите имя репозитория, например «http://git.assembla.com/demo.git». TortoiseGit сам добавит имя папки demo к пути c:\temp\user, так что получится c:\temp\user\demo. Сотрите последнее «\demo», так чтобы осталось только c:\temp\user. Это нужно сделать только при клонировании, дальше при выполнении команд push, pull и так далее ничего не нужно будет менять.

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

Основной рабочий цикл выглядит так:
  1. Выполните Pull.
  2. Разберите конфликты в TortoiseGit, если есть
  3. Чтобы загрузить изменения с диска в Caché, выберите меню Import All.
  4. Выполните изменения в Caché Studio.
  5. [Необязательно] Чтобы принудительно выгрузить изменения с диска в Caché, выберите меню Export All.
  6. Выберите Commit
  7. Выберите Push или из меню Caché Studio или сразу после Commit.

Пример установки и работы можно посмотреть на видео:

habr.com

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

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