Руководство для начинающих по Git: что такое журнал изменений и как его создать

Когда дело доходит до систем контроля версий, очень немногие могут затмить GIT в актуальности, производительности и распространенности. GIT был разработан Линусом Торвальдсом в 2005 году, и сегодня, миллионы компаний используют его для эффективного управления кодом и контроля над версиями своих проектов. Программное обеспечение с открытым исходным кодом может быть загружено для различных платформ, таких как Linux, Windows, Solaris и Mac; больше информации об основах GIT можно получить здесь. В этом руководстве вы узнаете основные GIT команды. 

Описание

Git является распределенной системой для управления версиями разрабатываемых файлов. Создана она была в 2005 году автором ОС Linux. Эта система осуществляет синхронизацию работы с сайтом, а также сохраняет и обновляет изменения в файлах. Это очень удобный подход в случае работы над проектом нескольких разработчиков. На сегодняшний день во многих известных проектах используется именно Git. Что такое использование дает? К примеру, разработкой операционной системы Android занимается большое число программистов. Было бы крайне неудобно, если бы один из них вносил изменения, а другие об этом не знали. Git же позволяет всем быть в курсе всех изменений, а в случае ошибок вернуться к предыдущим версиям файлов.

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

Следующие четыре команды предназначены для копирования файлов между рабочей директорией, сценой, также известной как «индекс», и историей, представленной в форме коммитов.

• git add файлы копирует файлы в их текущем состоянии на сцену.
• git commit сохраняет снимок сцены в виде коммита.
• git reset — файлы восстанавливает файлы на сцене, а именно копирует файлы из последнего коммита на сцену. Используйте эту команду для отмены изменений, внесённых командой git add файлы. Вы также можете выполнить git reset, чтобы восстановить все файлы на сцене.
• git checkout — файлы копирует файлы со сцены в рабочую директорию. Эту команду удобно использовать, чтобы сбросить нежелательные изменения в рабочей директории.

Вы можете использовать git reset -p, git checkout -p, и git add -p вместо имён файлов или вместе с ними, чтобы в интерактивном режиме выбирать, какие именно изменения будут скопированы.

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

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

Использование слепков, а не патчей

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

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

Преимущественно локальные операции

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

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

Наблюдение за целостностью данных

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

Данные чаще всего добавляются

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

Состояния файлов

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

• Зафиксированное, то есть файл сохранен в локальном хранилище.
• Измененное, когда правки были внесены, но сохранение еще не выполнено.
• Подготовленное – измененные файлы, которые отмечены для сохранения.

Так, в проектах, в которых используется Git, имеется три раздела для разных состояний файлов:

• Каталог Git, где хранятся метаданные, а также база данных объектов. Эта часть системы самая важная.
• Рабочий каталог, который является извлеченной из базы данных копией какой-то версии проекта.
• Файл, содержащий информацию о последующем сохранении.

Устанавливаем Git

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

• Установка Git из исходников.
• Установка пакета для используемой платформы.

Установка Git из исходников

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

Для установки понадобятся необходимые библиотеки: expat, curl, libiconv, openssl, zlib. После их инсталляции можно загрузить последнюю версию системы контроля версий, скомпилировать ее и установить.

Установка в операционной системе Windows

Если у пользователя нет Linux, а хочется использовать Git, Windows также поддерживает эту систему. И установить ее очень просто. Существует проект msysGit, процедура установки которого является одной из самых простых. Необходимо просто загрузить файл инсталлятора, который можно найти на странице проекта в GitHub, а затем запустить его. По окончании установки на компьютере будет две версии – графическая и консольная.

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

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

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

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

Пользовательское имя

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

Если указать опцию –global, такие настройки нужно будет сделать один раз.

Выбор текстового редактора

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

Проверка параметров

Чтобы знать основы Git, необходимо уметь проверять используемые настройки. Для этого применяется команда git config –list. Она выводит все доступные параметры, которые сможет найти. Некоторые имена настроек могут присутствовать в списке несколько раз. Это происходит из-за того, что Git считывает один ключ из различных файлов. В такой ситуации для каждого ключа используется последнее значение. Есть возможность проверять значения определенных ключей, вписав в команду вместо «–list» – «{ключ}».

