Cистема контроля версий Git расширенная шпаргалка


Оглавление (нажмите, чтобы открыть):

Git и GitHub: что это такое и в чём разница

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

Что такое система контроля версий?

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

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

Существует три типа СКВ: локальная, централизованная и распределённая.

Локальные системы контроля версий (ЛСКВ)

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

Централизованные системы контроля версий (ЦСКВ)

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

Прим.перев. А ещё в таких системах может быть затруднена одновременная работа нескольких разработчиков над одним файлом.

Распределённые системы контроля версий (РСКВ)

Недостаток ЦСКВ был исправлен в РСКВ, клиенты которых не просто скачивают снимок всех файлов (состояние файлов на определённый момент времени), а полностью копируют репозиторий. Это значит, что у каждого клиента есть копия всего исходного кода и внесённых изменений. В этом случае, если один из серверов выйдет из строя, любой клиентский репозиторий может быть скопирован на другой сервер для продолжения работы. Ещё одним преимуществом РСКВ является то, что они могут одновременно взаимодействовать с несколькими удалёнными репозиториями, что означает, что вы можете параллельно работать над несколькими проектами.

ZIP Service, Москва, можно удалённо, от 100 000 ₽

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

Что такое Git?

Git — распределённая система контроля версий, которая даёт возможность разработчикам отслеживать изменения в файлах и работать совместно с другими разработчиками. Она была разработана в 2005 году Линусом Торвальдсом, создателем Linux, для того, чтобы другие разработчики могли вносить свой вклад в ядро Linux. Git известен своей скоростью, простым дизайном, поддержкой нелинейной разработки, полной децентрализацией и возможностью эффективно работать с большими проектами.

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

Преимущества Git

  • Бесплатный и open-source. Это значит, что его можно бесплатно скачать и вносить любые изменения в исходный код;
  • Небольшой и быстрый. Он выполняет все операции локально, что увеличивает его скорость. Кроме того, Git локально сохраняет весь репозиторий в небольшой файл без потери качества данных;
  • Резервное копирование. Git эффективен в хранении бэкапов, поэтому известно мало случаев, когда кто-то терял данные при использовании Git;
  • Простое ветвление. В других СКВ создание веток— утомительная и трудоёмкая задача, так как весь код копируется в новую ветку. В Git управление ветками реализовано гораздо проще и эффективнее.

Теперь пора разобраться, что такое GitHub и как он работает с Git.

Что такое GitHub?

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

Также GitHub может похвастаться контролем доступа, багтрекингом, управлением задачами и вики для каждого проекта. Цель GitHub — содействовать взаимодействию разработчиков.

К проекту, загруженному на GitHub, можно получить доступ с помощью интерфейса командной строки Git и Git-команд. Также есть и другие функции, такие как документация, запросы на принятие изменений (pull requests), история коммитов, интеграция со множеством популярных сервисов, email-уведомления, эмодзи, графики, вложенные списки задач, система @упоминаний, похожая на ту, что в Twitter, и т.д.

Git — это инструмент, позволяющий реализовать распределённую систему контроля версий, а GitHub — это сервис для проектов, использующих Git.

Шпаргалка по частоиспользуемым коммандам git

Git хорошая штука, не просто хорошая, а очень хорошая. Теперь без Git’a у меня не обходится и дня разработки, как на работе так и для своих проектов. Для разработки использую Bitbucket, на нем, в отличии от GitHub, можно бесплатно размещать как закрытые так и открытые репозитории.

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

Так в чем состоит отличие Git от Subversion

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

Пока разработка идет в рамках своего репозитория, все полностью аналогично Subversion. Мы коммитим и откатываем изменения, создаем, мерджим и удаляем бранчи, разрешаем конфликты и т.д. и т.п. Также предусмотрены команды для работы с репозиториями на удаленных машинах. Например, «git push» означает слияние локальных изменений в удаленный репозиторий, а «git pull» — наоборот, слияние изменений из удаленного репозитория в локальный. Обмен информацией о изменении в репозитории происходит с использованием протокола SSH, но возможно и использование http.

Итого, главные отличия и сходства Git и Subversion:

  1. Git имеет все те же преимущества от использования VCS, что мы используем в Subversion.
  2. Git обладает нормальным шифрованием «из коробки», в Subversion надо изрядно помудохаться.
  3. Понятия основного сервера для Git нет, в отличии от Subversion, где без главного сервера никуда. В следствии этого мы можем не беспокоиться о сохранности наших файлов, когда мы делаем «pull» забывая залить изменения на сервер.
  4. Можно использовать Git только локально. Например, для того, чтобы иметь возможность откатиться к предыдущим версиям файлов или вернуть случайно удаленные.
  5. Git не раскидывает по каталогам служебную информацию (о этот «.svn»), вместо этого она хранится только в корне репозитория («.git»).
  6. Git — модная вещь, знание его в резюме разработчика будет хорошим плюсом в сравнении с другими кандидатами на должность. Конечно если руководство понимает его силу.
  7. Git поддерживают многие хостинги репозиториев (GitHub, BitBucket, SourceForge, Google Code, …) — есть из чего выбрать.
  8. Большой популярностью пользуется GitHub. Используя Git, вы увеличиваете вероятность того, что кто-то захочет безвозмездно написать патч для вашего OpenSource проекта.

Как же начать пользоваться Git’ом?

Для начала создаем пару ssh ключей:

Заходим на Bitbucket, создаем репозиторий под новый проект, а в свойствах аккаунта прописываем свой открытый ssh-ключ. Затем клонируем репозиторий:

Делаем какие-то изменения:

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

Отправляем все сделанные изменения в репозиторий:

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

Работаем с этой веткой. Если ничего хорошего не вышло, возвращаемся к основной ветке (она же «trunk» или «ствол»):

Если вышло что-то хорошее, мерджим ветку в master:

Не забываем время от времени отправлять наш код на BitBucket:

Если мы правим код с нескольких компьютеров, то перед началом работы не забываем «накатить» в локальный репозиторий последнюю версию кода:

