Краткое руководство git

Git - это система контроля версий (VCS), одна из наиболее часто используемых и распространенных. Созданная для разработки ядра операционной системы Linux, она применяется в тысячах и тысячах программных проектов по всему миру, став практически незаменимым инструментом для программистов, писателей и всех, кто создает и редактирует документы.

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

• коллективная работа над проектом;
• ведение истории внесения изменений в код и документацию;
• лёгкое переключение между разными ветвями разработки;
• лёгкий ''откат'' к состоянию кода проекта в прошлом;
• упорядочивание хранилищ исходных файлов и документации;
• лёгкое клонирование существующих проектов;
• предоставление свободного доступа к Open Source проектам для лёгкого распространения ПО.

Существуют две основные разновидности VCS :

• с централизованным сервером (CVS, SVN, …);
• распределённые (GIT, Mercurial, …).

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

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

Тем не менее, наличие некоторого сервера для распределённых систем необходимо для связи разработчиков друг с другом и обменом изменениями. В этом документе описывается работа с таким сервером: bitbucket.org. на котором можно зарегистрировать несколько проектов (репозитариев) и организовать коллективную работу.

В качестве Git - сервера можно использовать компьютер в локальной сети (например, дома или на предприятии). Наиболее интересным в этой роли представляется проект GitLab. Существуют, также очень популярные площадки для хостинга проектов, а именно GitHub и BitBucket .

На локальном компьютере пользователя должна быть развернута локальная копия Git. Работать с ней можно через командный интерфейс или благодаря большому количеству программ с графическим интерфейсом пользователя.

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

"Интернет дом" Git расположен по адресу: http://git-scm.com/ После выбора операционной системы и скачивания дистрибутива, можно запустить инсталлятор и пройти через несколько шагов мастера настройки. В ОС Windows желательно включить интеграцию с проводником (Git Bash Here ):

Инсталлятор установит специальную unix-подобную оболочку для ввода команд:

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

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

Чтобы создать новое хранилище необходимо сначала выбрать папку на жестком диске, где будут размещены файлы проекта. Предположим, что такая папка называется Labs и расположена она в домашнем каталоге пользователя (в windows-системах в корневом каталоге на диске C:).

Необходимо запустить командную оболочку Git (при работе в Windows) и перейти в каталог Labs. Если при установке была выполнена интеграция с проводником, то достаточно в проводнике перейти в папку, вызвать на экран контексное меню и выбрать пункт Git Bash Here. Если пользователь предпочитает работать в unix-подобной системе, но нужно открыть терминал и перейти в папку Labs. Но во всех случаях важно оказаться внутри папки Labs перед тем как начинать работу с хранилищем! Используйте команду pwd в bash-оболочке или терминале для контроля полного пути к текущему каталогу.

Кроме pwd полезно знать еще несколько команд оболочки:

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

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

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

Перед тем, как начать работать с хранилищем, необходимо настроить некоторые параметры Git. Важнейшие из них устанавливаются командами (данные заменить на актуальные :-)):

После создания пустого репозитория можно добавлять в него содержимое. Напишем простую программу "Hello, world" и поместим ее код в хранилище.

Предположим, что текст программы сохранен в файле hello.c внутри каталога Labs. Следующим этапом будет добавление этого файла в хранилище:

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

выдает текущее состояние хранилища. После добавления нового файла, статус хранилища меняется.

Изменения, вносимые в хранилище, пока незафиксированы. Чтобы сохранить состояние репозитория используется команда

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

Я пишу текстовую игру на Python: мой первый репозиторий на GitHub

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

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

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

Совместная работа. Можно писать код для одного проекта параллельно с другими и легко объединять весь труд.

Я расскажу о самой распространённой системе управления версиями — Git. Она предустановлена на Mac OS X, а пользователям Windows для начала работы нужно её скачать. Вы можете установить графическую оболочку для работы с Git, но для начала я предлагаю попробовать вводить команды в терминале, чтобы лучше понять, как работает система.