Строим репозитории

В первую очередь нужно понять что такое git-репозиторий? Ответ очень прост: это набор файлов. Папка `.git`. Важно понимать, что это только набор файлов и ничего больше. Раз 20 наблюдал проблему у коллег с авторизацией в github/gitlab. Думая, что это часть git-системы, они пытались искать проблему в конфигруации git, вызывать какие-то git-команды.
А если это просто файлы, то к ним нужно как-то получить доступ, иметь возможность оттуда читать и туда писать? Да! Я называю это «транспортом». Это может и некорректно, но мне так было удобно запомнить. Более правильный вариант: «Протокол передачи данных». Самые распространённые варианты:

1. FILE — мы имеем прямой доступ к файлам репозитория.
2. SSH — мы имеем доступ к файлам на сервере через ssh.
3. HTTP(S) — используем http в качестве приёма/передачи.

Вариантов намного больше. Не важно какой транспорт будет использован, важно чтобы был доступ на чтение или чтение/запись к файлам.
Поэтому, если вы никак не можете клонировать репозиторий с github, и нет в логах никаких подсказок, возможно у вас проблема с транспортом.
В частности, при клонировании вот так:
git clone git@github.com:user/repo.git
урл «превращается» в
git clone ssh://git@github.com:user/repo.git
Т.е. используется SSH и проблемы нужно искать в нём. Как правило, это неправильно настроенный или не найденный ssh-ключ. Гуглить надо в сторону «SSH Auth Key git» или, если совсем по взрослому, проверить, что же происходит:
ssh -vvv git@github.com
Какие протоколы поддерживаются поможет справка (раздел GIT URLS):
git clone –help
Репозиторий можно клонировать, но для начала поиграемся со своими:

1. Придумаем свой удалённый репозиторий
2. Сделаем два клона с него, от имени разработчиков (dev1 и dev2)

Кроме самого репозитория есть ещё и workspace, где хранятся файлы с которыми вы работаете. Именно в этой папке лежит сам репозиторий (папка .git ). На серверах рабочие файлы не нужны, поэтому там хранятся только голые репозитории (bare-repo).
Сделаем себе один (будет нашим главным тестовым репозиторием):
$ mkdir git-habr #создадим папку, чтоб не мусорить $ cd git-habr $ git init –bare origin Initialized empty Git repository in /home/sirex/proj/git-habr/origin/
Теперь клонируем его от имени разработчиков. Тут есть только один нюанс, которого не будет при работе с сервером: git, понимая, что репозитории локальные и находятся на одном разделе, будет создавать ссылки, а не делать полную копию. А нам для изучения нужна полная копия. Для этого можно воспользоваться ключом –no-hardlinks или явно указать протокол:
$ git clone –no-hardlinks origin dev1 Cloning into ‘dev1’… warning: You appear to have cloned an empty repository. done. $ git clone –no-hardlinks origin dev2 Cloning into ‘dev2’… warning: You appear to have cloned an empty repository. done.
Итог: у нас есть 3 репозитория. Там ничего нет, зато они готовы к работе.

Создание в данном каталоге

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

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

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

Удаленный доступ и его особенности

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

Управление удаленным репозиторием в Git

Ниже рассмотрен процесс работы с удаленными хранилищами в Git. Обычно пользователям системы приходится делиться рядом коммитов, а не одним набором изменений. Вместо того, чтобы отправлять набор изменений из рабочей копии в центральный репозиторий, Git позволяет разработчикам обмениваться целыми ветвями между отдельными хранилищами. У каждого пользователя может быть несколько репозиториев, каждый из которых обычно доступен только для чтения или чтения и записи. Сотрудничество с другими людьми предполагает управление этими удаленными репозиториями. Именно для этого нужна команда для удаленного доступа — git remote. Она является одной из частей более широкой системы, отвечающей за синхронизацию изменений.

Особенности удаленного доступа