Работа в команде мало чем отличается от описанного выше. Только каждый программист должен работать со своей веткой, чтобы не мешать другим программистам. Одна из классических ошибок при начале работы с Git заключается в push’е всех веток, а не только той, с которой вы работали. Вообще я бы советовал первое время перед выполнением каждого push делать паузу с тем, чтобы подумать, что и куда сейчас уйдет.

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

Шпаргалка по командам

Создать новый репозиторий:

Клонировать репозиторий с удаленной машины:

Добавить файл в репозиторий:

Текущее состояние репозитория (изменения, неразрешенные конфликты и тп):

Сделать коммит, введя его описание с помощью $EDITOR:

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

Аналогично предыдущему, но делается пуш только ветки master:

Запушить текущую ветку, не вводя целиком ее название:

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

Аналогично предыдущему, но накатывается только ветка master:

Накатить текущую ветку, не вводя ее длинное имя:

Скачать все ветки с origin, но не мерджить их в локальный репозиторий:

Аналогично предыдущему, но только для одной заданной ветки:

Начать работать с веткой some_branch (уже существующей):

Создать новый бранч (ответвится от текущего):

Переключиться на другую ветку (из тех, с которыми уже работаем):

Получаем список веток, с которыми работаем:

Просмотреть все существующие ветви:

Создать локальную ветку и сопоставить ее с удаленной

Замерджить some_branch в текущую ветку:

Удалить бранч (после мерджа):

Просто удалить бранч (тупиковая ветвь):

История конкретного файла:

Аналогично предыдущему, но с просмотром сделанных изменений:

История с именами файлов и псевдографическим изображением бранчей:

Изменения, сделанные в заданном коммите:

Посмотреть, кем в последний раз правилась каждая строка файла:

Удалить бранч из репозитория на сервере:

Откатиться к конкретному коммиту (хэш смотрим в «git log»):

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

Попытаться обратить заданный commit (но чаще используется branch/reset + merge):

Просмотр изменений (суммарных, а не всех по очереди, как в «git log»):

Используем vimdiff в качестве программы для разрешения конфликтов (mergetool) по умолчанию:

Отключаем диалог «какой mergetool вы хотели бы использовать»:

Разрешение конфликтов (когда оные возникают в результате мерджа):

Удаление untracked files:

«Упаковка» репозитория для увеличения скорости работы с ним:

Получение данных подмодулей:

Получение изменений во всех подмодулях:

Следует отметить, что Git позволяет использовать короткую запись хэшей. Вместо «d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4» можно писать «d8578edf» или даже «d857».

Содержание файла .gitignore для bitrix’a:

Частые ошибки

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


Система контроля версий GIT

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

Особенности системы Git

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

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

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

Установка и настройка

Для установки Git достаточно выполнить в командной консоли команду (для Ubuntu):

Для RPM-ориентированных систем, таких как Red Hat или CentOS:

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

Мастер Йода рекомендует:  Как читают web-пользователи

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

Настройка Git начинается с указания некоторых данных о пользователе, который желает использовать эту СКВ — имя пользователя и электронный адрес:

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

Указанные данные о пользователе Git хранятся в домашнем каталоге в файле .gitconfig, содержимое которого можно просмотреть либо текстовым редактором (nano, vi), либо специальной командой Git:

Теперь можно создать хранилище, которое будет включать в себя, к примеру, каталог /etc:

Инфраструктура нового хранилища создаётся командой git init в каталоге /etc/.git, далее всё содержимое каталога /etc добавляется в список отслеживания изменений Git командой git add . — этот список будет использоваться для выполнения последующих коммитов (синхронизаций). Команда git commit проведёт начальную синхронизацию хранилища и с помощью ключа -m добавит к этому действию сопровождающее сообщение. Если опускать опцию -m, то Git автоматически запустит текстовый редактор для добавления комментария.

Использование Git

Для того, чтобы внести изменения в хранилище проекта, нужно сообщить об этом системе Git уже известной командой git commit, например:

В данном случает коммит сделает только то, что в нём указано — обновит хранилище новым файлом readme.txt, даже если имеются другие изменённые файлы, потому как в команде git commit явно указано имя конкретного файла. Для указания нескольких файлов для коммита можно их просто перечислить.

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

  • Во-первых, если имеется какой-либо файл, стоящий «на учёте» у Git и в то же время этот же файл может модифицироваться самой системой (не Git), т. е. являться служебным, то во время исполнения коммита с ключом -a, этот файл, естественно будет обработан и соответствующая информация также будет обновлена в хранилище. Если в будущем придётся проводить «откат» предыдущего состояния, то будет возвращена и соответствующая предыдущая версия этого служебного файла, что может привести к сбою конфигурации, ведь этот файл является служебным, поддерживается системой и изменения в нём она (система) делает не просто так.
  • Во-вторых, коммит с ключом -a проверяет изменения только тех файлов, которые имеются на учёте, т. е. в так называемом списке «стадийности» Git. Любые другие новые или изменённые файлы учитываться ключом -a не будут.

Чтобы избежать вышеописанных подводных камней стоит оценивать ситуацию вручную используя команду git status. Эта команда выведет информацию о модифицированных и новых файлах. К примеру, если был отредактирован файл readme.txt, а также установлен новый демон, конфигурация для которого содержится в файле /etc/somedaemon/somedaemon.conf, то тогда вывод команды git status может быть следующим:

Новый файл somedaemon.conf не видим для Git внутри поддиректории somedaemon. Файл readme.txt ожидаемо в списке изменённых, однако в этом же списке и файл passwd, который мог быть модифицирован скриптом установки нового демона somedaemon, либо изменения могли быть внесены одним из системных администраторов, который забыл внести соответствующие изменения в хранилище. Чтобы это выяснить, нужно выполнить команду git diff passwd, которая выведет информацию о реальных изменениях для интересующего файла passwd. Если, к примеру, файл passwd был изменён не в результате установки нового демона, т. е. недавних действий, а ещё как-то, то рекомендуется в данном случае выполнить отдельный для данного файла (passwd) коммит:

Когда нужно исключить какие-либо файлы из списка «стадийности» Git, нужно сначала удалить файлы из хранилища:

и далее добавить файл в список игнорирования Git, содержащийся в файле .gitignore:

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