Начнём с простого набора команд, ваших регистрационных данных — имени пользователя и электронной почты:

git config --global user.name [ИМЯ ПОЛЬЗОВАТЕЛЯ]
git config --global user.email [ЭЛЕКТРОННАЯ ПОЧТА]

Введя данные, зайдите с помощью команды cd в папку с проектом, наберите git init. нажмите ENTER — и всё, вы готовы к работе с Git! Впрочем, это только начало.

Только что вы создали репозиторий — набор файлов вашего проекта. В этой папке Git будет следить за всеми изменениями. Наверняка есть такие, за которыми следить не следует: например, разные кэш-файлы. Чтобы система не учитывала их, создайте файл .gitignore и добавьте на каждую его строку названия файлов и папок, для которых нужно сделать исключение. Например:

Чтобы удалить репозиторий, достаточно удалить папку — с ней погибнет и системный файл .git.

Ключевое понятие Git — это коммит, по сути, некая промежуточная версия приложения с существенными изменениями. Коммитить нужно как можно раньше и как можно чаще, чтобы вы всегда могли откатиться. В коммит входит стадия, которую вы добавляете командой git add [ИМЯ ФАЙЛА]. Чтобы добавить в стадию все файлы репозитория, поставьте на месте имени файла точку.

Суть стадии в том, что часто есть смысл не добавлять в один коммит все изменения, которые вы ввели с предыдущего коммита, а разделить их на разные. Например, вы добавили в файл game.py функцию очистки экрана, а в файл bureaucrat.py — функцию генерации пола бюрократа. Так как эти функции совершенно не связаны друг с другом и находятся в разных файлах, куда лучше разбить их добавление в основную программу на отдельные коммиты. Если окажется, что изменения в файле bureaucrat.py некорректны, вам не нужно будет откатываться слишком далеко.

Чтобы система запомнила коммит, введите команду git commit -m "[ОПИСАНИЕ]". Описание в кавычках должно быть коротким и внятным, вы и другие люди из вашей команды должны чётко понимать, что за изменения были в этом коммите. Проверить текущее состояние репозитория можно, набрав команду git status. историю изменений — git log. при этом модификатор --oneline сделает лог более читаемым.

Итак, вы допустили ошибку и хотите откатиться назад. Для этого наберите команду git checkout [ИМЯ ФАЙЛА]. и ваш файл словно волшебным образом вернётся в состояние последнего коммита. Если вы уже добавили файл в стадию, введите git reset HEAD [ИМЯ ФАЙЛА]. если добавили его в коммит — git checkout HEAD^ [ИМЯ ФАЙЛА]. если хотите откатить весь репозиторий к предыдущему коммиту — git reset --hard HEAD^ [ИМЯ ФАЙЛА]. Чтобы просмотреть текущие изменения в репозитории, воспользуйтесь командой git diff .

Ещё одно важное понятие Git — это ветка. Вы можете параллельно вести сразу несколько веток программы: например, одну стабильную и экспериментальные. С самого начала у вас уже есть активная основная ветка, называемая master — убедитесь в этом, набрав команду git branch. Чтобы отойти от основной ветки, нужно создать новую командой git checkout -b [ИМЯ ВЕТКИ]. Будьте внимательны, на какой ветке вы находитесь сейчас: именно на ней Git отслеживает все изменения. Чтобы вернуться на основную, наберите git checkout master — но лучше всего закончить работу над дополнительной веткой и, убедившись, что с кодом всё в порядке, ввести команду git merge [ИМЯ ДОПОЛНИТЕЛЬНОЙ ВЕТКИ]. которая добавит изменения в дополнительной ветке в основную. Так вы можете использовать модульный подход, постепенно подключая к программе новые возможности. Во время объединений бывают, конечно, и конфликты, но о них сейчас не будем — внизу я укажу ссылки, где можно будет подробнее изучить тему. Кстати, чтобы удалить ветку, введите git -d [ИМЯ ВЕТКИ] — только с этой командой надо быть осторожным.