Записи, зарегистрированные при помощи команды удаленного доступа, используются в сочетании с командами git remote push, fetch и pull. Как git fetch, так и git pull можно использовать для чтения из удаленного репозитория. Команда git remote позволяет создавать, просматривать и удалять подключения к другим репозиториям. Например, push используется для того, чтобы поместить данные в хранилище, а pull, наоборот, чтобы получить. Команда fetch нужна, чтобы извлечь всю информацию, отсутствующую на локальной копии, из удаленного репозитория. После ее выполнения создаются ссылки на все новые ветки, в которых находятся недостающие данные. То есть обновления не сливаются с текущим проектом, а располагаются отдельно.

Впоследствии данные нужно будет сливать вручную, если возникнет такая необходимость. Для автоматического извлечения и соединения репозиториев используется git remote pull. Удаленные подключения больше напоминают закладки, чем прямые ссылки в другие репозитории. Вместо предоставления доступа в режиме реального времени они служат удобными именами, которые могут использоваться для ссылки на не очень удобный URL-адрес.

Команда удаленного доступа по сути является интерфейсом для управления списком записей, которые находятся в файле ./.git/config. Она нужна для управления удаленными хранилищами, удаления несуществующих, отслеживания определенных веток и смены адресов удаленных репозиториев (git change remote).

Отображение удаленных хранилищ

По умолчанию Git удаляет список ранее сохраненных удаленных подключений к другим репозиториям. При этом создается строка, в которой будут указаны имена удаленных репозиториев. Вызов git remote с параметром -v покажет список имен закладок репозитория и, кроме того, соответствующие им URL-адреса. Опция -v означает verbose. Команда git remote add создаст новую запись соединения в удаленном репозитории. После того как удаленная запись была настроена при помощи команды удаленного доступа, ее имя может быть передано другим командам Git для связи с хранилищем.

Конфигурация команды удаленного доступа

Ниже рассмотрены варианты использования команды для управления репозиториями. Простая запись git remote выдает список удаленных подключений. Существует несколько ее конфигураций. Команда удобна для внесения изменений в файл ./.git/config. Также его можно редактировать и вручную при помощи текстового редактора. Команда для удаленного доступа Git является одной из тех, что принимает дополнительные “подкоманды”.

Варианты “подкоманд”:

1. Команда “git remote add ” используется для создания нового подключения к удаленному репозиторию. После добавления удаленного управления появляется возможность использовать как удобный ярлык для в других командах. Эта подкоманда принимает параметр -f, который добавляет имя ветви сразу после создания удаленной записи. А также параметр –tags”, который немедленно извлекает <имя> и импортирует каждый тег из удаленного репозитория.
2. Еще одна команда git remote rm позволяет удалить соединение с удаленным репозиторием. Она изменяет /.git/config и удаляет файл с именем . Если затем выполнить эту команду с префиксом remote_test, можно увидеть, что запись больше не существует.
3. Запись git remote rename переименовывает удаленное соединение. При этом сначала указывается старое имя, а затем — новое. Чтобы изменить удаленный URL-адрес репозитория, необходимо обновить конфигурационный файл новым URL-адресом. В противном случае вы получите сообщение об ошибке.
4. Команда get-url выводит URL-адреса для удаленного доступа. При добавлении параметра – all будут перечислены все URL-адреса доступных удаленных хранилищ.

Всякие полезности

Git позволяет настраивать aliasы для различных команд. Это бывает очень удобно и сокращает время набора команд. Приводить здесь примеры не буду, в Интернете их полно, просто поищите.
Перед тем, как отдавать свои изменения их можно перестроить на самих себя, чтобы привести историю в порядок.
Например, в логах может быть такое:
9982f7b Finally make test works b21f8a5 Fixed typo in Test 3eabaab Fixed typo in Test e514869 Added Test for Foo b4439a2 Implemented Method for Foo 250adb1 Added class Foo
Перестроим сами себя, но начиная с 6 коммитов назад:
dev2(dev)$ git rebase -i dev~6 # т.к. нам всё равно отдавать это в origin/dev мы можем перестроить прямо на него dev2(dev)$ git rebase -i origin/dev
Теперь в интерактивном режиме можно объединить (squash) первые два коммита в один и последние четыре. Тогда история будет выглядеть так:
0f019d0 Added Test for class Foo a3ae806 Implemented class Foo
Такое намного приятнее передавать в общим репозиторий.
Обязательно посмотрите, что умеет git config и git config –global. Перед тем, как начнёте работать с реальным проектом, неплохо было бы настроить свой username и email:
git config –global user.name sirex git config –global user.email jsirex@gmail.com
На одном проекте у нас велась параллельная разработка очень многих фич. Они все разрабатывались в отдельных ветках, но тестировать их нужно было вместе. При этом на момент выпуска билда для тестирования не было понятно, готовы фичи или нет: могли поменяться требования или найтись серьёзные баги. И стал вопрос: как продолжить работу над всеми фичами не объединяя их в принципе никогда, но объединяя всё перед релизом? Противоречие? Git красиво помогает решить эту проблему и вот как:

1. для выпуска билда была создана отдельная ветка, куда все фичи мержились (git merge –no-ff)
2. ветка отдавалась на тестирование
3. разработка продолжалась в своих ветках
4. новые изменения опять объединялись (git merge –no-ff)
5. Если тестируемую временную ветку просто удалить, все связанные коммиты с ней исчезнут и история опять распадётся на много отдельных веток. А их потом можно снова пересобрать
6. Когда какая-то фича абсолютна готова к релизу, только её одну можно перестроить на dev и протолкнуть в релиз.
7. Операция с остальными, неготовыми ветками, повторяется

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

Удалить из системы любой файл можно, если исключить его из индекса, то есть из отслеживаемых файлов. Для этого нужна команда git rm. Она также убирает файл из рабочего каталога пользователя. Затем нужно выполнить коммит. После него файл попросту исчезнет и отслеживаться больше не будет. Если же он изменен и уже проиндексирован, то применяют принудительное удаление с параметром -f. Такой способ предотвратит удаление тех данных, которые еще не записались в снимок состояния и которые нет возможности восстановить из системы.

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

В любой момент может появиться необходимость в отмене какого-либо действия. Если пользователь выполнил коммит рано, забыв внести некоторые файлы, то можно перевыполнить его, используя опцию –amend. Такая команда использует для коммита индекса. Если после выполнения последнего сохранения не производилось никаких изменений, то проект будет в таком же состоянии, и появится редактор для комментариев, где пользователь сможет отредактировать все, что нужно. Нужно помнить, что не каждую операцию отмены можно будет отменить. Иногда можно безвозвратно удалить необходимые данные. Следует быть внимательными.

Переключение веток

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

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

Иногда команду git checkout можно спутать с командой git clone. Разница между этими двумя командами заключается в том, что при клонировании (clone) выполняется извлечение кода из удаленного репозитория, тогда как при переключении (checkout) происходит переключение между версиями кода, который уже находится в локальной системе.

Использование: существующие ветки

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

$> git branch master another_branch feature_inprogress_branch $> git checkout feature_inprogress_branch

В вышеприведенном примере показано, как просмотреть список доступных веток с помощью команды git branch и переключиться на конкретную ветку (в данном случае — на ветку feature_inprogress_branch).

Новые ветки

Команда git checkout часто используется вместе с командой git branch . С помощью команды git branch можно создать новую ветку. Когда вы захотите начать работу над новой функцией, создайте новое ответвление от ветки master с помощью команды git branch new_branch. Затем переключитесь на новую ветку с помощью команды git checkout new_branch. Команда git checkout также принимает аргумент -b, который действует как вспомогательный метод, позволяя создать новую ветку и сразу переключиться на нее. Вы можете работать сразу с несколькими функциями в одном репозитории, переключаясь между ними с помощью git checkout.

git checkout -b В вышеприведенном примере одновременно создается ветка и сразу же выполняется переключение на нее. Опция -b — это удобный способ сообщить системе Git, чтобы она выполнила команду git branch перед выполнением команды git checkout .git checkout -b По умолчанию команда git checkout -b создает ветку new-branch от текущего указателя HEAD. Команде git checkout можно передать необязательный параметр — еще одну ветку. В вышеприведенном примере передается , поэтому ответвление new-branch будет создано от ветки existing-branch, а не от текущего указателя HEAD.