Далее нужно выполнить коммит со всеми сделанными изменениями с помощью команды git commit -a или же поступить по-другому — дать команду git add . — это оправдано в данном случае, поскольку будет создан новый образ хранилища, соответствующий текущему каталогу, а эффект будет тот же:

Следует обратить внимание на то, что файл .gitignore теперь сам учитывается в списке «стадийности» Git. Также важно знать и о том, что Git не отслеживает реальные режимы доступа к файлам, их владельцев и дату/время модификации. Хотя и печатает в выводах соответствующие коды. Не следует использовать Git для восстановления файловых систем со сложной структурой, в которых для корректного функционирования очень важно соблюдение определённых атрибутов файлов.

Откат и сброс изменений в GIT

Если вы запороли проект, но еще не сделали commit, то сбросить изменения можно командой

например создадим файл bad.txt

Теперь удалим изменения

git сообщил нам что мы вернулись к коммиту «Added readme.txt file». Если теперь проверить директорию с помощью команды

Мы увидим что файла bad.txt нет.

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

Отменит 3 последних коммита.

Если вы просто хотите восстановить только один единственный файл, предположим hello.rb, то выполните git checkout

Первая команда восстановит hello.rb до версии хранящейся в индексе, и команда «git diff hello.rb» не покажет отличий. Вторая команда восстановит hello.rb до версии в ревизии HEAD, таким образом обе команды «git diff hello.rb» и «git diff —cached hello.rb» не покажут отличий.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Git для начинающих. Часть 1. Что такое системы контроля версий?

Система контроля версий (Version Control System, VCS) представляет собой программное обеспечение, которое позволяет отслеживать изменения в документах, при необходимости производить их откат, определять, кто и когда внес исправления и т.п. В статье рассмотрены виды VCS, принципы их работы, а также приведены примеры программных продуктов.

Что такое система контроля версий?

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

Для решения таких проблем как раз и используется система контроля версий, она позволяет комфортно работать над проектом как индивидуально, так в коллективе. VCS отслеживает изменения в файлах, предоставляет возможности для создания новых и слияние существующих ветвей проекта, производит контроль доступа пользователей к проекту, позволяет откатывать исправления и определять кто, когда и какие изменения вносил в проект. Основным понятием VCS является репозиторий (repository) – специальное хранилище файлов и папок проекта, изменения в которых отслеживаются. В распоряжении разработчика имеется так называемая “рабочая копия” (working copy) проекта, с которой он непосредственно работает. Рабочую копию необходимо периодически синхронизировать с репозиторием, эта операция предполагает отправку в него изменений, которые пользователь внес в свою рабочую копию (такая операция называется commit) и актуализацию рабочей копии, в процессе которой к пользователю загружается последняя версия из репозитория (этот процесс носит название update).

Централизованные и распределенные системы контроля версий

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

Централизованные системы контроля версий

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

CVS (Concurrent Versions System, Система одновременных версий) одна из первых систем получивших широкое распространение среди разработчиков, она возникла в конце 80-х годов прошлого века. В настоящее время этот продукт не развивается, это в первую очередь связано с рядом ключевых недостатков, таких как невозможность переименования файлов, неэффективное их хранение, практически полное отсутствие контроля целостности.

Subversion (SVN) – система контроля версий, созданная на замену CVS. SVN была разработана в 2004 году и до сих пор используется. Несмотря на многие преимущества по сравнению с CVS у SVN все-таки есть недостатки, такие как проблемы с переименованием, невозможность удаления данных из хранилища, проблемы в операции слияния ветвей и т.д. В целом SVN был (и остается) значительном шагом вперед по сравнению с CVS.

Распределенные системы контроля версий

Распределенные системы контроля версий (Distributed Version Control System, DVCS) позволяют хранить репозиторий (его копию) у каждого разработчика, работающего с данной системой. При этом можно выделить центральный репозиторий (условно), в который будут отправляться изменения из локальных и, с ним же эти локальные репозитории будут синхронизироваться. При работе с такой системой, пользователи периодически синхронизируют свои локальные репозитории с центральным и работают непосредственно со своей локальной копией. После внесения достаточного количества изменений в локальную копию они (изменения) отправляются на сервер. При этом сервер, чаще всего, выбирается условно, т.к. в большинстве DVCS нет такого понятия как “выделенный сервер с центральным репозиторием”.

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

Начнем с Mercurial, эта система представляет собой свободную DVCS, которая построена таким образом, что в ней отсутствует понятие центрального репозитория, для работы с этой VCS используется (как правило) консольная утилита hg. Mercurial обладает всеми возможностями системы контроля версий, такими как ветвление, слияние, синхронизация с другими репозиториями. Данный проект используют и поддерживают большое количество крупных разработчиков, среди них Mozilla, OpenOffice, OpenJDK и многие другие. Сам продукт написан на языке Python и доступен на большинстве современных операционных систем (Windows, Mac OS, Linux), также существует значительное количество утилит с графическим интерфейсом для работы с Mercurial. Основным конкурентом Mercurial на рынке распределенных систем контроля версий является Git, который, на сегодняшний день, выиграл гонку за лидерство.

Git – распределенная система контроля версий, разработанная Линусом Торвальдсем для работы над ядром операционной системы Linux. Среди крупных проектов, в рамках которых используется git, можно выделить ядро Linux, Qt, Android. Git свободен и распространяется под лицензией GNU GPL 2 и, также как Mercurial, доступен практически на всех операционных системах. По своим базовым возможностям git схож с Mercurial (и другими DVCS), но благодаря ряду достоинств (высокая скорость работы, возможность интеграции с другими VCS, удобный интерфейс) и очень активному сообществу, сформировавшемуся вокруг этой системы, git вышел в лидеры рынка распределенных систем контроля версий. Необходимо отметить, что несмотря на большую популярность таких систем как git, крупные корпорации, подобные Google, используют свои VCS.

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

Если вам больше нравится учиться по видео-лекциям, то рекомендуем классный курс по git от GeekBrains , перейдите по ссылке и найдите в разделе “Курсы” курс “Git. Быстрый старт” . Он бесплатный, нужно только зарегистрироваться на сайте. Рекомендуем повнимательнее посмотреть на этот ресурс, на нем ещё очень много чего интересного!