Наконец, пришло время создать репозиторий на сайте GitHub. Если у вас ещё нет там аккаунта, зарегистрируйтесь — только помните, что ваши регистрационные имя пользователя и электронная почта на GitHub должны быть теми же, что вы вводили в начале в терминал. Затем нажмите кнопку Create repository («Создать репозиторий»). введите название, описание и подтвердите создание. На этом этапе вы вполне можете поставить себе для удобства клиент GitHub с графическим интерфейсом, но постоянства ради давайте лучше введём команды одну за другой.

git remote add origin [ССЫЛКА НА РЕПОЗИТОРИЙ]
git push -u origin master

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

Подробное руководство по GitHub для новичков на Readwrite

Краткое РУКОВОДСТВО для освоения Git

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

1 Работа с Git репозиториями Почему Git Краткий ответ: потому что не появляются задержки от работы с системой контроля версий. Git хранит всё локально, включая историю, ветки, коммиты и позволяет переключаться между всем добром без обращения к сети. Авторизация в GIT производится по персональному ключу а не паролю, который кешируется на некоторое время на стороне клиента, а не запоминается навсегда в настройках клиента. GIT позволяет легко работать с ветками, без видоизменений раскладки репозитория, и древесный просмотр изменений позволяет видеть что из какой ветки пришло. Более подробно можно прочитать http://habrahabr.ru/blogs/git/104198/ Общие сведения о Git Подробно о работе с Git, что это такое можно прочитать в Git Book по адресу http://book.gitscm.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 означает смену родителя ветки на новый коммит. При ребейзе все изменения, внесенные в данной ветке, откатываются назад и сохраняются в виде изменений, внесенных каждым коммитом; после чего указатель ветки переносится на новое начало, и на него последовательно начинают применяться изменения. Если конфликтов нет, то изменения накладываются автоматически, после чего ветка представляет собой набор изменений

2 относительно нового начала. Если теперь сделать слияние этой ветки с исходной, указатель головы исходной ветки будет просто передвинут на новое место, и мы потеряем информацию о том, что вообще существовала новая ветка. Именно поэтому используется слияние без fast-forward'а. При этом, даже если новая ветка начинается с конца предыдущей, создаётся специальный mergecommit, содержащий информацию о том, что в этом месте сливается текущая ветка с дополнительной. Подробнее о том, что такое 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. Коммит не должен добавлять/убирать пустые строки, менять пробелы на табы и наоборот, менять число пробелов и т. п. нигде, кроме случаев, относящихся к сути коммита. То есть при рефакторинге это нормально, но если ваш редактор поменял во всем файлые пробелы на табы или наоборот меняйте настройки редактора или перед

3 коммитом приводите всё к виду «как было». 5. Стиль исходного кода и отступов должен совпадать с текстом вокруг. То есть, если всюду в файле используются табы для отступа, не следует вставлять еще один case выровненный пробелами. 6. Минимизация конфликтов. При добавлении кода следует стараться форматировать код так, чтобы модификация его приводила к минимуму конфликтов при слиянии. Работа под Windows Для работы с Git под Windows самое удобное использовать TortoiseGit. Подготовка к работе 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» выбираем путь до приватного ключа.

4 Основные используемые функции При работе используются либо консольные утилиты, аналогично linux, либо графический интерфейс. 1. Обновление текущей ветки из центрального репозитория: В контекстном меню папки с исходниками TortoiseGit->Pull 2. Отправка текущей ветки в центральный репозиторий: В контекстном меню TortoiseGit Push Выбираем в Local сперва master, потом нашу текущую ветку. Remote заполняется при этом автоматически. Название remote ветки должно быть идентично local

5 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 чтобы сразу переключиться на ветку.

