Github com на русском пошаговая инструкция. Подробное введение в работу с 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 будет зависеть от масштаба и сложности вашей программы. Но для начала мы будем использовать проект, состоящий только из одной ветви. Каждый проект содержит одну ветку по умолчанию, она называется master. Наш первый проект будет называться test.

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

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

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

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

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

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

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

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

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

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

Изменения тоже автоматически не отслеживаются. Фиксация изменений выполняется с помощью команды 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

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

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

git push origin master

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

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

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

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

git checkout -b develop

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

git checkout master
$ git checkout develop

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

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

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

git commit -m "develop file" develop

git branch
$ ls

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

git checkout master
$ git branch
$ ls

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

git merge develop --no-ff

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

Выводы

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

Для людей естественно сопротивляться изменениям. Если Git не встретился вам, когда вы начинали работать с системами контроля версий, наверняка вы чувствуете себя комфортнее в системе Subversion (SVN) .

Часто люди говорят, что Git слишком сложен для новичков. Тем не менее, я позволю себе не согласиться с этим.

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

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

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

Установка Git

На официальном сайте Git есть детальная информация об его установке на Linux, Mac и Windows. В нашем случае, мы будем использовать в целях демонстрации Ubuntu 13.04 , где установим Git с помощью apt-get:

sudo apt-get install git

Начальная настройка

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

mkdir my_git_project cd my_git_project

Первым этапом является инициализация Git в каталоге. Это можно сделать с помощью команды init , которая создает каталог .git , содержащий всю информацию, связанную с Git для вашего проекта.

git config --global user.name "Shaumik" git config --global user.email "[email protected]" git config --global color.ui "auto"

Важно отметить, что если вы не укажите свое имя и адрес электронной почты, то будут использованы значения по умолчанию. В нашем случае, значениями по умолчанию были бы имя пользователя donny и адрес электронной почты donny@ubuntu .

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

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

Подготовка файлов для коммита

Следующий шаг - это создание файлов в каталоге. Вы можете использовать, к примеру, текстовый редактор Vim . Заметьте, что если вы собираетесь добавить Git к уже существующему каталогу, вам не нужно выполнять этот шаг:

Проверить статус репозитория

Теперь, когда у нас есть несколько файлов в нашем репозитории, давайте посмотрим, как Git обращается с ними. Для того, чтобы проверить текущий статус репозитория, нужно воспользоваться командой git status :

Добавление файлов в Git для отслеживания

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

Добавляем файлы при помощи команды add :

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

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

git add myfile2 myfile3

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

Если вы будете использовать команду add рекурсивно, она добавит все такие файлы, если они существуют в вашем репозитории.

Удаление файлов

Но выполнение простой команды git rm удалит файл не только из Git , но также и из вашей локальной файловой системы! Чтобы

Git прекратил отслеживать файл, но при этом в вашей локальной системе сохранился сам файл, выполните следующую команду:

git rm --cached

Коммит изменений

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

Вы можете привязывать к каждому коммиту сообщение, которое добавляется при помощи префикса -m :

git commit -m "My first commit"

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

Избегайте слишком общих сообщений типа «Исправлены ошибки ». Если у вас есть трекер задач, вы можете добавлять сообщения в виде «Исправлена ошибка #234 ».

Хорошей практикой является использование имени ветки или имени функции в качестве префикса к сообщению коммита. Например, «Управление активами: добавлена функция для генерации PDF файлов активов » - это содержательное сообщение.

Git идентифицирует коммиты путем добавления длинного шестнадцатеричного числа к каждому коммиту. Как правило, не нужно копировать всю строку, для определения вашего коммита достаточно первых 5-6 символов.

Обратите внимание, что на скриншоте наш первый коммит определяется кодом 8dd76fc .

Дальнейшие коммиты

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

Вы можете проверить изменения в отслеживаемых файлах, сделанные в последнем коммите, с помощью команды git diff . Если вы хотите просмотреть изменения в определенном файле, используйте команду git diff :

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

Вы можете избежать использования этой команды, воспользовавшись префиксом -a для команды git commit , который добавит все изменения в отслеживаемые файлы.

Этот процесс, однако, очень опасен, так как может навредить проекту. Например, допустим, что вы открыли файл и изменили его по ошибке.

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

После того, как вы разместили ваши файлы, можно приступить к коммиту. Я упоминал, что с каждым коммитом может быть ассоциировано сообщение, которое мы вводим с помощью префикса -m .

Однако существует возможность ввести сообщение в несколько строк, воспользовавшись командой git commit , которая открывает интерактивную форму для записи:

Управление проектом

Чтобы просмотреть историю вашего проекта, вы можете выполнить следующую команду:

Так будет показана вся история проекта, которая представляет собой список всех коммитов и информации по ним. Информация о коммите включает в себя хеш-код коммита, автора, время и сообщение коммита. Есть различные варианты git log , которые вы можете изучить, как только освоите понятие ветки (англ. branch) в Git .

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

git show

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

Размещение кода в облаке

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

Здесь описывается практическая часть вопроса использования Git - его установка и регистрация на сервере GitHub.com.