Шпаргалка по Git

Система управления версиями Git довольно хороший, полезный инструмент, эволюционировавший от Subversion, CVS, и других старых систем управления версиями. Она особенно хорошо подходит для распределенной разработки, так как вы можете работать без подключения к центрального серверу.
Git прекрасно документирован, поэтому вы всегда можете найти ответы на возникающие у вас вопросы. Если у вас возник вопрос, начните поиск ответа с документации, прежде чем делать искать в сети — это быстрее, и, кроме того, вы получите более полные ответы.
Мы, в свою очередь, хотим подарить вам небольшую шпаргалку, которая отражает использование Git в типичном цикл разработки.

Основные Git команды: шпаргалка

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

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

С этими задачами призваны справляться системы контроля версий. И одной из них является продукт под названием Git.

Системы контроля версий: немного теории

Если вкратце — любая система контроля версий позволяет сохранять все внесённые в файл проекта изменения. Это дает возможность осуществлять контроль за ошибками в коде и быстрое их устранение.

Условно системы контроля версий можно разделить на три типа:

  • локальные;
  • централизованные;
  • распределенные.

Виды систем контроля версий

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

Централизованные системы контроля версий решили такую актуальную проблему, как работа над проектом силами нескольких разработчиков. Ее суть заключается в том, что файлы хранятся не на локальном компьютере, а на определённом сервере, к которому он подключён. Таким образом, участники проекта могут получать доступ к различным версиям файлов, и становится легче контролировать, кто и чем занят при разработке. Однако если по какой-то причине сервер окажется недоступен или выйдет из строя, то возникнут серьёзные проблемы. Это может усугубится ещё и тем, что не всегда получается восстановить все данные обратно.

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

Git: описание и особенности системы

Система контроля версий Git обладает своими особенностями. Большинство систем хранит файлы, изменяя их в соответствии с инструкциями в проекте. То есть, к примеру, версия текущей разработки под номером 3 может содержать данные об изменениях в файле А и Б. А уже версия 4 будет иметь в себе А, Б и В. Таким образом, файлы меняются по необходимости.

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

Ещё одной важной особенностью является возможность непосредственной работы с локальным хранилищем. То есть если требуется делать правки, то их реализуют прямо на компьютере участника проекта. Это очень удобно, когда разработчик находится вдали от сети Интернет. Затем, при получении доступа к серверу, появится возможность отправить все данные в общее хранилище.

Мастер Йода рекомендует:  Как создать эффект золотого текста в Photoshop

Для сохранения целостности данных применяется метод хеширования каждого изменённого файла методом SHA-1. Это позволяет системе контроля версий точно знать, где, кто и когда изменил файл.

Git: установка

Для того чтобы начать работать с Git, нужно его установить. Система контроля версий доступна для использования в Windows, Mac OS, Linux.

Версию для Windows можно скачать по адресу: git-for-windows.github.io. После загрузки программу нужно установить. Инсталлятор простой, так что эта процедура не должна вызвать проблем.

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

Первые команды

После установки системы контроля версий на компьютер, ее необходимо настроить. Стоит отметить, что к этому моменту на сайте Github должен быть зарегистрирован свой аккаунт. Для того чтобы выполнить первоначальную настройку, нужно вызвать консольный клиент, так как придётся вводить команды. Сделать это можно, нажав правую кнопку мыши и выбрав пункт Git Bash. Должно открыться окно консольного клиента, которое пригласит ввести данные. В нем нужно выполнить последовательно Git Bash команды:

  • git config —global user.name »Имя»;
  • git config —global user.mail »Адрес электронной почты».

На этом же этапе необходимо настроить метод окончания строк с помощью двух команд:

  • git config —global core.autocrlf true;
  • git config —global core.safecrlf false.

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

Основные команды Git

  • Init: данная команда создаёт новый репозиторий.

Пример использования: init имя проекта.


  • Clone. Производит копирование существующего репозитория с удалённого источника.

Вот так используется команда git clone: clone git://github.com/путь к репозиторию.

  • Add. Наиболее часто используемая команда в системе контроля версий Git. Она выполняет простую задачу — добавляет указанные файлы в особую область, именуемую индексом или сценой. В неё можно перенести несколько файлов или папок, которые необходимо будет впоследствии добавить в репозиторий или, выражаясь на языке Git, «закоммитить».

Пример использования этой Git команды выглядит так: add некий_файл.txt.

  • Status. Позволяет просмотреть список файлов, которые присутствуют в индексе и рабочей папке. Служит для контроля и просмотра готовых к коммиту данных или их изменённых, но не внесённых версий в сцену.
  • Diff. Показывает разницу состояний. Например, с помощью этой Git команды можно определить, есть ли изменения между папкой с проектом и индексом.
  • Commit. Выполняет сохранение слепка всего того, что находилось в индексе непосредственно в базу данных. В результате работы Git команды на экране отобразится текстовый файл, в котором можно указать, какие именно изменения были произведены. А также будет выведена информация о том, сколько файлов подверглись коммиту, и его контрольная сумма. Главное — не забывать о том, что после изменения в базу попадут только те данные, которые были занесены в индекс командой git add.

Дополнительные команды Git

  • Reset. О функциях этой команды говорит ее название. Она просто выбрасывает из специальной промежуточной области — индекса, указанный файл, помещённый туда по случайности. Стоит осторожно обращаться с reset при использовании команды с ключом — — hard, так как это затронет и файлы в рабочей папке, что может привести к непредвиденным последствиям.
  • Rm. Наиболее точно эту команду можно описать как обратную git add, так как она удаляет файлы из индекса. Правда, при этом ещё и из рабочей папки.

Пример использования: git rm некий_файл.txt.

  • Mv. Служит для перемещения файла.
  • Clean. Предназначена для очистки папки проекта от ненужных файлов.

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

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