6 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 после каждого коммита, так как это потребует доступа до удалённого сервера, и, соответственно, времени, потраченного впустую.

7 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

8 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

9 Работа под 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 == сохранить все добавленные изменения и все измененные файлы. Позволяет сохранять все изменения, если файлы не добавлялись.

10 Стандартные процедуры работы 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 == прерывает ребейз и возвращает ветку в исходное

11 состояние (до начала ребейза) После ребейза обновляем состояние ветки в центральном репозитории 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

Установка и настройка клиента Git

Как-то давно я уже писал о GitHub. Но только единицы смогли зарегистрироваться на сайте, что уж говорить о регистрации клиента через консоль. Это смог сделать ( кроме меня ) только один человек. Я решил, что пора бы выложить руководство по установке, настойке и использованию. Приготовьтесь. Букаф будет очень много.

Огромное спасибо Романову Андрею. который работал над переводом руководства по установке.

Первое: Загрузка и установка Git

В основе GitHub лежит открытая система контроля версий (VCS), называемая Git *. Созданная теми же людьми, которые создали Linux, Git отвечает за все изменения файлов, которые связаны с GitHub. Если Вы еще не знаете, что представляет из себя Git, взгляните на краткое описание.

1. Загрузка и установка последней версии программы Git для Windows.

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

Не используйте PuTTY, если Вам предоставляется выбор. GitHub поддерживает только OpenSSH.

Далее: Настройка SSH ключей. Мы используем SSH ключи для установления безопасного соединения между Вашим компьютером и GitHub. Их настройка довольно проста, но происходит в несколько шагов Дабы убедиться, что Вы генерируете новый ключ, нужно проверить, не существует ли он уже. Во-первых, Вам необходимо открыть Git Bash (не командную строку Windows), а командную строку клиента Git, которую вы можете найти в меню «Пуск».

Полезно знать: Из соображений безопасности Git Bash не будет отображать символы в то время, когда вы набираете пароль. Просто введите свой пароль и нажмите enter.

1. Проверка SSH ключей. Существует ли пара старых ключей ключей? ( Этот шаг можно пропустить и перейти сразу к шагу 4. )

Во-первых, нужно проверить существующие SSH ключи на Вашем компьютере:

/.ssh – Проверьте, есть ли каталог с именем ". SSH" в вашем каталоге

Пользователя Если получите сообщение "No such file or directory" пропустите этот шаг и переходите к шагу 3. В противном случае переходите к шагу 2. 2. Резервное копирование и удаление имеющихся SSH ключей. Если вы уже имеете SSH-каталог, то вероятно вы захотите сделать его резервную копию, либо же удалить его:

$ ls – Список всех подкаталогов в текущем каталоге

config id_rsa id_rsa.pub known_hosts

$ mkdir key_backup – делает подкаталог "key_backup" в текущем каталоге

$ cp id_rsa* key_backup – Копирует id_rsa и id_rsa.pub файлы вkey_backup

$ rm id_rsa* – Удаляет файлы id_rsa и id_rsa.pub

3. Генерирование нового SSH ключа. Для генерации нового SSH ключа введите текст команды, приведённый ниже. Когда Вас попросят ввести имя файла, в который и будет сохранен ваш ключ, просто нажмите enter ( Enter file in which to save the key )

$ ssh-keygen -t rsa -C your_email@youremail.com – Создавая новый SSH ключ, предоставьте адрес электронной почты

Generating public/private rsa key pair. Enter file in which to save the key (/Users/your_user_directory/.ssh/id_rsa):

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

Нажмите "Add Key.” 5. Общая проверка. Чтобы проверить, что вы связали свой SSH-ключ с аккаутном в github, следует выполнить нижеприведенную команду. Не меняйте "git@github.com" ни на что другое. Так и должно быть.

$ ssh -T git@github.com – Произойдет попытка объединения SSH-ключа с аккаунтом на GitHub Вы должны увидеть cледующее сообщение:

