Работа с 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), в рабочей копии хранится текущее состояние репозитория, и базовая копия текущей ревизии. На сервере хранятся все ревизии в виде изменений от предыдущей, либо в виде полных копий каждой ревизии с вычислением разницы по запросу. Все ревизии нумеруются по порядку начиная от первой. Так как 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 Алгоритм работы над задачейСтандартный алгоритм работы над какой-либо задачей выглядит так:
Правила ведения чистых коммитов Все коммиты, которые попадают в центральную ветку, должны следовать следующим правилам:
Работа под Windows Для работы с Git под Windows самое удобное – использовать TortoiseGit. Однако следует знать, что на 2017 год есть более удобный инструмент — SmartGit. Подготовка к работе
Получение репозитория В папке, где будут размещаться все рабочие проекты, жмём Основные используемые функции При работе используются либо консольные утилиты, аналогично linux, либо графический интерфейс.
Стандартные процедуры работы
Работа под Linux Подготовка к работе
Получение репозитория Переходим в директорию для работы, и запускаем git clone ssh://git@СЕРВЕР:ПОРТ/РЕПОЗИТОРИЙ.git Основные используемые функции
Стандартные процедуры работы
|
webhamster.ru
Распределенные системы контроля версий (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 тоже имеется.
Качаем по ссылке 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 на русском:
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
Основные постулаты работы с кодом:
Полученной инструкцией я кидаюсь во всех новых и старых разработчиков, которым даю доступ до репозиториев с рабочим кодом.
Предупреждаю сразу, инструкция отвечает на вопрос «зачем» разработчику, незнакомому с DVCS, а не начальству.
Так же, предполагается, что master ветку никогда не трогают с —force, желательно, чтобы это было невозможно вообще (зарезано на уровне gitolite).
Инструкция — начинающих разработчиков, а не Tips & Tricks, из этих соображений я опустил моменты «выхода из самосозданной задницы». Все случаи не упомнишь, гораздо проще разрулить на месте по факту если что-то из ряда вон выходящее.
Собственно инструкция: Работа с Git.pdf (135Kb).
Для желающих адаптировать её к своей ситуации, исходник: Работа с Git.odt (90Kb).
p.s.: Забыл сказать о лицензии: Public Domain. Делайте что хотите, только в терновый куст не бросайте.
Буду благодарен каким-либо полезным комментариям, указанием на очепятки и прочему фидбеку.
habr.com
Теперь будем рассматривать комплексные утилиты оболочки работы с Git. Начнем TortoiseGit.
Качаем тут.
Скачиваем сам дистриб
Я выбрал под свою разрядность вы выбираете под свою.
И если надо там же можно скачать языковый пакет русского языка для TortoiseGit
Устанавливаем
Ну и до кучи уж поставим русский язык. В настройках легко можно переключиться на английский.
Жмем старт и идем в настройки
И видим это
Далее идем в раздел Git и видим предупреждение на враждебном нам буржуйском языке
Что в переводе означает
Это нам говорят про это. Ставим галку чтобы нам это больше не показывали. Мы и так про это знаем.
Далее убираем не нужные контекстные меню, дабы они не засоряли его. В крайнем случае все можно вернуть обратно. Я оставил только этот пункт, чтобы сразу можно было посмотреть лог репозитория из контекстного меню проводника:
На скрине ниже я показал этот пункт и весь раскрытый пункт контекстного меню TortoiseGit
Ну а теперь кратенько по возможностям программы. По существу все операции с репозиторием Git можно выполнять из графического интерфейса. Глюки в программе есть конечно, но они не сильно страшные.
Из всего этого добра мне понравилось красивый просмотр логов (как раз пункт меню который я оставил):
Ну и сравнение файла из различных коммитов. Правда это чуток заморочено тут, но все же можно сделать.
И так сравним версии файла из коммита 2 и коммита 4. На коммите 2 делаем правый клик мышью
Далее видим скрин что ниже и убираем там все эти нули. Если не убрать то вылетит ошибка и жмем раскрывающийся список RefBrowse
Далее видим это и выбираем четвертый коммит
Жмем Compare revisions и видим сравнение файла test.txt из коммитов 2 и 4
Так же можно воспользоваться графическим интерфейсом для слияния веток. Но как то оно мне там не очень понравилось. Привычней уже при помощи командной строки это делать и разрешать конфликт уже при помощи графических утилит. Кстати, TortoiseGitMerge можно, так же настроить в Git, как внешние утилиты сравнения и слияния. Что я и сделаю. Об этом читайте в следующем посте.
Цель этого была просто познакомить с TortoiseGit.
pr0git.blogspot.com
Если непонятно, как пользоваться и работать с Git, то перед прочтением данной инструкции советую ознакомиться с основами работы Git здесь
Здесь остается добавить то, что программа 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 для управления своими проектами, я бы хотел сказать несколько слов о том, как же работает эта технология, так сказать, основы работы 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 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
В каждой области выбираются пакеты, проекты, классы, рутины, dfi-файлы, csp-страницы, csp-приложения которые будут остлеживаться Caché-Git.
Всякий раз при сохранении отслеживаемой программы, она будет экспортироваться на диск в репозиторий. При открытии программа будет загружаться из репозитория, если версия, находящаяся в нём свежее.
Caché-Git работает только на компьютерах, на которых установлен и сервер и клиент Caché. Caché-Git не будет работать при соединении с удалённым сервером.
В Caché Studio выберите область %SYS и импортируйте («Инструменты > Импортировать локально») файл c Caché-Git. Всё, можно опять запрещать запись в CACHELIB.
Теперь нужно установить области, в которых для контроля версий будет использоваться Caché-Git. Для этого в «Портале управления системой» выберите «Администрирование системы > Конфигурация > Дополнительные настройки > Система контроля версий». Для нужных вам областей отметьте класс %SourceControl.Git и нажмите «OK». Пример в этом туториале будет работать с областью SAMPLES, поэтому выберите класс %SourceControl.Git как класс системы контроля версий для неё.
***
После установки, в Caché Studio при выборе области, в которой Caché-Git назначен как система контроля версий, появится меню «Git».
Настройки TortoiseGit вызываются через меню «Git > Tortoise Git Settings».
В инспекторе выберите элемент, который вы хотите добавить в Git, щёлкните по нему правой кнопкой и в контекстном меню Git выберите «Add to SourceControl».
Затем выберите пункт меню «Git > Commit». В нижней части открывшегося окна выберите все файлы и добавьте (щелчок правой кнопкой > Add) их к версионным. Если файлов нет — поставьте галочку Show Unversioned Files. Напишите комментарий к коммиту. Нажмите OK, а затем Close.
Файл sc-list.txt содержит список элементов, которые отслеживаются Caché-Git. Он нужен для того, чтобы передавать между двумя репозиториями информацию о программах, которые контролируются Git.
При импорте наоборот. Во-первых, при pull или revert может измениться значительная часть программ. Во-вторых, вызов окон TortoiseGit из Caché Studio асинхронный и нет возможности узнать, когда то или иное окно закрыто и закончилась операция обновления файлов. ПОЭТОМУ. После всех операций, выполненных TortoiseGit, которые могут менять содержимое рабочей папки, выберите пункт меню «Git > Import All». Это команды — Clone, Pull, Fetch, Revert. Всякий раз, когда при выполнении одной из этих команд в окне вывода будет появляться напоминание «Choose Import All menu after work with Git»
Чтобы подключиться к удалённому репозиторию — выберите меню «Git > Clone». Введите имя репозитория, например «http://git.assembla.com/demo.git». TortoiseGit сам добавит имя папки demo к пути c:\temp\user, так что получится c:\temp\user\demo. Сотрите последнее «\demo», так чтобы осталось только c:\temp\user. Это нужно сделать только при клонировании, дальше при выполнении команд push, pull и так далее ничего не нужно будет менять.
Пример установки и работы можно посмотреть на видео:
habr.com