Переключение веток

Переключение веток — простая операция. При выполнении следующей команды указатель HEAD будет перенесен на последний коммит ветки .git checkout

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

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

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

git fetch –all

В современных версиях Git переключение на удаленную ветку не отличается от переключения на локальную ветку.

git checkout

В более старых версиях Git необходимо создать новую ветку на основе удаленной (remote).

git checkout origin/

Кроме того, можно переключиться на новую локальную ветку и сбросить ее до последнего коммита удаленной ветки.

git checkout -b git reset –hard origin/

Открепленные указатели HEAD

Теперь, когда мы рассмотрели три основных варианта использования команды git checkout на ветках, важно обсудить состояние detached HEAD, или состояние открепленного указателя HEAD. Помните, что HEAD — это указатель на текущий снимок в Git. Сама команда git checkout просто обновляет указатель HEAD, чтобы он ссылался на указанную ветку или коммит. Когда HEAD указывает на ветку, Git молчит, но при попытке переключиться на коммит он переходит в состояние detached HEAD (открепленный указатель HEAD).

Это сообщение предупреждает о том, что вся текущая работа «откреплена» от остальной части вашего проекта. Если вы начнете разрабатывать функцию, находясь в состоянии открепленного указателя HEAD, у вас не будет ветки, которая позволила бы вам вернуться к этой функции. Когда вы неизбежно переключитесь на другую ветку (например, чтобы слить код своей функции), вы уже никак не сможете сослаться на свою функцию:

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

Добавление Git Remote

Удаленный репозиторий должен существовать до того, как вы добавите git remote в ваш локальный репозиторий. Вы можете создать репозиторий в службе хостинга Git, такой как GitHub, GitLab и BitBucket, или на своем частном сервере Git.

Чтобы добавить новый удаленный каталог, перейдите в каталог, в котором хранится ваш репозиторий, и используйте команду git remote add, за которой следует удаленное имя и удаленный URL:

git remote add

Например, чтобы добавить новый remote с именем staging указывающим на git@gitserver.com:user/repo_name.git, введите:

git remote add staging git@gitserver.com:user/repo_name.git

Чтобы убедиться, что новый пульт был успешно добавлен, используйте команду git remote для просмотра списка удаленных соединений:

git remote -v

Вывод будет выглядеть примерно так:

origin https://github.com/user/repo_name.git (fetch) origin https://github.com/user/repo_name.git (push) staging git@gitserver.com:user/repo_name.git (fetch) staging git@gitserver.com:user/repo_name.git (push)

На самом деле команда git remote add изменяет файл репозитория .git/config и новое соединение с удаленным репозиторием.