Для управления ветками в Git имеется специальный набор команд. Они способны соединять, удалять, создавать ветвления в Git. Список команд представлен ниже.

  • Branch. У этой команды имеется в наличии несколько ключей, используя которые можно гибко управлять ветками в проекте. Branch представляет собой некий многопрофильный инструмент для полноценного контроля за состоянием репозитория. Простой вызов git branch выдаст перечень всех имеющихся веток хранилища. Ключ -v добавленный к команде отобразит какие коммиты были зафиксированы за последнее время. А использование -d приведёт к удалению указанной ветки. Branch умеет не только удалять, но и создавать. Выполнение git branch имя_ветки приведёт к организации новой ветки в проекте. Стоит учесть, что при этом указатель текущего рабочего положения бывает иным. К примеру, создав имя_ветки, можно на самом деле находится в ветке master.
  • Чтобы переместиться в нужный пункт, существует команда Git checkout нужная_ветка, которая переставит указатель в необходимую ветку.
  • Checkout. Как уже говорилось выше, выполняет переключение.
  • Merge. Данная команда позволяет производить слияние нескольких веток воедино.
  • Log. Функция отображает все изменения от начала проекта и до последнего коммита. Использование разнообразных ключей совместно с вызовом команды позволяет расширить ее функционал. Например, вызов git log -p -2 позволит просмотреть подробную информацию об изменениях в каждом коммите. Второй ключ -2 говорит о том, что нужно показать лишь 2 последних изменения. Аргумент —stat, добавленный к вызову git log, выполнит практически то же самое, что и -р, но в более подробной и при этом компактной форме. Также с помощью git log можно выводить информацию об изменениях, создав собственный формат отображения, используя опции format ключа pretty. Для придания особого вида нужно использовать некое подобие регулярных выражений. Например, такая запись get log —pretty=format »%h, %an, %ar, %s» выведет краткий хэш коммита, затем его автора, дату и комментарий изменения. Это очень удобно использовать при просмотре большого количества коммитов.

Команды для распределенной работы в системе

  • Fetch. При вводе данной команды git консоль выполнит перенос всех изменений с удалённого хранилища в локальное.
  • Pull. Команда git pull представляет собой симбиоз двух перечисленных выше — git fetch и git merge. То есть она сначала получает сведения из удалённого репозитория, а затем выполняет слияние с использующейся в данный момент веткой.
  • Push. Именно от названия этой команды в среде пользователей появилось выражение «запушить», что означает соединение с удаленным репозиторием и передачу туда изменений из локального.

Команды удаленного управления

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

Как использовать данную шпаргалку

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

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

Perl, Python — блог программиста

Шпаргалка по git. Пошаговое руководство: как выполнить слияние веток в git, как создать новую ветку и репозиторий, как выписать ветку с github и т.п. Инструкции по git для начинающих.

Git — это распределенная система контроля версий. Это главное отличие git от svn . Каждый разработчик создает на своем компьютере отдельный, полноценный репозиторий.

В рамках этого репозитория можно делать все тоже самое, что и обычно в svn — создавать ветки, просматривать изменения, выполнять коммиты. Для того, чтобы можно было работать с удаленными репозиториями и обмениваться изменениями с другими разработчиками, в git есть две команды, не имеющие аналогов в svn — git push и git pull .

git push — вливание локальных изменений в удаленный репозиторий. git pull — вливание изменений из удаленного репозитория в локальный. Обмен данными обычно происходит с использованием протокола SSH.

Git поддерживают несколько крупных репозиториев — GitHub , SourceForge , BitBucket и Google Code . Удобно использовать один из них в качестве основного хранилища для корпоративных проектов.

Изображение с сайта http://www.stickycomics.com/where-did-you-meet/

Ниже приведены инструкции по использованию git в различных ситуациях. Что делать, если нужно создать новый репозиторий, или выписать ветку, и т.п. Я использую подобную шпаргалку для скоростного копипаста 🙂 Чтобы не отвлекаться, когда голова занята сложными задачами. По мере создания новых инструкций, статья будет обновляться.

Пошаговые рекомендации

Как выписать репозиторий с github

  1. Создаем новую директорию для проекта project_name , переходим в нее.
  2. Выполняем команду:

Результат: каталог с выписанной веткой master . Теперь можно создавать новые ветки, или выписывать с github существующие.

Как выписать ветку с github

С помощью команды «checkout» можно выписать уже существующую ветку с github:

Или так, что намного надежнее:

Если команда не сработала, нужно попробовать выполнить обновление:

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

Т.е. сначала мы создаем новую ветку, а затем вливаем в нее изменения из ветки на github.

Как создать новую ветку в локальном репозитории

  1. Создаем новую ветку в локальном репозитории:

Как переключиться на другую ветку в git

Если вы случайно удалили какой-то файл, можно извлечь его из хранилища:

Как посмотреть список веток

Команда «branch» позволяет посмотреть список веток в локальном репозитории. Текущая ветка будет помечена звездочкой:

Как сделать commit

Создаем новую ветку, выполняем в ней нужные изменения.

    Список всех измененных и добавленных файлов можно просмотреть командой:

Или удаляем устаревшие файлы:

Как правило, в репозитории существует две основные ветки — dev и master. Dev — общая ветка разработчиков и тестировщиков. Именно в нее добавляются все новые разработки перед очередным релизом. Master — ветка для выкладки продукта на боевые сервера.

После коммита надо влить в нашу ветку изменения из ветки dev и master:

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

Вливаем в dev изменения из ветки проекта:

Заливаем последнюю версию ветки dev на удаленный сервер:

push может не пройти, потому что удалённый origin/dev обогнал локальную его копию.

Как решить конфликт бинарных файлов

Допустим, при слиянии с другой веткой git выдал ошибку. Команда git status возвращает информацию о конфликте:

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

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

Если мы выбираем версию из вливаемой ветки:

» ours » — от английского «наш», » theirs » — от английского «их».

Как посмотреть историю изменений

git log — просмотр логов.

Вывод данных о каждом коммите в одну строку:

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

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

Команда «git show» позволяет просмотреть, какие именно изменения произошли в указанном коммите:


Можно посмотреть построчную информацию о последнем коммите, имя автора и хэш коммита:

git annotate , выводит измененные строки и информацию о коммитах, где это произошло:

Как сделать откат

  1. git log — просмотр логов, показывает дельту (разницу/diff), привнесенную каждым коммитом.