GitHub.com - это сервис, предлагающий хранение вашего кода и данных с использованием системы контроля версий Git . GitHub предоставляет бесплатный тарифный план для хранения 300Мб данных в открытом виде. Это значит, что любой пользователь интернета может скачать себе ваши данные. На GitHub можно разместить и закрытые для других репозитарии, заплатив 7$ в месяц. На бесплатном аккаунте GitHub, по-умолчанию, никто не сможет изменить ваши данные (могут только читать). Но вы можете настоить, кто из пользователей системы GitHub, имеет право на запись.

В статье подробно рассказывается, как делать настройку Git в ОС Windows и в ОС Linux.

Установка Git под Linux

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

apt-get install git

Установка Git под Windows

Идем на официальную страницу Git http://git-scm.com , кликаем на Download for Windows . В открывшемся окне кликаем на Full installer for official Git . Запускаем полученный exe-шник.

В процессе инсталляции будет задан такой вопрос:

Я рекомендую выбрать "Run Git from the Windows Command Prompt". Все остальные опции можно оставлять по-умолчанию. После установки Git нужно перегрузиться или завершить сеанс пользователя и снова войти, чтобы применились изменения в системной переменной PATH.

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

Настройка SSH-ключей

Перед тем, как регистрироваться на GitHub, следует вначале сгенерировать SSH-ключ шифрования. Этот ключ необходим, чтобы быстро устанавливать соединение с GitHub, не вводя пароля. Без такого ключа GitHub просто не будет работать.

Внимание!

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

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

Настройка SSH-ключей в Linux

В операционной системе Linux вначале нужно заглянуть в каталог ~/.ssh . Если там есть файлы id_rsa и id_rsa.pub то это и есть SSH-ключи. Если такого каталога или таких файлов нет, то ключи нужно сгенерировать. Даем команду:

Вместо [email protected] нужно указать свой email. В процессе генерации ключа у вас спросят куда положить файлы, в ответ просто нажимаем Enter. При запросе пароля просто нажимаем Enter. После генерации, в каталоге ~/.ssh должны появиться файлы id_rsa и id_rsa.pub , они нам пригодятся в дальнейшем.

Настройка SSH-ключей в Windows

В операционной системе Windows генератор SSH-ключей включен в комплект поставки Git. Для генерации ключей необходимо запустить на выполнение файл C:\Program Files\Git\Git bash.vbs . Его можно запустить как обычный exe-шник. Откроется программа "Консоль git". В ней надо дать команду:

ssh-keygen -t rsa -C "[email protected]"

Будьте внимательны, в этой консоли подглючивает копи-паст, прощще ввести команду вручную. В качестве email указываем свой почтовый ящик. На запрос "Enter file in which to save the key " просто нажимаем Enter. При запросе пароля "Enter passphrase " и "Enter same passphrase again " просто нажимаем Enter. В процессе генерации ключей в консоли будет выдаваться примерно следующая информация:

Generating public/private rsa key pair.
Enter file in which to save the key (/c/Documents and Settings/username/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /c/Documents and Settings/username/.ssh/id_rsa.
Your public key has been saved in /c/Documents and Settings/username/.ssh/id_rsa.pub.
The key fingerprint is:
51:db:73:e9:31:9f:51:a6:7a:c5:3d:da:9c:35:8f:95 [email protected]

После выполнения этой программы, в каталоге C:\Documents and Settings\username\.ssh будут лежать файлы id_rsa и id_rsa.pub , они нам пригодятся в дальнейшем.

Регистрация на GitHub.com

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

В верхнем меню находим пункт "Pricing and Signup " и нажимаем на него:

Откроется страница выбора тарифного плана. Выбираем бесплатный аккаунт "Create a free account ":

Установка SSH-ключа в GitHub

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

В открывшемся окне нужно кликнуть на пункт меню "SSH Public Keys ", и нажать "Add Another Public Key ". Появится два поля - название ключа (Title ) и содержимое ключа (Key ).

В поле Title можно написать название компьютера, на котором сгенерирован публичный ключ. Можно писать по-русски.

В поле Key надо вставить содержимое файла id_rsa.pub . Помните, в каком каталоге они находятся? Переходим в этот каталог, открываем любым текстовым редактором файл id_rsa.pub (именно с расширением .pub , не перепутайте). Выделяем весь текст, копируем, и вставляем на странице GitHub в поле Key .

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

Создание репозитария на GitHub

Теперь пришло время создать свой первый репозитарий на GitHub. Репозитарий можно рассматривать просто как директорию, в которой будут лежать синхронизируемые файлы и поддиректории. Создавать репозитарий нужно в web-интерфейсе GitHub, а наполнять его файлами и работать с ним можно будет уже с помощью программы git на своем компьютере.

Для создания репозитария, нужно в правом верхнем углу нажать "Dashboard ". В открывшемся окне вы увидите пункт "Create A Repository ":

Так вот, этот пункт нам не нужен! Данный пункт открывает не диалог создания репозитария, а страничку помощи. Вместо клика по этому пункту, ищем ниже на странице малоприметную ссылку "Create A Repository ". Она и откроет диалог добавления нового репозитария.

В диалоге добавления нового репозитарию нужно заполнить, как минимум, поле названия проекта "Project Name ". В названии проекта лучше не использовать кириллицу, так как имя проекта - это по факту имя директории. Для избежания проблем лучше, чтобы имя проекта содержало только латиницу. После нажатия кнопки "Create Repository ", репозитарий будет создан.

Рабочая ссылка на репозитарий в системе GitHub формируется так. Если вы зарегистрировались под именем username , и ваш репозитарий называется reponame , то для доступа к этому репозитарию можно использовать следующие ссылки:

В синтаксисе Git:

[email protected]:username/reponame.git

В синтаксисе Https:

https://[email protected]/username/reponame.git

Работа с репозитарием на GitHub через программу Git

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

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

git config --global user.name "YourFullName"
git config --global user.email [email protected]

где вместо YourFullName нужно написать свое имя, а вместо [email protected] - свой email. Эти значения используются для логина на GitHub. Поэтому на месте YourFullName нужно указать ваш логин на GitHub-е, а на месте [email protected] нужно указать email, который вы вводили при генерации ключей шифрования.

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

git commit -a -m "first commit"

git remote add origin [email protected]:username/reponame.git

git push -u origin master

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

Git. Быстрый старт по использованию основных операций с объяснениями

Теперь файл(-ы) прочно обосновались в HEAD вашей рабочей локальной копии. Оттуда их не выгнать, но в вашем удаленном репозитории их все еще нет. Давайте сунем их еще и туда! Используйте:

Git push origin master

Только вместо master напишите название нужной ветки. Ах да, вы же еще не знаете, что такое ветки. Ну ладно, пока что запомните это место, а когда прочитаете про ветвление, вернетесь сюда.

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

Git remote add origin [сервер]

Ветвление

По-английски эта штука зовется branching - лучше как следует вникните в этот вопрос и почитайте про ветвление подробнее, я вас с ним только познакомлю. Ветвление используется для одновременной и независимой разработки разных фич (ну, или накопления большего количества багов, ведь исходного кода становится больше). Основной веткой является master - она появляется при создании репозитория. Другие ветки - это песочницы, когда достаточно в них наиграетесь, слейте в единое целое в master. Сейчас поясню, как это делается.

Создание новой ветки

Вот вы решили проработать какую-нибудь новую фичу. Создайте для нее новую ветку:

Git checkout -b [новая_ветка]

Ах да, фантазия-то у вас, наверное, работает на полную катушку, ну да поумерьте её в деле именования веток: назвать ветку можно только именем, допустимым для переменной в вашем любимом языке.

Переключение между ветками

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

Git checkout [репозиторий]/[ветка]

Ну, а если вы уже совсем не хотите с ней работать, то удалите ее совсем:

Git branch -d [ветка]

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

Git push origin [ветка]

Слияние веток

Чтобы слить ветку в ту, с которой вы сейчас работаете, используйте:

Git merge [ветка]

Но, понятное дело, это все приводит к конфликтам. И это реально проблема. Так что попробуйте исправлять все ручками прямо в директории с репозиторием. Только потом не забудьте пометить, что вы их «слили»:

Git add [имя_файла]

Кстати, ветки можно сравнить:

Git diff [одна_ветка] [другая_ветка]

Так, теперь приступим к более решительным действиям. Будем обновлять свой репозиторий в соответствии с самым свежим коммитом. Сделать это очень просто (а вот вернуть обратно не очень, поэтому трижды подумайте, прежде чем совершать эту ужасную ошибку):

Git pull

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

Git tag [первые_десять_символов_соответствующего_коммита]

Вы не знаете, какие первые символы у имени нужного коммита? Не беда, смотрите в историю репозитория - его лог:

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

Вот черт, я не то смержил!

Ну, а теперь давайте расскажу вам, как исправлять свои ошибки, хотя вы уверены, что не будете их делать. Если проблема только в одном файле, то вот вам Ctrl+Z для HEAD’a:

Git checkout -- [имя_файла]

Но если проблема находится аж в локальном репозитории, то зачистите там все и верните версию с сервера:

Git fetch origin git reset --hard origin/master

Да, чувак, тут все по-hard’овому. Это git.

Фичи git’а

Если вы ленивый, и вам не охота по-трупрогерски все писать в оболочке своей ОСи, то можете использовать GUI git’а:

В найдете еще кучу других GUI-шек.
Если вам стандартный вывод git’а кажется скучным, раскрасьте его:

Git config color.ui true

Ну, и есть еще такая штука - интерактивное индексирование. Когда у вас будет уже достаточно большой проект, то ужать представление index’а в log’е можно будет так:

Git add -i

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

Распределенные системы контроля версий (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, очень рекомендую попробовать именно его

Про git на русском:
habrahabr.ru/blogs/Git/106912 «Удачная модель ветвления для git» - перевод хорошей англоязычной статьи
githowto.com интерактивный курс по работе с git из консоли
habrahabr.ru/blogs/Git/106912 «Почему git» + обсуждение
habrahabr.ru/blogs/development/68341 «Git для переходящих с SVN» + обсуждение