.git/config… [remote “staging”] url = git@gitserver.com:user/repo_name.git fetch = +refs/heads/*:refs/remotes/staging/*

Вы можете добавить новый remote, отредактировав файл .git/config с помощью текстового редактора, но использовать команду намного проще.

Вот и все. Вы успешно добавили Git remote.

Чтобы перенести ваш код на remote, вы должны использовать:

git push

Чтобы извлечь и извлечь из удаленного использования:

git fetch git pull

15 команд Git, о которых вы, возможно, не знали

1. Изменение последнего коммита

git commit –amend

—amend позволяет добавлять подготовленные (staged) изменения к предыдущему коммиту (например, добавлять забытый файл). Если изменений нет, то —amend даст вам возможность переписать сообщение этого коммита (commit message). А если приписать —no-edit, то наоборот: можно будет внести изменения в сам коммит, не затрагивая commit message.

Узнать больше: git help commit

2. Интерактивное добавление отдельных частей файлов

git add -p

-p (или —patch) позволяет интерактивно выбирать для добавления в коммит части отслеживаемый файлов. Таким образом коммит будет содержать только нужные изменения.

Узнать больше: git help add

3. Интерактивное скрытие отдельных частей файлов

git stash -p

Опцию —patch можно добавлять не только к git-add. Добавленная к git stash, она позволяет интерактивно выбирать части отслеживаемых файлов, которые вы хотели бы скрыть.

Узнать больше: git help stash

4. Скрытие файлов, включая неотслеживаемые

По умолчанию при скрытии файлов неотслеживаемые файлы не учитываются. Чтобы изменить это поведение и включить в stash также и эти файлы, нужно использовать параметр -u. Есть также параметр -a (—all), который позволяет скрывать как неотслеживаемые, так и игнорируемые файлы, но это, вероятно, не то, что вам обычно нужно.

5. Интерактивный «сброс» выбранных частей файлов

git checkout -p

—patch можно также использовать для выборочного сброса частей отслеживаемых файлов. Я задал этой команде псевдоним git discard.

Узнать больше: git help checkout

6. Переключение в предыдущую ветку

git checkout –

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

7. Сброс всех локальных изменений

git checkout .

Если вы уверены, что все ваши локальные изменения можно сбросить, то для одновременного сброса вы можете использовать символ точки. Тем не менее, хорошей практикой будет всегда использовать checkout —patch.

8. Показать изменения

git diff –staged

Эта команда показывает все подготовленные изменения (проиндексированные). Если вы введете просто git diff, будут показаны изменения только в рабочей директории.

Узнать больше: git help diff

9. Локальное переименование веток

git branch -m old-name new-name

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

git branch -m new-name

Узнать больше: git help branch

10. Переименование веток удаленно

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

git push origin :old-namegit push origin new-name

11. Открыть все файлы с конфликтами одновременно

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

git diff –name-only –diff-filter=U | uniq | xargs $EDITOR

12. Что изменилось?

git whatchanged –since=‘2 weeks ago’

Эта команда покажет лог изменений, представленных по каждому коммиту за последние две недели.

13. Удаление файла из последнего коммита

Скажем, вы сделали коммит файла по ошибке. Этот файл можно быстро удалить из последнего коммита путем комбинации команд rm и commit —amend:

git rm –cached git commit –amend

Шпаргалка программиста по работе с 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, вы увеличиваете вероятность того, что кто-то захочет безвозмездно написать патч для вашего open source проекта.

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

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

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

pkg_add -rgit

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

ssh-keygen
cat ~/.ssh/id_rsa.pub

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

cd ~/projects/haskell
git clonegit@bitbucket.org:afiskon/hs-textgen.git
cd hs-textgen

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

echotest> TODO.TXT

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

git add TODO.TXT
git commit-a

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

git push origin

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

git branch new_feature
git checkout new_feature

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

git checkout master

Если вышло что-то хорошее, мержим ветку в master (о разрешении конфликтов рассказано в следующем параграфе):

git commit-a# делаем коммит всех изменений в new_feature
git checkout master # переключаемся на master
git merge new_feature # мержим ветку new_feature

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

git push origin

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

git pull origin

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

Fun fact! Нравится статья? Поддержи автора, чтобы он мог писать больше полезных статей!

Для работы с Git под Windows можно воспользоваться клиентом TortoiseGit. Если память не подводит, для работы ему нужен Git for Windows. Для генерации ключей можно воспользоваться утилитой PuTTyGen. Только не забудьте экспортировать открытый ключ в правильном формате, «Conversions → Export OpenSSH key».

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

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

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

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

git init project-name

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

git config–bool core.bare true

… иначе при git push вы будете получать странные ошибки вроде:

Refusing to update checked out branch: refs/heads/master
By default, updating the current branch in a non-bare repository
is denied, because it will make the index and work tree inconsistent
with what you pushed, and will require ‘git reset –hard’ to match
the work tree to HEAD.

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

git clonegit@bitbucket.org:afiskon/hs-textgen.git

Если хотим пушить один код в несколько репозиториев:

git remote add remotename git@gitlab.example.ru:repo.git

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

git add text.txt

Удалить файл:

git rm text.txt

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

git status

Сделать коммит:

git commit-a-m”Commit description”

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

git commit-a

Замержить все ветки локального репозитория на удаленный репозиторий (аналогично вместо origin можно указать и remotename, см выше):

git push origin

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

git push origin master

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

git push origin HEAD

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

git pull origin

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

git pull origin master

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

git pull origin HEAD

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

git fetch origin

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

git fetch origin master

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

git checkout-b some_branch origin/some_branch

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

git branch some_branch

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

git checkout some_branch

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

git branch# звездочкой отмечена текущая ветвь

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

git branch-a# | grep something

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

git merge some_branch

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

git branch-d some_branch

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

git branch-D some_branch

История изменений:

git log

История изменений в обратном порядке:

git log–reverse

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

git log file.txt

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

git log-p file.txt

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

git log–stat–graph

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

git show d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4

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

git blame file.txt

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

git push origin :branch-name

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

git reset–hard d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4

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

git reset–soft d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4

Попытаться обратить заданный commit:

git revert d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4

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

git diff# подробности см в “git diff –help”

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

git config–global merge.tool vimdiff

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

git config–global mergetool.prompt false

Отображаем табы как 4 пробела, например, в «git diff»:

git config–global core.pager ‘less -x4’

Создание глобального файла .gitignore:

git config–global core.excludesfile ~/.gitignore_global

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

git mergetool

Создание тэга:

git tag some_tag # за тэгом можно указать хэш коммита

Удаление untracked files:

git clean-f

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

git gc

Иногда требуется создать копию репозитория или перенести его с одной машины на другую. Это делается примерно так:

mkdir-p/tmp/git-copy
cd/tmp/git-copy
git clone–baregit@example.com:afiskon/cpp-opengl-tutorial1.git
cd cpp-opengl-tutorial1.git
git push–mirrorgit@example.com:afiskon/cpp-opengl-tutorial2.git

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

Дополнение: Также в 6-м пункте Мини-заметок номер 9 приводится пример объединения коммитов с помощью git rebase, а в 10-м пункте Мини-заметок номер 11 вы найдете пример объединения двух репозиториев в один без потери истории.

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

Более подробно сабмодули и зачем они нужны объясняется в заметке Простой кроссплатформенный OpenGL-проект на C++. Здесь упомянем самое главное.

Добавить сабмодуль:

git submodule add https://github.com/glfw/glfw glfw

Инициализация сабмодулей:

git submodule init

Обновление сабмодулей, например, если после git pull поменялся коммит, на который смотрит сабмодуль:

git submodule update

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

1. Скажите git rm–cached имя_сабмодуля;
2. Удалите соответствующие строчки из файла .gitmodules;
3. Также грохните соответствующую секцию в .git/config;
4. Сделайте коммит;
5. Удалите файлы сабмодуля;
6. Удалите каталог .git/modules/имя_сабмодуля;

Что могу посоветовать

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

Но при работе в команде имеет смысл подумать над такими вещами:

• пушить коммиты почаще, чтобы коллеги быстрее получали доступ к новым изменениям
• пулиться почаще – обратная ситуация, почаще получать свежие изменения
• всегда пультесь с флажком ребейза – git pull –rebase origin master
• не удивляйтесь, что при пуллах и пушах могут возникать подобные ситуации, как мы рассматривали выше
• не стесняйтесь спрашивать коллег, если увидели незнакомую ситуацию
• больше практикуйтесь. Посадите домашний проект на git и работайте с ним

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

В следующем уроке мы узнаем, что такое ветки и будем активно работать с ними. Там мы будем активно использовать git push и git pull, и это поможет закрепить уже пройденный материал.

Спасибо за внимание и до встречи!

[spoiler title=”Источники”]

• https://www.hostinger.ru/rukovodstva/osnovnie-git-komandy
• https://FB.ru/article/278293/git—chto-takoe-git-dlya-nachinayuschih-opisanie
• https://marklodato.github.io/visual-git-guide/index-ru.html
• https://habr.com/ru/post/174467/
• https://FB.ru/article/429161/git-remote-opisanie-poryadok-rabotyi-repozitsii
• https://www.atlassian.com/ru/git/tutorials/using-branches/git-checkout
• https://andreyex.ru/operacionnaya-sistema-linux/kak-dobavit-git-remote/
• https://techrocks.ru/2019/04/03/15-useful-git-commands/
• https://eax.me/git-commands/
• https://webdevkin.ru/courses/git/git-push-pull

[/spoiler]