После того, как откат сделан, и выполнен очередной локальный коммит, при попытке сделать push в удаленный репозиторий, git может начать ругаться, что версия вашей ветки младше чем на github и вам надо сделать pull. Это лечится принудительным коммитом:

Как выполнить слияние с другой веткой

git merge выполняет слияние текущей и указанной ветки. Изменения добавляются в текущую ветку.

git pull забирает изменения из ветки на удаленном сервере и проводит слияние с активной веткой.

git pull отличается от git merge тем, что merge только выполняет слияние веток, а pull прежде чем выполнить слияние — закачивает изменения с удаленного сервера. merge удобно использовать для слияния веток в локальном репозитории, pull — слияния веток, когда одна из них лежит на github.

Создание нового локального репозитория

git cherry-pick

git cherry-pick помогает применить один-единственный коммит из одной ветки к дереву другой.

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

Как раскрасить команды git

После создания репозитория в текущей директории появится субдиректория .git . Она содержит файл config .

Чтобы раскрасить вывод git, можно добавить в файл блок [color] :

Полезные ссылки по теме git

Шпаргалка по Git — основные команды, слияние веток, выписка веток с github : 10 комментариев

> git cherry-pick помогает применить один-единственный коммит из одной ветки к дереву другой.

можно и не один, а много коммитов перечислить через проблел

пример: git cherry-pick qw1w2e3 a4s5d5 f6g7h8j8
(последний коммит будет верхним)

У меня с гитом было так.
На первом работе использовали SVN
В ВУЗе я работаю четвертый год над проектом и исторически там SVN
Писал игрушку под андроид и надеялся делать это не один, товарищ подтолкнул к гиту, я попробовал. Потом таки писал один и проклинал гит.
Постепенно привыкал к гиту, хотел прочитать книжку по нему, но руки не доходили (ты знаешь о чем я, ведь твой блог о мотивации xD).
Устроился на новую работу, там меркуриал. Работа работой, но за 3 месяца я прочитал на работе 2 книжки (одни из них Pro GIT) и прошел курс по git.

Но сначала был курс. Я как бы понимал что делаю что-то не так, когда постоянно матерился на гит в проекте с андройдом. Я хотел научиться и нашел курс (ну многие его знают — на githowto). И вот я устроился на работу и у меня появилось 8 часов свободного времени в сутки xD — я конечно прошел курс. Дак вот курс хреновый, он запутывает и не рассказывает как правильно.

Я начал читать книжку Чакона и вот ее я всем советую. Особенно в середине книжке здорово описаны варианты использования гита — из этого хотя бы понятно как его правильно (ну или «более оптимально») использовать в твоем проекте исходя из масштаба проекта. Потому что в гите тьма всяких фич и вот статьи на хабре рассказывают про них, а значит люди пользуются этим. Если кто-то этим пользуется, а я нет, значит я чего-то не понимаю? — вот Чакон пояснил че почем. Это реально нужно, потому что в гите гораздо больше вариантов ведения проекта чем в svn. Ну а также есть куча холиваров на хабре, например по поводу удаленных веток и эти все статьи часто запутывают.

Опять же статьи описывают не все, а книга Чакона — все и сразу. Очень здоровская книга и ее перевели на русский уже.

