Git начало работы. Проверить статус репозитория. Создание в данном каталоге

Многим трудно начать работать с Git , ведь не все привыкли работать с командной строкой, но именно ее лучше всего использовать при работе с репозиторием Git . И сегодня я расскажу о самом простом, так сказать Git для чайника , чтобы помочь освоиться Вам с этой системой. Git представляет собой систему контроля версий, которая позволяет в нужный момент откатиться на старую версию, если вы "наломали дров ".

С помощью Git Вы сможете размещать свой код на GitHub , BitBucket и Google Code .

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

С чего начать?

Нам понадобиться программа Git Bash , это шелл сделанный на основе Cygwin, поэтому возможно использование Unix-команд, вроде ls, cd, mkdir. Скачать его можно по следующей ссылке http://git-scm.com/ .

Настройка Git

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

Git config --global user.name "Ваше имя" git config --global user.email "Ваш Email"

Также нам нужно настроить параметры установок окончания строк, для Windows мы вводим две команды

Git config --global core.autocrlf true git config --global core.safecrlf false git config --global core.eol native

На этом настройка заканчивается, можем начинать работу с проектом.

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

Допустим у нас есть папка с проектом, которую мы хотим разместить на GitHub.

2. Инициализируем папку для Git репозитория. Это нужно сделать только один раз для каждого проекта.

Git init

3. Связываем папку с удаленным репозиторием

Git remote add origin https://github.com/LeoXCoder/test_project.git

4. Добавляем все новые и измененные файлы

Git add .

5. Помечаем все новые и измененные файлы сообщением (commit )

Git commit -m "message"

Вместо message вписываем сообщение, например Initial Commit. или Bugfix.

6. Закачиваем код на удаленный репозиторий

Git push -u origin master

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

Git push

7. Можно посмотреть статус изменений, которые были сделаны.

Git status

8. Для скачивания репозитория используется команда

Git pull

Второй компьютер

Для использования репозитория на другом компьютере, используем следующие команды.

1. Клонирование репозитория

Git clone https://github.com/LeoXCoder/test_project.git

В результате git скачает удаленный репозиторий в новую папку test-project

2. После каких-то изменений в коде, выполняем все те же команды

Git add . git commit -m "I changed the user module." git push

Откат изменений

1. Полный откат до предыдущего коммита

Git reset HEAD --hard

2. Сброс изменений в файле на версию коммита

Git checkout

3. Откат до установленного тега, например v1