Здесь просто наберите yes и вы увидите следующее, если нет, то тогда вы сделали что-то не правильно.

Добавление вашей личной информации Теперь, когда Ваш GIT настроен и SSH ключи введены в GITHub, пришло время настроить Вашу личную информацию. 1. Настройка имени пользователя и электронного адреса При совершении каждого коммита, клиент git будет использовать ваши личные сведения. Чтобы предоставить GitHub информацию о вас ( это необходимо сделать ), выполните команды, приведенные ниже, заменив имя и электронный адрес своими собственными. «Именем» должно быть ваше настоящее имя, а не имя пользователя GitHub аккаунта. $ git config --global user.name " Firstname Lastname " – Задаём имя пользователя для всех Git инстанций в системе $ git config --global user.email " your_email@youremail.com " – Устанавливаем адрес электронной почты пользователя для всех Git инстанций в системе 2. Установка GitHub токена. Некторые инструменты осуществляют соединение к GitHub без участия SSH. Чтобы правильно использовать эти инструменты Вам нужно найти и настроить API токен. На сайте GitHub перейдите "Account Settings” > "Account Admin.” ( Настройки аккаунта > Управление аккаунтом ). Там вы должны увидеть следующее:

В консоли выполните следующую команду, используя Ваши имя пользователя и токен GitHub вместо тех, что показаны. git config --global github.user username – Устанавливаем имя пользователя GitHub для всех инструментов в системе. $ git config --global github.token 0123456789yourf0123456789token – Устанавливаем токен GitHub для всех Git инстанций в ситеме. *ПРИМЕЧАНИЕ* Если Вы смените пороль на GitHub, новый токен сгенерируется автоматически и его нужно будет заменить. От автора перевода: Спасибо всем, кто читает это перевод, на который было потрачено несколько ночных человеко-часов, так как если Вы его читаете – тут есть нужная Вам информация, а это значит, что мои силы и время были потрачены не зря. Был рад помочь, обращайтесь ещё, если что.

А теперь собственно работаем с GitHub

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

$ git clone <адресс репозитория>

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

$ ls -просмотр содержимого каталога

$ cd D: - перемещает вас на диск D

$ cd Labs/MyProject - перемещает вас в папку Labs/MyProject в том случае, если вы до этого находились в каталоге, содержащем эту папку.

$ cd. / -перемещает вас на каталог выше

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

$ git clone git@github.com:daynin/Labs.git

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

Редактируем содержимое репозитория и отправляем на сервер

Итак, у вас есть свой репозиторий, либо же клонированный чужой репозиторий. Вы поработали с файлами в нем и теперь хотите отправить изменения на сервер. Что для этого нужно сделать? Например, вы отредактировали один из файлов среди большого числа файлов, но забыли который файл подвергался изменениям. Вы можете легко посмотреть статус изменений командой:

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

$ git add FileName -проиндексировать файл FileName для того, чтобы его закоммитить

$ git commit -m 'Здесь нужно вводить текст сообщения вашего коммита' -на Windows можно вводить только латинские буквы, поэтому вам придется писать по английски, но сюда можно писать очень короткие фразы типа: "Small fix"

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

$ git commit -a -m 'All changes were pushed'

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

$ git commit -a -v -m 'Your comment'

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

$ git push origin master - все вы отправили изменения на сервер.

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

Просмотр всех изменений в репозитории. Получение изменений

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

$ git fetch - которая выведет в ваш терминал список изменений

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

$ git pull - эту команду, кстати, как и все остальные нужно выполнять в папке репозитория

На этом все. Вы получили необходимые знания для начала работы с github. Если вы хотите получить больше сведений по этому поводу, пройдите по этой ссылочке

Спасибо за ваше внимание. Кстати, следующий конкурс будет тесно связан с GitHub. Приз тот же - все исходники лаб.