Но пока я читал книгу, я написал вот такую же шпаргалку как у Вас примерно (но побольше только. ). Потом я забыл ее на работе (( — я ж уволился сразу как дочитал все книги xD.

проконсультируйте пжл что я делаю не правильно.
#!/bin/bash
clear
git status | grep -c «nothing to commit»
read $s
echo $s

Мастер Йода рекомендует:  Кодировка UTF – основной стандарт текста в интернете

echo выводит null

Простите, у меня сейчас нет git на серверах — т.к. для личных нужд он мне пока не был нужен, а устанавливать нет желания. Обычно я не отвечаю на вопросы, если не могу проверить ответ на практике, чтобы быть уверенной в его корректности. 🙁

You should remove $ in fourth line:)

Try smth like that:

#!/bin/bash
clear
git status | grep -c “nothing to commit”
read s
echo $s

Что значит выписать? Все татары кроме я.

Ну можно, наверное, перевести это как «создать копию указанной ветки на локальном компьютере» 🙂

Шикарная шпаргалка, спасибо!

Но сначала был курс. Я как бы понимал что делаю что-то не так, когда постоянно матерился на гит в проекте с андройдом. Я хотел научиться и нашел курс (ну многие его знают – на githowto). И вот я устроился на работу и у меня появилось 8 часов свободного времени в сутки xD – я конечно прошел курс. Дак вот курс хреновый, он запутывает и не рассказывает как правильно.

Я начал читать книжку Чакона и вот ее я всем советую. Особенно в середине книжке здорово описаны варианты использования гита – из этого хотя бы понятно как его правильно (ну или “более оптимально”) использовать в твоем проекте исходя из масштаба проекта. Потому что в гите тьма всяких фич и вот статьи на хабре рассказывают про них, а значит люди пользуются этим. Если кто-то этим пользуется, а я нет, значит я чего-то не понимаю? – вот Чакон пояснил че почем. Это реально нужно, потому что в гите гораздо больше вариантов ведения проекта чем в svn. Ну а также есть куча холиваров на хабре, например по поводу удаленных веток и эти все статьи часто запутывают.

Записки программиста

Моя шпаргалка по работе с Git

28 декабря 2011

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

В чем состоит отличие Git от Subversion?

Главное отличие Git от Subversion заключается в том, что Git — распределенная система контроля версий. Звучит ужасающе, но на практике это означает очень простую вещь. Каждый разработчик держит у себя на диске отдельный репозиторий. Обратите внимание — не копию репозитория, не некоторые бранчи, а тупо отдельный и при этом абсолютно полноценный репозиторий.

Пока мы работаем в рамках своего репозитория, все происходит в точности, как в Subversion. Мы коммитим и откатываем изменения, создаем, мержим и удаляем бранчи, разрешаем конфликты и тд. Помимо этого, предусмотрены команды для работы с репозиториями на удаленных машинах. Например, «git push» означает мерж локальных изменений в удаленный репозиторий, а «git pull» — наоборот, мерж изменений из удаленного репозитория в локальный. Обмен данными по сети обычно происходит с использованием протокола SSH.

В результате имеем:

  • Git присущи все те же преимущества от использования VCS, что мы получаем в Subversion.
  • Git дает нам нормальное шифрование «из коробки», безо всяких танцев с бубнами, как в случае с Subversion.
  • Если сервер с «главным» репозиторием, куда пушат свои изменения все разработчики (хотя формально в Git нет никакого «главного» репозитория), вдруг прилег — ничего страшного. Делаем коммиты в локальный репозиторий и ждем, когда сервер вернется.
  • Даже если сервер доступен, все равно удобнее сделать пяток локальных коммитов, а затем отправить их на сервер одним пушем.
  • Сервер вообще не нужен. Вы можете использовать Git только локально. И не обязательно для работы с исходниками. Например, можно использовать Git для того, чтобы иметь возможность откатиться к предыдущим версиям файлов (каких-нибудь электронных таблиц) или вернуть случайно удаленные.
  • Git не раскидывает по каталогам служебную информацию (помните «.svn»?) , вместо этого она хранится только в корне репозитория.
  • Git нынче очень моден (хотя это далеко не единственная распределенная система контроля версий, например, есть Mercurial и Darcs), в связи с чем растет число разработчиков, использующих его. Как следствие, используя Git, легче получить помощь на каком-нибудь форуме или собрать команду разработчиков, знакомых с этой VCS.
  • Существует множество полезных утилит для работы с Git — Qgit, gitk, gitweb и другие. «Из коробки» есть импорт и экспорт в/из Subversion/CVS.
  • Git поддерживают многие хостинги репозиториев (GitHub, BitBucket, SourceForge, Google Code, … ) — есть из чего выбрать.
  • Большой популярностью пользуется GitHub. Используя Git, вы увеличиваете вероятность того, что кто-то захочет безвозмездно написать патч для вашего OpenSource проекта.

Пример использования Git

Я использовал Git при написании программы из заметки Генерация почти осмысленных текстов на Haskell, сидя под своей любимой FreeBSD. Вот как примерно выглядела моя работа с Git.

В первую очередь необходимо поставить Git:

Затем создаем пару ssh ключей, если не создавали ее ранее:

Git Шпаргалка | Список часто используемых команд

Git Список часто используемых команд

Установка

Рекомендуемые утилиты

Справочник по командам

Первоначальная настройка

Общие команды

  • инициализация
  • добавление к будущему комиту

Работа с удаленными репозиториями

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


  • обновление данных об удаленных ветках

Откаты и восстановления

  • откатить не проиндексированный файл (до добавления в список перед коммита)
  • откатить проиндексированный файл (до коммита)
  • Удаление неотслеживаемых файлов ПРОСМОТР списка удалений
  • Удаление неотслеживаемых файлов + те которые добавлены в игнор ПРОСМОТР списка удалений . осторожно . удалит и файлы настроек, т.к. они всегда в игноре
  • Исправить последний коммит
  • Привести ветку в состояние удаленного репозитория . Осторожно, удалит все локальные коммиты, которых нет в удаленной ветке
  • Удалить последние n коммитов

Специальной команды для этого нет, нужно выполнить ряд действий:

Прятанье источник

  • спрятать изменения без коммита
  • просмотр списка спрятанных изменениц
  • достать спрятанные изменения
  • удалить спрятанные изменения

Работа с ветками

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

Работа с метками (тегами) источник

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

Просмотр логов

  • просмотр лога
  • список коммитов, сделанных за последние две недели
  • поиск по сообщениям коммитов

Сравнение изменений

  • сравнение текущих изменений с последним комитом
  • сравнение комитов между собой
  • просмотр объема правок перед коммитом

Работа с подмодулями

  • привязка подмодуля
  • первичная инициализация подмодулей
  • получение/обновление содержимого подмодулей
  • просмотр списка подмодулей
  • Удаление подмодуля

В случае получения ошибки “already exists in the index” при добавлении подмодуля:

Оптимизация репозитория

  • Очистка логов
  • Запуск сборщика мусора

Материалы для обучения

  • Пошаговый учебник
  • Видеокурс “Git для профессионалов” от http://pr-of-it.ru найдете при желании 🙂
  • Статья о rebase и слиянии веток
  • Обучающие видео http://monsterlessons.com/project/categories/git
  • Полезные алиасы git команд https://habrahabr.ru/company/mailru/blog/318508/?utm_campaign=email_digest&utm_source=email_habrahabr&utm_medium=email_week_20200110&utm_content=link2post
  • Шпаргалка по работе с Git http://eax.me/git-commands/

установка средства сравнения

sudo aptitude install meld

0.2) создаем скрипт питона

/scriptHelpers touch diff.py

0.3) прописываем в настройках гита

git config –global diff.external

/scriptHelpers/diff.py что бы отменить эту настройку используем git config –global –unset diff.external

Проверить что настройки применились git config –list

3) создание репозитория git init

добавление удаленного репозитория к текушему git remote add origin https://github.com/gdecider/tscc.git

проталкивание изменений в удаленный репозиторий git push -u origin master

клонирование репозитория в текущую папку git clone https://github.com/gdecider/tscc.git .

удаление файлов из подготовленных к коммиту git rm –cached если это папка, то добавляем флаг -r для рекурсивного удаления

git reset –hard HEAD git clean -f

Это отбросит все сделанные изменения которые вы возможно добавили в индекс git, а также все другие изменения в вашей рабочем дереве. Другими словами, результат этого — вывод команд “git diff” и “git diff –cached” будет пустым.

About MELD http://meldmerge.org/help/

1) Installing Meld on Ubuntu (http://linuxpitstop.com/install-meld-on-ubuntu-and-mint-linux/)

sudo apt-get update sudo apt-get install meld

или через команды

git config –global diff.tool meld git config –global merge.tool meld . . . и т.д.

— . то что ниже не проверено

git config –global mergetool.meld.trustExitCode false

// Fix git mergetool meld –help error git config mergetool.meld.hasOutput true

Для доступа к репозиторию нужно добавить SSH ключ в настройках аккаунта github https://help.github.com/articles/connecting-to-github-with-ssh/

0) Проверим есть ли ключ на ПК с которого нужно соединиться ls -al