Распределенные системы контроля версий (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» + обсуждение
habrahabr.ru/blogs/Git/75990 «Командная работа в git» + обсуждение
progit.org/book/ru русский перевод книги «Pro Git» (переведено не до конца)
habrahabr.ru/blogs/Git/123111 инструкция-шпаргалка для начинающих
цикл постов «внутренности 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 на английском:
книги

progit.org/book книга «Pro Git»
rutracker.org/forum/viewtopic.php?t=2808582 книга «Version Control with Git», 2009, O"Reilly
book.git-scm.com книга «Git Community Book»
rutracker.org/forum/viewtopic.php?t=2808843 книга «Pragmatic Version Control Using Git», 2008, T. Swicegood
rutracker.org/forum/viewtopic.php?t=3239579 книга «Pragmatic Guide to Git», 2010, T. Swicegood. Описываемая версия git: 1.7.2.1. Книга в формате двустраничных разворотов - проблема/решение

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

Почему Git

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

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

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

Общие сведения о Git

Подробно о работе с Git, что это такое можно прочитать в Git Book по адресу http://book.git-scm.com/

В классических VCS (Version Control System) (CVS, SVN), в рабочей копии хранится текущее состояние репозитория, и базовая копия текущей ревизии. На сервере хранятся все ревизии в виде изменений от предыдущей, либо в виде полных копий каждой ревизии с вычислением разницы по запросу. Все ревизии нумеруются по порядку начиная от первой.
В случае CVS хранятся изменения и нумерая по каждому файлу независимо, в случае SVN, нумеруются изменения репозитория.
Так как SVN хранит только изменения всего репозитория, «ветки» в нем реализуются через специальную организацию файлов в хранилище. Классически, это /trunk/ для последнего кода, /branch/somename/ для веток. Для создания ветки, делается копия /trunk/ в /branch/somename/, над которым уже работает разработчик.
При этом, при каждом коммите, идёт обращение к центральному репозиторию, для сохранения изменения, отрабатывают скрипты на сервере, идет непрерывная нумерация изменений, запрос истории так же требует обращения на сервер и т.д.

Git относится к классу DVCS (Distributed Version Control System). При этом рабочая копия содержит все коммиты, историю, ветки, всё необходимое для ведения разработки без обращения к какому-либо серверу. Для синхронизации изменений между разными копиями репозитория, в нужный момент делается pull чтобы скопировать изменения удалённого репозитория к себе, либо push чтобы скопировать локальные изменения в удалённый репозиторий. В случае с Git, каждый коммит имеет уникальный ID в виде хеша, содержащий в себе все файлы, относящиеся к нему.

Каждый коммит имеет один коммит-родитель, и, возможно, коммит-источник слияния. Таким образом, коммиты представляют собой дерево наборов файлов. «Веткой» является указатель на какой-либо коммит. Таким образом, чтобы создать ветку, нужно просто дать имя какому-либо коммиту. Чтобы слить две ветки, одна из которых начинается с конца другой, можно просто передвинуть указатель второй ветки на новый коммит (это называется Fast-Forward).

Чтобы поддерживать «плоскую» основную ветку (master), используется техника ребейза веток перед слиянием, и слияение без fast-forward"а.

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

Если теперь сделать слияние этой ветки с исходной, указатель головы исходной ветки будет просто передвинут на новое место, и мы потеряем информацию о том, что вообще существовала новая ветка. Именно поэтому используется слияние без fast-forward"а. При этом, даже если новая ветка начинается с конца предыдущей, создаётся специальный merge-commit, содержащий информацию о том, что в этом месте сливается текущая ветка с дополнительной.

Алгоритм работы над задачей

Стандартный алгоритм работы над какой-либо задачей выглядит так:

Создаётся ветка, основывающаяся на последней копии master ветки. Название новой ветки содержит класс задачи, краткое описание, номер задачи в БТ. Например feature/sessions_add_datetime_filter.5503
Все изменения производятся внутри этой ветки. При каждом атомарном логическом изменении (например, добавили плагин – закоммитили добавление; поправили API одной функции во всех местах – закоммитили и тп) создаётся свой коммит. Это позволяет разделять какие были изменения, упрощается чтение и проверка на ошибки процесса разработки.
После того как код в ветке сделан и отлажен, все изменения закоммичены, данная ветка ребейзится относительно последнего мастера, и пушится в центральный репозиторий.
Второй человек, работающий над тем же проектом, делает к себе pull центрального репозитория. Если он уже смотрел – то удаляет свою локальную копию ветки, после чего переключается на указанную ветку. Прочитывает код, проверяет его работоспособность, после чего либо отдаёт на доработку, если там обнаружены проблемы, либо делает еще раз rebase поверх мастера, и слияние ветки с мастером.
После слияния с мастером, ревьюер пушит новый мастер в центральный репозиторий, удаляет у себя локальную ветку задачи, пушит в мастер удаление ветки задачи.
Разработчик удаляет локальную ветку задачи после того как задача была закрыта и изменения попали в master.

Правила ведения чистых коммитов

Все коммиты, которые попадают в центральную ветку, должны следовать следующим правилам:

Автором должен быть прописан разработчик – Имя, Фамилия, рабочий e-mail.
Текст комментария должен содержать краткое описание изменения. Для зарубежных проектов описание обязано быть на английском языке, для проектов российского бранча приемлемо комментировать на русском.
Коммит не должен содержать в себе файлы, не относящиеся к изменениям. Если ваша IDE, OS, какой-то плагин какому-либо софту использующемуся при разработке создают технические файлы, либо добавьте их в.gitignore, либо не добавляйте к коммиту, либо удаляйте перед коммитом.
Коммит не должен добавлять/убирать пустые строки, менять пробелы на табы и наоборот, менять число пробелов и т. п. нигде, кроме случаев, относящихся к сути коммита. То есть при рефакторинге это нормально, но если ваш редактор поменял во всем файлые пробелы на табы или наоборот – меняйте настройки редактора или перед коммитом приводите всё к виду «как было».
Стиль исходного кода и отступов должен совпадать с текстом вокруг. То есть, если всюду в файле используются табы для отступа, не следует вставлять еще один case выровненный пробелами.
Минимизация конфликтов. При добавлении кода следует стараться форматировать код так, чтобы модификация его приводила к минимуму конфликтов при слиянии.

Работа под Windows

Для работы с Git под Windows самое удобное – использовать TortoiseGit. Однако следует знать, что на 2017 год есть более удобный инструмент - SmartGit.

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

Устанавливается putty со страницы http://www.chiark.greenend.org.uk/~sgtatham/putty/
Лучше всего ставить полный пакет, со всеми программами. По надобятся как минимум plink, puttygen.
Устанавливается 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
Устанавливается TortoiseGit из проекта http://code.google.com/p/tortoisegit/
После установки зайти в TortoiseGit → Settings → Git → Config, убедиться что путь до msysgit задан, и что опции AutoCRLF и SafeCRLF установлены, настроены имя, фамилия, email разработчика.
С помощью puttygen создаётся пара приватный+публичный ключ.
Публичный ключ высылается админам для добавления в доступы репозиториев и серверов.
Приватный ключ добавляется в pagent через клик правой кнопкой → add key.

Получение репозитория

В папке, где будут размещаться все рабочие проекты, жмём
Правой кнопкой→TortoiseGit→Clone, вводим адрес центрального репозитория
ssh: //git@ СЕРВЕР:ПОРТ/РЕПОЗИТОРИЙ.git
В поле «Load Putty Key» выбираем путь до приватного ключа.

При работе используются либо консольные утилиты, аналогично linux, либо графический интерфейс.

Стандартные процедуры работы

«Начало работы над задачей»

,
Branch: master
Меню → TortoiseGit → Pull
Меню → TortoiseGit → Create Branch
Name Branch: название новой ветки
Base On: HEAD (master)
[x] Switch to new branch
«Коммит очередного кусочка работы»

Меню → Git commit -> “имя ветки”
Отметить файлы, только нужные для данного конкретного коммита
Обязательно щелкнуть на «View Patch», и убедиться
в соответствии правилам ведения чистых коммита
В message ввести описание изменения, соответствующее правилам
Меню → TortoiseGit → Push
Выбираем в Local сперва master, потом нашу текущую ветку.
Remote заполняется при этом автоматически.
Название remote ветки должно быть идентично local
«Ребейз относительно мастера»
Выполняется перед заливкой на сервер законченной задачи, когда все изменения уже закоммичены.
Меню → 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
«Кратковременное сохранение состояния изменений»

Меню → TortoiseGit → Stash Save
После этого дерево чисто, можно переключиться на другую ветку/мастер и так далее, поработать, после чего восстановить состояние, если переключиться обратно на рабочую ветку, и сделать
Меню → TortoiseGit → Stash Pop
«Длительное сохранение состояния изменений»

Меню → Git Commit -> “ветка”
Отмечаем все-все изменения (Select/Deselect All)
В текст сообщения пишем «Partial commit»
Позже, для возврата к тому же состоянию как было до, переключаемся на рабочую ветку, и делаем
Меню → TortoiseGit → Show Log
Выделяем коммит, который идет в дереве сразу перед «Partial commit»
Правой кнопкой → Reset <ветка> to this
Reset type: Mixed
«Ревью ветки»

Меню → TortoiseGit → Switch/Checkout
Branch: master
Меню → TortoiseGit → Pull
Меню → TortoiseGit → Switch/Checkout
Branch: remotes/origin/нужнаяветка
[x] Create new branch: нужнаяветка
[x] Force
[x] Track
[x] Override branch if exists
Меню → TortoiseGit → *Rebase
Branch: нужнаяветка
UpStream: master
Ветка ветка должна быть «up to date» или заребейзится без конфликтов.
== Анализируем изменения просмотром лога изменений через
Меню → TortoiseGit → Show log
и смотрим изменения от master до последнего
== Смотрим общее изменение относительно мастера
Меню → TortoiseGit → Diff with previous version
Version 1: HEAD
Version 2: master
== если всё хорошо, делаем
Меню → TortoiseGit → Switch/Checkout
Branch: master
Меню → TortoiseGit → Merge
From: нужнаяветка
[x] No fast forward
Сообщение не редактируем.
Меню → TortoiseGit → Push
И удаляем ветки:
Shift + Меню → TortoiseGit → Browser Reference
в дереве слева Refs => heads => находим ветку, правой кнопкой, Delete branch
в дереве слева remotes => origin => находим ветку, правой кнопкой,
Delete remote branch

Работа под Linux

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

Устанавливаются системные пакеты ssh-client и git
Создаётся приватный ключ:
ssh-keygen -t dsa -C "Ivan Petrov "
Настраивается ФИО и Емейл автора:
git config --global user.name "Ivan Petrov"
git config --global user.email work@mail"
Админу отсылается файл ~/.ssh/id_dsa.pub для прописывания доступов до репозиториев и серверов.

Получение репозитория

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

git clone ssh://git@СЕРВЕР:ПОРТ/РЕПОЗИТОРИЙ.git

Основные используемые функции

Обновление текущей ветки из центрального репозитория:
git pull
Отправка текущей ветки в центральный репозиторий:
git push origin branchname
Переключение на некоторую ветку:
git checkout branchname
При переключении на ветку, которой еще нет в локальном репозитории, будет создана локальная ветка, связанная с удалённой.
Создание новой ветки, базирующейся на текущей
git checkout -b branchname
Удаление веток
git branch -d branchname == удаление локальной уже слитой ветки
git branch -D branchname == принудительное удаление локальной ветки
git push origin:branchname == удаление ветки с центрального репозитория
Слияние ветки с текущей
git merge --no-ff branchname
Посмотреть какие файлы изменены в текущей директории:
git status
Просмотреть текущие изменения:
git diff
Сохранение текущих изменений:
git add именафайлов == добавить измененные/созданные файлы/директории
git rm именафайлов == добавить удаление файла/директории
git commit == сохранить добавленные изменения. Откроется редактор, чтобы ввести комментарий к коммиту
git commit -a == сохранить все добавленные изменения и все измененные файлы. Позволяет сохранять все изменения, если файлы не добавлялись.

Стандартные процедуры работы

«Начало работы над задачей».
Выполняется перед началом работы над задачей. Дерево должно быть без изменений.
git checkout master
git pull
git checkout -b branchname
«Коммит очередного кусочка работы».
Выполняется после выполнения некого изменения, суть которого целостная.
# проверяем, какие файлы изменились к текущему моменту
# удаляем если что-то попало совсем лишее
git status
# смотрим текст изменений, на предмет соответствия
# правилам ведения чистых коммитов. удаляем, если какой-либо мусор попал
git diff
# если какие-либо файлы не должны попасть в коммит (например,
# относятся к другому атомарному изменению.)
# то помечаем только те файлы, изменения которых нужно сохранить
git add …
git rm …
# сохраняем. -m можно опустить, тогда комментарий через редактор
git commit -m "Some commit message"
# если все на текущий момент созданные изменения нужно сохранить, то
# через git add добавляем новые файлы, а всё остальное сохраняем через
git commit -a -m "Some commit message"
«Отправка ветки на центральный репозиторий»
Выполняется после завершения работы, либо в конце каждого дня (чтобы был бакап на сервере), либо если нужно какие-то изменения показать коллеге.
git push origin branchname
Не следует делать push после каждого коммита, так как это потребует доступа до удалённого сервера, и, соответственно, времени, потраченного впустую.
«Ребейз относительно мастера».
Выполняется перед заливкой на сервер законченной задачи, когда все изменения уже закоммичены:
git checkout master
git pull
git checkout branchname
git rebase master
При возникновении конфликтов, нужно:
(*)
git status == проверить файлы, для которых есть неразрешенные конфликты.
Редактируем первый файл с конфликтом: находим в нем «<<<<<». То, что между <<<<< и ==== – содержит копию текста из master ветки, то что между ===== и >>>>> содержит текст из нашей ветки. Нужно на этом месте оставить одну единую версию, содержащую общий код и мастера и нашей ветки
git add измененный_файл
перейти на (*)
После исправления конфликтов во всех файлах, запускаем
git rebase --continue
Если конфликты несовместимые с дальнейшим продолжением ребейза
git rebase --abort == прерывает ребейз и возвращает ветку в исходное
состояние (до начала ребейза)
После ребейза обновляем состояние ветки в центральном репозитории
git push origin branchname -f
«Кратковременное сохранение состояния изменений».
Выполняется, если требуется временно приостановить работу над текущей веткой на короткое время (например, на ревью, или чтобы сделать какую-либо двухминутную задачу).
git stash save
После этого дерево чисто, можно переключиться на другую ветку/мастер и так далее, поработать, после чего восстановить состояние с помощью
git checkout originalbranch
git stash pop
Тем самым восстановив состояние изменения.
«Длительное сохранение состояния изменений».
Выполняется в конце рабочих суток, чтобы даже частичные изменения были забакаплены; либо при необходимости срочно переключиться на решение другой задачи, которая может занять значительно больше 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 всегда, так как это спасёт от случайных опечаток в названии ветки, например.
«Ревью ветки».
Выполняется на чистом дереве, временно сохраните изменения согласно пункта 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 (или ему подобные сервисы вроде Bitbucket или GitLab) - это по сути хостинг для проектов, использующих git.

Репозиторий

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

Git init

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

Git clone

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

Но если вы крутой чувак и уже работаете с удаленным сервером, то вот такая команда будет для вас в самый раз:

Git clone username@host:/path/to/repository

Лес git’а

Немного теории. Git в своей работе управляет тремя структурами, которые называются деревьями. Первое - это рабочая директория, в ней хранятся файлы, с которыми вы прямо сейчас работаете. Ну, она ж рабочая, логично. Второе - это Index, этакий чек-поинт, который позволяет вам вносить изменения и ничего не портить. А третье - это HEAD, который указывает на последний сделанный вами коммит. (Чтобы вы не запутались в терминологии: коммит (англ. commit) - это сохранение состояния проекта в репозиторий. Короче, считайте, новая версия.)

Так вот, чтобы вы не заблудились в этих трех соснах, запомните две крутые команды: add и commit. Они позволят вашей работе спокойно бродить по git’у, сохраняясь, куда надо. Если вы придумали что-то гениальное и тут же внесли изменение в рабочую копию проекта, то не спешите сразу коммитить! Сначала испытайте в Index’е, для этого выполните:

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

если вы внесли изменение только в один файл, или

Git add *

если вы хорошо потрудились поменяли сразу кучу исходников. Изменения положительны? Хорошо потестили? Тогда скорее коммитить:

Git commit -m "Commit message"

Вы, конечно же, плохой парень и не оставляете комментариев в коде. Но 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 [первые_десять_символов_соответствующего_коммита]

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

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

Git GUI

Входит в комплект git - Запустите git gui из командной строки, а установщик Windows msysgit добавит его в меню "Пуск".

Git GUI может сделать большинство того, что вам нужно сделать с git. Включая изменения сцены, настройте git и репозитории, нажмите изменения, создайте/просмотрите/удалите ветки, слейте и многое другое.

Одна из моих любимых функций - ярлыки "сценарий" и "сценарий" в меню правой кнопки мыши, что позволяет фиксировать определенные части файла. Вы можете достичь того же через git add -i , но мне легче его использовать.

Это не самое приятное приложение, но оно работает практически на всех платформах (основано на Tcl/Tk)

GitK

Также включен в git. Это средство просмотра истории git и позволяет визуализировать историю репозитория (включая ветки, когда они созданы и объединены). Вы можете просматривать и выполнять поиск.

Хорошо сочетается с git -gui.

Gitnub

Приложение Mac OS X. В основном эквивалент git log , но имеет некоторую интеграцию с github (например, "Сетевой вид").

Выглядит красиво и подходит для Mac OS X. Вы можете искать репозитории. Самая большая критика Gitnub заключается в том, что он показывает историю линейным образом (по одной ветки за раз) - она не визуализирует ветвление и слияние, что может быть важно с git, хотя это плановое улучшение.

GitX

Предназначен для "клонирования gitk для OS X".

Он может визуализировать нелинейную историю ветвления, выполнять коммиты, просматривать и выполнять поиск, а также имеет некоторые другие приятные функции, такие как возможность "Quicklook" любого файла в любой редакции (нажмите пробел в представлении списка файлов) экспортировать любой файл (с помощью перетаскивания).

Он намного лучше интегрирован в OS X, чем git-gui / gitk , и является быстрым и стабильным даже при исключительно больших репозиториях.

Оригинальный репозиторий git pieter не обновлялся недавно (более года на момент написания). Более активно поддерживаемая ветвь доступна в brotherbard/gitx - она добавляет "боковую панель, выборку, вытягивание, толчок, добавление удаленного, слияния, выбирать, переустанавливать, клонировать, клонировать до"

SmartGit

На главной странице:

SmartGit - это интерфейс для распределенная система управления версиями Gitи работает на Windows, Mac OS X и Linux. SmartGit предназначен для разработчики, предпочитающие графического пользователя интерфейс через клиент командной строки, быть еще более продуктивным с помощью git - самый мощный DVCS сегодня.

TortoiseGit

Версия TortoiseSVN git для пользователей Windows.

Он переносит TortoiseSVN на TortoiseGit. Последняя версия 1.2.1.0. Эта версия может выполнять обычную задачу, такую фиксацию, журнал показа, разницу двух версий, создавать ветку и тег, создавать патч и т.д. Подробнее см. ReleaseNotes . Добро пожаловать, чтобы внести свой вклад в этот проект.

QGit

QGit - это средство просмотра git GUI, построенное на Qt/С++.

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

gitg

gitg - просмотрщик репозитория gitориентация gtk +/GNOME. Один из основных задача состоит в том, чтобы обеспечить более унифицированный пользовательский интерфейс для Gitинтерфейсы на нескольких рабочих столах. Это это не означает кросс-платформенное приложение, но тесное сотрудничество с аналогичными клиенты для других операционных систем (например, GitX для OS X).

Особенности

Просмотр истории изменений.
Обрабатывать большие репозитории (загружает репозиторий linux, 17000+ ревизий, менее 1 секунды).
Зафиксировать изменения.
Ступени/неустановленные отдельные куски.
Отменить изменения.
Показать расцветку изменений изменений в версиях.
Просмотр дерева для данной версии.
Экспортировать части дерева данной версии.
Поставьте любой refspec, который команда, например "git log", может понять, чтобы построить историю.
Показывать и переключаться между ветвями в виде истории.

Gitbox

Gitbox - графический Mac OS X интерфейс для управления версиями gitсистема. В одном окне вы видите веток, истории и работы статус каталога.

Ежедневные операции легки: этап и нестационарные изменения с помощью флажка. Зафиксировать, вытащить, слить и нажать с помощью один клик. Дважды щелкните изменение на показать diff с FileMerge.app.

Gity

На веб-сайте Gity не так много информации, но на скриншотах там есть полнофункциональный открытый OS X git gui с открытым исходным кодом.

Meld - инструмент визуального разграничения и слияния. Вы можете сравнить два или три файла и редактировать их на месте (diffs update динамически). Вы можете сравнить два или три папки и файл запуска сравнения. Вы можете просматривать и просматривать рабочая копия из популярной версии такие системы управления, как CVS, Subversion, Bazaar-ng и Mercurial [и Git].

Katana

A git GUI для OSX от Steve Dekorte.

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

Бесплатно для 1 репозитория, $25 для более.

Sprout (ранее GitMac)

Ориентация на создание git проста в использовании. Имеет собственный пользовательский интерфейс Cocoa (mac-like), быстрый просмотр репозитория, клонирование, push/pull, разветвление/слияние, визуальный diff, удаленные ветки, легкий доступ к терминалу и т.д.

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