Краткое руководство по git1
Необходимо зайти в менеджер удалённых репозиториев2 по адресу 1.0.0.137:3033 и выбрать репозиторий, над которым будет вестись работа. Нажать Ответвить
Репозиторий должен появиться в списке удалённых репозиториев пользователя3. Такой репозиторий называется форк (от англ. - вилка).
Именно этот репозиторий нужно сохранять в качестве локального4. Для этого необходимо скопировать его полный адрес (http-ссылка) с суффиксом .git,
Графический клиент SmartGit5
- Перейти в пункт меню
Repository -> Clone.
- В появившемся окне в поле
Repository URLнеобходимо вставить скопированную ранее с портала ссылку, и указать, какую ветку репозитория следует сделать локальной при клонировании репозитория. На третьем шаге клонирования будет предложено указать папку на компьютере, куда будет помещён репозиторий.
Работа в консоли git-bash полностью дублирует работу в любом терминале *nix систем. При работе с консолью следует обратить внимание на то, что команды рекомендуется набирать вручную, а не копировать из этого мануала, во избежание попадания в команду специальных пробельных символов. Для клонирования репозитория необходимо перейти в папку, куда предполагается поместить репозиторий командой cd <folder-path> или создать её mkdir <folder-name>. Затем необходимо выполнить команду git clone <path-to-remote-repository>, где path-to-remote-repository - это скопрованная с портала ссылка на пользовательский репозиторий. Обратите внимание, что выполнение команды git clone создаст в папке вызова отдельную папку с названием клонируемого репозитория, и поместит туда проект. Например, Вы находитесь в папке c:\ то после выполнения, например, команды git clone http://1.0.0.137:3033/ovchinnikov_ii/git-man.git файлы проекта будут находиться в папке c:\git-man
Необходимость в обновлении форков может возникать в случае когда основной репозиторий был обновлён, и внесённые изменения необходимо применить также в созданном форке. Общую схему работы с репозиторием можно описать следующей диаграммой:
Таким образом становится очевидно, что при внесении изменений в форк, основной репозиторий не затрагивается, поэтому можно без каких-либо последствий создавать дополнительные локальные ветки, но учесть, что их слияния с основной веткой форка недостаточно для обновления глобального репозитория.
Для настройки обновления форка и соответствующего ему локального репозитория необходимо открыть консоль git-bash. Для проверки корректности работы следует пройти в папку локального репозитория и ввести команду git remote -v, результатом работы которой должны стать строки
Далее следует указать, к какому глобальному репозиторию относится данный форк, выполнив команду git remote add upstream <http-path-to-global-remote-repository>, где указанный путь - это http-ссылка с суффиксом .git. Таким образом результат работы команды git remote -v должен будет преобрести следующий вид:
Однажды настроив локальный репозиторий таким образом, можно будет в любой момент проверять и добавлять обновления глобального репозитория, выполняя следующие команды:
git fetch upstream- выполнит проверку удалённого репозитория на наличие обновлений;git checkout <branch-to-update>- выполнит переход в нужную ветку локального репозитория;git merge upstream/<branch-with-updates>- выполнит слияние локальной ветки и ветки удалённого репозитория;git push- выполнит синхронизацию локального репозитория и удалённого пользовательского репозитория.
В случае, если в локальном репозитории не было произведено никаких изменений - слияние веток произойдёт методом Fast-forward. Если же в локальном репозитории были произведены изменения, будет создан обычный merge-commit в котором будут отражены возможные конфликты и изменения с двух сторон слияния.
Все правки в проект следует вносить в отдельных локальных ветках6, и в удалённый репозиторий эти ветки не добавлять. Внесение правок осуществляется непосредственным изменением и добавлением файлов в папке проекта, без дополнительного создания "старых версий файла". После внесения изменений в проект следует отформатировать и протестировать вновь написанный код и все возможные смежные части проекта (чтобы не нарушить работоспособность проекта). После такой проверки следует зафиксировать изменения в проекте, выполнив коммит.
Написав сообщение, описывающее характер сделанных изменений, следует сделать коммит. Поскольку изменения делаются в пользовательском клоне удалённого репозитория, то изменения можно сразу синхронизировать, выполнив команду Commit & Push.
В git-bash прежде чем выполнять коммит следует дополнительно уточнить состояние файлов и убедиться, что они подготовлены (staged). Для этого необходимо выполнить команду git status и в случае необходимости добавить файлы к подготовленным командой git add <file-name> для одного файла или git add . для всех файлов. Когда нужные файлы переведены в состояние подготовленных - можно делать коммит, выполнив команду git commit -a -m"<your-commit-message>", где ключ -a означает, что необходимо зафиксировать все подготовленные файлы, а -m означает, что далее в двойных кавычках будет следовать коммит сообщение. Обратите особенное внимание на то, что не следует фиксировать коммиты без коммит сообщений. Загрузка локального репозитория на сервер производится командой git push, которая в процессе выполнения потребует ввода логина и пароля удалённого репозитория.
Последний шаг - предложение запроса на слияние изменений с основным репозиторием. Прежде, чем приступать к этому шагу, следует удостовериться, что предлагаемые для слияния коммиты содержат актуальную информацию с сервера7. Необходимо зайти в оригинальный репозиторий, от которого производилось клонирование, выбрать вкладку "Запросы на слияние".
Далее выбрать ветку основного репозитория, в которую нужно влить изменения, соответствующую ветку своего склонированного репозитория из которой будут слиты изменения, и ввести основную информацию о запросе на слияние, например резюме изменений, их причину и следствие. Внизу, для дополнительного осведомления можно также посмотреть какие коммиты предлагаются для слияния и какие изменения в файлах были произведены.
В связи с тем, что почтовые оповещения в сети не настроены, после отправки запроса на слияние следует оповестить владельца репозитория о новом запросе на слияние.
1: Системы контроля версий (СКВ) это программное обеспечение облегчающее работу с изменяющейся информацией. СКВ регистрируют изменения в одном или нескольких файлах чтобы в дальнейшем иметь возможность вернуться к определённым старым версиям этих файлов. Традиционно СКВ используются в сфере разработки программного обеспечения и работы с текстами, но под версионный контроль можно поместить файлы практически любого типа. Таким образом, СКВ позволяют отслеживать изменения внесённые в код программы и при необходимости отменять их до любого нужного момента. Вести работу над новым функционалом без влияния на работоспособность существующего. СКВ позволяет возвращать к прежнему виду как отдельный файлы, так и проект целиком, предохраняет от порчи, потери и удаления отдельных частей проекта, позволяет отслеживать кем и когда вносились изменения, и в чём эти изменения состояли. При разработке одной программы несколькими программистами применение системы контроля версий делает работу в команде эффективнее. Что такое Git? Это важно усвоить, поскольку если вы поймёте, что такое Git, и каковы принципы его работы, вам будет гораздо проще пользоваться им эффективно. Главное отличие Git'а от любых других СКВ (например, Subversion и ей подобных) — это то, как Git смотрит на свои данные. В принципе, большинство других систем хранит информацию как список изменений (патчей) для файлов. Эти системы (CVS, Subversion, Perforce, Bazaar и другие) относятся к хранимым данным как к набору файлов и изменений, сделанных для каждого из этих файлов во времени. Git не хранит свои данные в таком виде. Вместо этого Git считает хранимые данные набором слепков небольшой файловой системы. Каждый раз, когда вы фиксируете текущую версию проекта, Git, по сути, сохраняет слепок того, как выглядят все файлы проекта на текущий момент. Ради эффективности, если файл не менялся, Git не сохраняет файл снова, а делает ссылку на ранее сохранённый файл. Это важное отличие Git'а от практически всех других систем контроля версий. Git больше похож на небольшую файловую систему с инструментами, работающими поверх неё, чем на просто СКВ. Для совершения большинства операций в Git'е необходимы только локальные файлы и ресурсы, т.е. обычно информация с других компьютеров в сети не нужна. Работа локально означает, что мало чего нельзя сделать без доступа к Сети. Перед сохранением любого файла Git вычисляет контрольную сумму, и она становится индексом этого файла. Поэтому невозможно изменить содержимое файла или каталога так, чтобы Git не узнал об этом. Эта функциональность встроена в сам фундамент Git'а и является важной составляющей его философии. Если информация потеряется при передаче или повредится на диске, Git всегда это выявит. Механизм, используемый Git'ом для вычисления контрольных сумм, называется SHA-1 хешем. Это строка из 40 шестнадцатеричных символов (0-9 и a-f), вычисляемая в Git'е на основе содержимого файла или структуры каталога. SHA-1 хеш выглядит примерно так: 24b9da6552252987aa493b52f8696cd6d3b00373 При работе с Git'ом, эти хеши встречаются повсюду, поскольку он их очень широко использует. Фактически, в своей базе данных Git сохраняет всё не по именам файлов, а по хешам их содержимого. Практически все действия, которые вы совершаете в Git'е, только добавляют данные в базу. Очень сложно заставить систему удалить данные или сделать что-то неотменяемое. Можно, как и в любой другой СКВ, потерять данные, которые вы ещё не сохранили, но как только они зафиксированы, их очень сложно потерять, особенно если вы регулярно отправляете изменения в другой репозиторий. Поэтому пользуясь Git'ом можно экспериментировать, не боясь что-то серьёзно поломать. Три состояния - это самое важное, что нужно помнить про Git, для дальнейшего изучения и работы. В Git'е файлы могут находиться в одном из трёх состояний: зафиксированном, изменённом и подготовленном. "Зафиксированный" значит, что файл уже сохранён в вашей локальной базе. К изменённым относятся файлы, которые поменялись, но ещё не были зафиксированы. Подготовленные файлы — это изменённые файлы, отмеченные для включения в следующий коммит. Таким образом, в проектах, использующих Git, есть три части: каталог Git'а (Git directory), рабочий каталог (working directory) и область подготовленных файлов (staging area). Каталог Git'а — это место, где Git хранит метаданные и базу данных объектов вашего проекта. Это наиболее важная часть Git'а, и именно она копируется, когда вы клонируете репозиторий с другого компьютера. Рабочий каталог — это извлечённая из базы копия определённой версии проекта. Эти файлы достаются из сжатой базы данных в каталоге Git'а и помещаются на диск для того, чтобы вы их просматривали и редактировали. Область подготовленных файлов — это обычный файл, обычно хранящийся в каталоге Git'а, который содержит информацию о том, что должно войти в следующий коммит. Иногда его называют индексом (index), но в последнее время становится стандартом называть его областью подготовленных файлов (staging area). Если рабочая версия файла совпадает с версией в каталоге Git'а, файл считается зафиксированным. Если файл изменён, но добавлен в область подготовленных данных, он подготовлен. Если же файл изменился после выгрузки из БД, но не был подготовлен, то он считается изменённым.
2: Репозиторий - это место, где хранятся и поддерживаются какие-либо данные. Используемые в Git репозитории хранят все документы вместе с историей их изменений и служебной информацией. Менеджер удалённых репозиториев - это веб-приложение, которое хранит и предоставляет доступ к репозиториям пользователей.
3: About (remote) user repositories
4: About local repositories
5: About smartgit
6: About Branches
7: About Updating (pull, merge)