1) Сгенерируем ключ, если нет существующего ssh-keygen -t rsa -b 4096 -C “your_email@example.com”

На вопрос об имени файла можно оставить имя по умолчанию

На вопрос о пароле введите пароль или оставьте его пустым

2) Привязка ключа в аккаунт github Для получения содержимомо ключа выведем его на экран

Копируем то что вывелось в буфер обмена

Можно воспользоваться утилитой xcopy

В Вашем аккаунте GitHub идем в настройки, пункт SSH and GPG keys — New SSH key, вставляем скопированный ключ.

Шпаргалка по частоиспользуемым коммандам git

Git хорошая штука, не просто хорошая, а очень хорошая. Теперь без Git’a у меня не обходится и дня разработки, как на работе так и для своих проектов. Для разработки использую Bitbucket, на нем, в отличии от GitHub, можно бесплатно размещать как закрытые так и открытые репозитории.

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

Так в чем состоит отличие Git от Subversion

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

Пока разработка идет в рамках своего репозитория, все полностью аналогично Subversion. Мы коммитим и откатываем изменения, создаем, мерджим и удаляем бранчи, разрешаем конфликты и т.д. и т.п. Также предусмотрены команды для работы с репозиториями на удаленных машинах. Например, «git push» означает слияние локальных изменений в удаленный репозиторий, а «git pull» — наоборот, слияние изменений из удаленного репозитория в локальный. Обмен информацией о изменении в репозитории происходит с использованием протокола SSH, но возможно и использование http.

Итого, главные отличия и сходства Git и Subversion:

  1. Git имеет все те же преимущества от использования VCS, что мы используем в Subversion.
  2. Git обладает нормальным шифрованием «из коробки», в Subversion надо изрядно помудохаться.
  3. Понятия основного сервера для Git нет, в отличии от Subversion, где без главного сервера никуда. В следствии этого мы можем не беспокоиться о сохранности наших файлов, когда мы делаем «pull» забывая залить изменения на сервер.
  4. Можно использовать Git только локально. Например, для того, чтобы иметь возможность откатиться к предыдущим версиям файлов или вернуть случайно удаленные.
  5. Git не раскидывает по каталогам служебную информацию (о этот «.svn»), вместо этого она хранится только в корне репозитория («.git»).
  6. Git — модная вещь, знание его в резюме разработчика будет хорошим плюсом в сравнении с другими кандидатами на должность. Конечно если руководство понимает его силу.
  7. Git поддерживают многие хостинги репозиториев (GitHub, BitBucket, SourceForge, Google Code, …) — есть из чего выбрать.
  8. Большой популярностью пользуется GitHub. Используя Git, вы увеличиваете вероятность того, что кто-то захочет безвозмездно написать патч для вашего OpenSource проекта.

Как же начать пользоваться Git’ом?

Для начала создаем пару ssh ключей:

Заходим на Bitbucket, создаем репозиторий под новый проект, а в свойствах аккаунта прописываем свой открытый ssh-ключ. Затем клонируем репозиторий:

Делаем какие-то изменения:

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

Отправляем все сделанные изменения в репозиторий:

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

Работаем с этой веткой. Если ничего хорошего не вышло, возвращаемся к основной ветке (она же «trunk» или «ствол»):

Если вышло что-то хорошее, мерджим ветку в master:

Не забываем время от времени отправлять наш код на BitBucket:

Если мы правим код с нескольких компьютеров, то перед началом работы не забываем «накатить» в локальный репозиторий последнюю версию кода:

Работа в команде мало чем отличается от описанного выше. Только каждый программист должен работать со своей веткой, чтобы не мешать другим программистам. Одна из классических ошибок при начале работы с Git заключается в push’е всех веток, а не только той, с которой вы работали. Вообще я бы советовал первое время перед выполнением каждого push делать паузу с тем, чтобы подумать, что и куда сейчас уйдет.

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

Шпаргалка по командам

Создать новый репозиторий:

Клонировать репозиторий с удаленной машины:

Добавить файл в репозиторий:

Текущее состояние репозитория (изменения, неразрешенные конфликты и тп):

Сделать коммит, введя его описание с помощью $EDITOR:

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

Аналогично предыдущему, но делается пуш только ветки master:

Запушить текущую ветку, не вводя целиком ее название:

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

Аналогично предыдущему, но накатывается только ветка master:

Накатить текущую ветку, не вводя ее длинное имя:

Скачать все ветки с origin, но не мерджить их в локальный репозиторий:

Аналогично предыдущему, но только для одной заданной ветки:

Начать работать с веткой some_branch (уже существующей):

Создать новый бранч (ответвится от текущего):

Переключиться на другую ветку (из тех, с которыми уже работаем):

Получаем список веток, с которыми работаем:

Просмотреть все существующие ветви:

Создать локальную ветку и сопоставить ее с удаленной

Замерджить some_branch в текущую ветку:

Удалить бранч (после мерджа):

Просто удалить бранч (тупиковая ветвь):

История конкретного файла:

Аналогично предыдущему, но с просмотром сделанных изменений:

История с именами файлов и псевдографическим изображением бранчей:

Изменения, сделанные в заданном коммите:

Посмотреть, кем в последний раз правилась каждая строка файла:

Удалить бранч из репозитория на сервере:

Откатиться к конкретному коммиту (хэш смотрим в «git log»):

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

Попытаться обратить заданный commit (но чаще используется branch/reset + merge):

Просмотр изменений (суммарных, а не всех по очереди, как в «git log»):

Используем vimdiff в качестве программы для разрешения конфликтов (mergetool) по умолчанию:

Отключаем диалог «какой mergetool вы хотели бы использовать»:

Разрешение конфликтов (когда оные возникают в результате мерджа):

Удаление untracked files:

«Упаковка» репозитория для увеличения скорости работы с ним:

Получение данных подмодулей:

Получение изменений во всех подмодулях:

Следует отметить, что Git позволяет использовать короткую запись хэшей. Вместо «d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4» можно писать «d8578edf» или даже «d857».

Содержание файла .gitignore для bitrix’a:

Частые ошибки

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

Добавить комментарий