Git ubuntu как пользоваться

Настройка Git

At the heart of GitHub is an open-source version control system (VCS) called Git. Git is responsible for everything GitHub-related that happens locally on your computer.

С помощью Git

Для работы с Git в командной строке необходимо скачать, установить и настроить Git на компьютере. Также вы можете установить GitHub CLI для работы с GitHub из командной строки. Дополнительные сведения см. в разделе «AUTOTITLE».

Если вы хотите работать с Git локально, но не хотите использовать командную строку, вы можете скачать и установить клиент GitHub Desktop . Дополнительные сведения см. в разделе «AUTOTITLE».

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

• Краткое руководство по репозиториям
• Вилка репозитория
• Управление файлами
• Взаимодействие с сообществом

Настройка Git

1. Установите на устройство с Chrome OS эмулятор терминала, например Termux, из Google Play Маркет.
2. Установите Git из установленного эмулятора терминала. Например, в Termux введите apt install git и затем y при появлении запроса.

Проверка подлинности с помощью GitHub из Git

При подключении к репозиторию GitHub из Git необходимо пройти проверку подлинности в GitHub с использованием протокола HTTPS или SSH.

Примечание. Для проверки подлинности в GitHub можно использовать GitHub CLI для HTTP или SSH. Дополнительные сведения см. в разделе gh auth login .

Подключение по протоколу HTTPS (рекомендуется)

При клонировании по протоколу HTTPS вы можете кэшировать учетные данные GitHub в Git с помощью вспомогательного приложения для управления учетными данными. Дополнительные сведения см. в разделе «[AUTOTITLE» и «Сведения об удаленных репозиториях](/get-started/getting-started-with-git/caching-your-github-credentials-in-git)».

Подключение по протоколу SSH

При клонировании по протоколу SSH необходимо создать ключи SSH на каждом компьютере, который будет использоваться для отправки или извлечения данных из GitHub. Дополнительные сведения см. в разделе «[AUTOTITLE» и «Сведения об удаленных репозиториях](/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent)».

Следующие шаги

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

• Создание репозитория для проекта позволяет хранить код на GitHub. Таким образом вы получаете резервную копию результатов работы, которую можно предоставить другим разработчикам. Дополнительные сведения см. в разделе «Краткое руководство по репозиториям»..
• Создание вилки репозитория позволит вносить изменения в другой репозиторий, не затрагивая исходный. Дополнительные сведения см. в разделе «AUTOTITLE».
• Каждый репозиторий на GitHub принадлежит пользователю или организации. Вы можете взаимодействовать с людьми, репозиториями и организациями, подписавшись на них на GitHub. Дополнительные сведения см. в разделе «AUTOTITLE».
• У GitHub большое сообщество поддержки, где можно обратиться за помощью и поговорить с людьми со всего мира. Присоединиться к беседе можно в GitHub Community.

Как установить и настроить Git на Ubuntu 20.04

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

Автором Git является Линус Торвальдс он является создателям ядра Linux.

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

Из этой статьи вы узнаете как установить и настроить Git на Ubuntu 20.04. Кроме того, изучите основные команды git.

1) Установите Git с помощью APT

Git по умолчанию доступен на Ubuntu 20.04. Вы можете использовать команду apt для установки git из репозитория.

Следующая команда устанавливает последнюю версию, доступную в репозитории APT.

$ sudo apt update

$ sudo apt install git

Проверьте установленную версию Git с помощью:

git версия 2.25.1

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

2) Установите Git из исходного кода

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

Во-первых, установите все пакеты зависимостей Git на вашем Ubuntu 20.04

$ sudo apt install libz-dev libssl-dev libcurl4-gnutls-dev libexpat1-dev gettext cmake gcc

Затем перейдите к зеркалу проекта Git на Github и загрузите последнюю версию файла git tarball .tar.gz . На момент написания этой статьи последней версией была версия v2.30.0. Вы можете скачать его с помощью следующей команды:

Когда загрузка будет завершена, распакуйте исходные файлы в /opt каталог:

Затем перейдите в каталог исходного кода Git:

Далее выполните следующие команды для компиляции и установки Git:

$ sudo make prefix= / usr / local all

$ sudo make prefix= / usr / local install

После завершения установки проверьте версию Git:

Возможно вам будет интересно: Как отменить печать

git версия 2.30.0

Настройка Git

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

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

$ git config —global user.name «Your Name»

$ git config —global user.email «youremail@example.com»

Иногда мы также настраиваем основной редактор, используемый для записи сообщений фиксации, например: using vim as editor.

$ git config —global core. editor » vim»

Параметры конфигурации будут созданы и расположены в ~/.gitconfig файле:

name = Your Name

[core] editor = vim

Некоторые основные команды Git

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

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

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

Инициализированный пустой репозиторий Git в файле / home/ubuntu/foo/.git/

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

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

Для удаленного сервера используйте:

$ git clone username@host: / path/to / repository

Добавьте один или несколько файлов

Чтобы позволить Git отслеживать файлы, вы должны выполнить следующие команды:

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

Вы можете получить статус рабочего дерева, запустив его:

On branch master

No commits yet

Changes to be committed:

(use «git rm —cached …» to unstage)

new file: README

Как сделать

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

$ git commit -m «your commit message»

Ответ команды будет таким:

[master (root-commit) 9a07b1d] Commit message

1 file changed, 0 insertions(+), 0 deletions(-)

create mode 100644 README

Подключение к удаленному репозиторию

Иногда вам нужно подключиться к удаленному репозиторию, расположенному например github или gitlab. Вы можете выполнить следующую команду:

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

Возможно вам будет интересно: Меню Пуск без плиток WINDOWS 8

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

Вывод

Git — это действительно мощный инструмент для совместной работы. В этом учебнике рассмотрены все этапы установки и настройки Git на Ubuntu 20.04.

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

1.5 Введение — Установка Git

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

Примечание

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

Установка в Linux

Если вы хотите установить Git под Linux как бинарный пакет, это можно сделать, используя обычный менеджер пакетов вашего дистрибутива. Если у вас Fedora (или другой похожий дистрибутив, такой как RHEL или CentOS), можно воспользоваться dnf :

$ sudo dnf install git-all

Если же у вас дистрибутив, основанный на Debian, например, Ubuntu, попробуйте apt :

$ sudo apt install git

Чтобы воспользоваться дополнительными возможностями, посмотрите инструкцию по установке для нескольких различных разновидностей Unix на сайте Git https://git-scm.com/download/linux.

Установка на Mac

Существует несколько способов установки Git на Mac. Самый простой — установить Xcode Command Line Tools. В версии Mavericks (10.9) и выше вы можете добиться этого просто первый раз выполнив ‘git’ в терминале.

$ git --version

Если Git не установлен, вам будет предложено его установить.

Если Вы хотите получить более актуальную версию, то можете воспользоваться бинарным установщиком. Установщик Git для OS X доступен для скачивания с сайта Git https://git-scm.com/download/mac.

Рисунок 7. OS X инсталлятор Git

Установка в Windows

Для установки Git в Windows также имеется несколько способов. Официальная сборка доступна для скачивания на официальном сайте Git. Просто перейдите на страницу https://git-scm.com/download/win, и загрузка запустится автоматически. Обратите внимание, что это отдельный проект, называемый Git для Windows; для получения дополнительной информации о нём перейдите на https://gitforwindows.org.

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

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

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

Если вы действительно хотите установить Git из исходников, у вас должны быть установлены следующие библиотеки, от которых он зависит: autotools, curl, zlib, openssl, expat и libiconv. Например, если в вашей системе используется dnf (Fedora) или apt-get (системы на базе Debian), вы можете использовать одну из следующих команд для установки всех зависимостей, используемых для сборки и установки бинарных файлов Git:

$ sudo dnf install dh-autoreconf curl-devel expat-devel gettext-devel \ openssl-devel perl-devel zlib-devel $ sudo apt-get install dh-autoreconf libcurl4-gnutls-dev libexpat1-dev \ gettext libz-dev libssl-dev

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

$ sudo dnf install asciidoc xmlto docbook2X $ sudo apt-get install asciidoc xmlto docbook2x

Примечание

Пользователи RHEL и производных от неё (таких как CentOS или Scientific Linux) должны подключить репозиторий EPEL для корректной установки пакета docbook2X

Если вы используете систему на базе Debian (Debian/Ubuntu/Ubuntu-производные), вам так же понадобится установить пакет install-info :

$ sudo apt-get install install-info

Если вы используете систему на базе RPM (Fedora/RHEL/RHEL-производные), вам так же понадобится установить пакет getopt , который уже установлен в системах на базе Debian:

$ sudo dnf install getopt

К тому же из-за различий имён бинарных файлов вам понадобится сделать следующее:

$ sudo ln -s /usr/bin/db2x_docbook2texi /usr/bin/docbook2x-texi

Когда все необходимые зависимости установлены, вы можете пойти дальше и скачать самый свежий архив с исходниками из следующих мест: с сайта Kernel.org https://www.kernel.org/pub/software/scm/git, или зеркала на сайте GitHub https://github.com/git/git/releases. Конечно, немного проще скачать последнюю версию с сайта GitHub, но на странице kernel.org релизы имеют подписи, если вы хотите проверить, что скачиваете.

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

$ tar -zxf git-2.8.0.tar.gz $ cd git-2.8.0 $ make configure $ ./configure --prefix=/usr $ make all doc info $ sudo make install install-doc install-html install-info

После этого вы можете получать обновления Git посредством самого Git:

$ git clone git://git.kernel.org/pub/scm/git/git.git

2. Основы работы с Git¶

Git (произн. «гит») — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux. На сегодняшний день поддерживается Джунио Хамано.

Система спроектирована как набор программ, специально разработанных с учётом их использования в скриптах. Это позволяет удобно создавать специализированные системы контроля версий на базе Git или пользовательские интерфейсы. Например, Cogito является именно таким примером фронтенда к репозиториям Git, а StGit использует Git для управления коллекцией патчей.

Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки. Как и Darcs, BitKeeper, Mercurial, SVK, Bazaar и Monotone, Git предоставляет каждому разработчику локальную копию всей истории разработки; изменения копируются из одного репозитория в другой.

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

Основы работы с удаленным репозиторием¶

git clone — создание копии (удаленного) репозитория¶

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

Клонируем репозиторий, используя протокол http:

git clone http://user@somehost:port/~user/repository/project.git

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

git clone /home/username/project myrepo

Клонируем репозиторий, используя безопасный протокол ssh:

git clone ssh://user@somehost:port/~user/repository

У git имеется и собственный протокол:

git clone git://user@somehost:port/~user/repository/project.git/

Импортируем svn репозиторий, используя протокол http:

git svn clone -s http://repo/location

-s – понимать стандартные папки SVN (trunk, branches, tags)

git fetch и git pull — забираем изменения из центрального репозитория¶

Для синхронизации текущей ветки с репозиторием используются команды git fetch и git pull.

git fetch — забрать изменения удаленной ветки из репозитория по умолчания, основной ветки; той, которая была использована при клонировании репозитория. Изменения обновят удаленную ветку (remote tracking branch), после чего надо будет провести слияние с локальной ветку командой git merge.

git fetch /home/username/project — забрать изменения из определенного репозитория.

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

git remote add username-project /home/username/project

git fetch username-project — забрать изменения по адресу, определяемому синонимом.

Естественно, что после оценки изменений, например, командой git diff , надо создать коммит слияния с основной:

git merge username-project/master

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

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

git pull

Забрать изменения и метки из определенного репозитория:

git pull username-project --tags

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

git push — вносим изменения в удаленный репозиторий¶

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

Отправить свои изменения в удаленную ветку, созданную при клонировании по умолчанию:

git push

Отправить изменения из ветки master в ветку experimental удаленного репозитория:

git push ssh://yourserver.com/~you/proj.git master:experimental

В удаленном репозитории origin удалить ветку experimental:

git push origin :experimental

В удаленную ветку master репозитория origin (синоним репозитория по умолчанию) ветки локальной ветки master:

git push origin master:master

Отправить метки в удаленную ветку master репозитория origin:

git push origin master --tags

Изменить указатель для удаленной ветки master репозитория origin (master будет такой же как и develop)

git push origin origin/develop:master

Добавить ветку test в удаленный репозиторий origin, указывающую на коммит ветки develop:

git push origin origin/develop:refs/heads/test

Работа с локальным репозиторием¶

Базовые команды¶

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

Команда git init создает в директории пустой репозиторий в виде директории .git , где и будет в дальнейшем храниться вся информация об истории коммитов, тегах — о ходе разработки проекта:

mkdir project-dir cd project-dir git init

git add и git rm — индексация изменений

Следующее, что нужно знать — команда git add . Она позволяет внести в индекс — временное хранилище — изменения, которые затем войдут в коммит. Примеры использования:

индексация измененного файла, либо оповещение о создании нового:

git add EDITEDFILE

внести в индекс все изменения, включая новые файлы:

git add .

Из индекса и дерева проекта одновременно файл можно удалить командой git rm :

git rm FILE1 FILE2

хороший пример удаления из документации к git, удаляются сразу все файлы txt из папки:

git rm Documentation/\*.txt

внести в индекс все удаленные файлы:

git rm -r --cached .

Сбросить весь индекс или удалить из него изменения определенного файла можно
командой git reset :

сбросить весь индекс:

git reset

удалить из индекса конкретный файл:

git reset — EDITEDFILE

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

git status — состояние проекта, измененные и не добавленные файлы, индексированные файлы

Команду git status , пожалуй, можно считать самой часто используемой наряду с
командами коммита и индексации. Она выводит информацию обо всех изменениях,
внесенных в дерево директорий проекта по сравнению с последним коммитом рабочей
ветки; отдельно выводятся внесенные в индекс и неиндексированные
файлы. Использовать ее крайне просто:

git status

Кроме того, git status указывает на файлы с неразрешенными конфликтами слияния и
файлы, игнорируемые git.

git commit — совершение коммита

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

git commit

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

Есть несколько ключей, упрощающих работу с git commit :

git commit -a

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

git commit -m «commit comment»

комментируем коммит прямо из командной строки вместо текстового редактора.

git commit FILENAME

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

git reset — возврат к определенному коммиту, откат изменений, «жесткий» или «мягкий»

Помимо работы с индексом (см. выше), git reset позволяет сбросить состояние проекта до какого-либо коммита в истории. В git данное действие может быть двух видов: «мягкого»(soft reset) и «жесткого» (hard reset).

«Мягкий» (с ключом —soft ) резет оставит нетронутыми ваши индекс и все дерево файлов и директорий проекта, вернется к работе с указанным коммитом. Иными словами, если вы обнаруживаете ошибку в только что совершенном коммите или комментарии к нему, то легко можно исправить ситуацию:

1. git commit — некорректный коммит
2. git reset —soft HEAD^ — переходим к работе над уже совершенным коммитом, сохраняя все состояние проекта и проиндексированные файлы
3. edit WRONGFILE
4. edit ANOTHERWRONGFILE
5. git add .
6. git commit -c ORIG_HEAD — вернуться к последнему коммиту, будет предложено редактировать его сообщение. Если сообщение оставить прежним, то достаточно изменить регистр ключа -с:

git commit -C ORIG_HEAD

Обратите внимание на обозначение HEAD^, оно означает «обратиться к предку последнего коммита». Подробней описан синтаксис такой относительной адресации будет ниже, в разделе «Хэши, тэги, относительная адресация». Соответственно, HEAD — ссылка на последний коммит. Ссылка ORIG_HEAD после «мягкого» резета указывает на оригинальный коммит.

Естественно, можно вернуться и на большую глубину коммитов,

«Жесткий» резет (ключ —hard ) — команда, которую следует использовать с
осторожностью. git reset —hard вернет дерево проекта и индекс в состояние,
соответствующее указанному коммиту, удалив изменения последующих коммитов:

git add . git commit -m «destined to death» git reset --hard HEAD~1 — больше никто и никогда не увидит этот позорный коммит. git reset --hard HEAD~3 — . вернее, три последних коммита. Никто. Никогда!

Если команда достигнет точки ветвления, удаления коммита не произойдет.

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

git revert — отмена изменений, произведенных в прошлом отдельным коммитом

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

Отменяем коммит, помеченный тегом:

git revert config-modify-tag

Отменяем коммит, используя его хэш:

git revert cgsjd2h

Для использования команды необходимо, чтобы состояние проекта не отличалось от состояния, зафиксированного последним коммитом.

git log — разнообразная информация о коммитах в целом

Иногда требуется получить информацию об истории коммитов; коммитах, изменивших
отдельный файл; коммитах за определенный отрезок времени и так далее. Для этих
целей используется команда git log .

Простейший пример использования, в котором приводится короткая справка по всем
коммитам, коснувшимся активной в настоящий момент ветки (о ветках и ветвлении
подробно узнать можно ниже, в разделе «Ветвления и слияния»):

git log

Получить подробную информацию о каждом в виде патчей по файлам из коммитов
можно, добавив ключ -p (или -u):

git log -p

Статистика изменения файлов, вроде числа измененных файлов, внесенных в них
строк, удаленных файлов вызывается ключом —stat :

git log --stat

За информацию по созданиям, переименованиям и правам доступа файлов отвечает ключ
—summary :

git log --summary

Чтобы просмотреть историю отдельного файла, достаточно указать в виде параметра
его имя (кстати, в моей старой версии git этот способ не срабатывает,
обязательно добавлять » — » перед «README»):

git log README

или, если версия git не совсем свежая:

git log — README

Далее будет приводится только более современный вариант синтаксиса. Возможно
указывать время, начиная в определенного момента («weeks», «days», «hours», «s»
и так далее):

git log --since=«1 day 2 hours» README git log --since=«2 hours» README

изменения, касающиеся отдельной папки:

git log --since=«2 hours» dir/

Можно отталкиваться от тегов.

Все коммиты, начиная с тега v1:

git log v1.

Все коммиты, включающие изменения файла README, начиная с тега v1:

git log v1. README

Все коммиты, включающие изменения файла README, начиная с тега v1 и заканчивая тегом v2:

git log v1..v2 README

Интересные возможности по формату вывода команды предоставляет ключ —pretty .

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

git log --pretty=oneline

Лаконичная информация о коммитах, приводятся только автор и комментарий:

git log --pretty=short

Более полная информация о коммитах, с именем автора, комментарием, датой создания и внесения коммита:

git log --pretty=full/fuller

В принципе, формат вывода можно определить самостоятельно:

git log --pretty=format:'FORMAT'

Определение формата можно поискать в разделе по git log из Git Community Book
или справке. Красивый ASCII-граф коммитов выводится с использованием ключа
—graph .

git diff — отличия между деревьями проекта, коммитами и т.д.

Своего рода подмножеством команды git log можно считать команду git diff ,
определяющую изменения между объектами в проекте — деревьями (файлов и
директорий).

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

git diff

Изменения, внесенные в индекс:

git diff --cached

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

git diff HEAD

Предпоследним коммитом:

git diff HEAD^

Можно сравнивать «головы» веток:

git diff master..experimental

или активную ветку с какой-либо:

git diff experimental

git show — показать изменения, внесенные отдельным коммитом

Посмотреть изменения, внесенные любым коммитом в истории, можно командой git show :

git show COMMIT_TAG

git blame и git annotate — команды, помогающие отслеживать изменения файлов

При работе в команде часто требуется выяснить, кто именно написал конкретный
код. Удобно использовать команду git blame , выводящую построчную информацию о
последнем коммите, коснувшемся строки, имя автора и хэш коммита:

git blame README

Можно указать и конкретные строки для отображения:

git blame -L 2,+3 README — выведет информацию по трем строкам, начиная со второй.

Аналогично работает команда git annotate , выводящая и строки, и информацию о
коммитах, их коснувшихся:

git annotate README

git grep — поиск слов по проекту, состоянию проекта в прошлом

git grep , в целом, просто дублирует функционал знаменитой юниксовой
команды. Однако он позволяет слова и их сочетания искать в прошлом проекта, что
бывает очень полезно.

Поиск слова tst в проекте:

git grep tst

Подсчитать число упоминаний tst в проекте:

git grep -с tst

Поиск в старой версии проекта:

git grep tst v1

Команда позволяет использовать логическое И и ИЛИ.

Найти строки, где упоминаются и первое слово, и второе:

git grep -e 'first' --and -e 'another'

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

git grep --all-match -e 'first' -e 'second'

Ветвление¶

git branch — создание, перечисление и удаление веток

Работа с ветками — очень легкая процедура в git, все необходимые механизмы сконцентрированы в одной команде:

Просто перечислить существующие ветки, отметив активную:

git branch

Создать новую ветку new-branch:

git branch new-branch

Удалить ветку, если та была залита (merged) с разрешением возможных конфликтов в текущую:

git branch -d new-branch

Удалить ветку в любом случае:

git branch -D new-branch

Переименовать ветку:

git branch -m new-name-branch

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

git branch --contains v1.2

git checkout — переключение между ветками, извлечение файлов

Команда git checkout позволяет переключаться между последними коммитами (если упрощенно) веток:

checkout some-other-branch

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

checkout -b some-other-new-branch

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

checkout -f some-other-branch

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

checkout -m some-other-branch

Вернуть файл (или просто вытащить из прошлого коммита) позволяет команда вида:

Вернуть somefile к состоянию последнего коммита:

git checkout somefile

Вернуть somefile к состоянию на два коммита назад по ветке:

git checkout HEAD~2 somefile

git merge — слияние веток (разрешение возможных конфликтов)

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

Попробовать объединить текующую ветку и ветку new-feature:

git merge new-feature

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

Например, конфликт возник в файле TROUBLE , что можно увидеть в git status .

Произошла неудачная попытка слияния:

git merge experiment

Смотрим на проблемные места:

git status

edit TROUBLE

Индексируем наши изменения, тем самым снимая метки:

git add .

Совершаем коммит слияния:

git commit

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

git reset --hard HEAD

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

git reset --hard ORIG_HEAD

git rebase — построение ровной линии коммитов

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

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

Предположим, имеется две ветки, master и topic, в каждой из которых было совершенно несколько коммитов начиная с момента ветвления. Команда git rebase берет коммиты из ветки topic и накладывает их на последний коммит ветки master.

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

git-rebase master topic

на master накладывается активная в настоящий момент ветка:

git-rebase master

После использования команды история становится линейной. При возникновении конфликтов при поочередном накладывании коммитов работа команды будет останавливаться, а в проблемные местах файлов появятся соответствующие метки. После редактирования — разрешения конфликтов — файлы следует внести в индекс командой git add и продолжить наложение следующих коммитов командой git rebase —continue . Альтернативными выходами будут команды git rebase —skip (пропустить наложение коммита и перейти к следующему) или git rebase —abort (отмена работы команды и всех внесенных изменений).

С ключом -i ( —interactive ) команда будет работать в интерактивном режиме. Пользователю будет предоставлена возможность определить порядок внесения изменений, автоматически будет вызывать редактор для разрешения конфликтов и так далее.

git cherry-pick — применение к дереву проекта изменений, внесенных отдельным коммитом

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

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

git cherry-pick BUG_FIX_TAG

Ключ -n показывает, что изменения надо просто применить к дереву проекта без индексации и создания коммита

git cherry-pick BUG_FIX_TAG -n

Прочие команды и необходимые возможности¶

Хэш — уникальная идентификация объектов

В git для идентификации любых объектов используется уникальный (то есть с огромной вероятностью уникальный) хэш из 40 символов, который определяется хэшируюшей функцией на основе содержимого объекта. Объекты — это все: коммиты, файлы, тэги, деревья. Поскольку хэш уникален для содержимого, например, файла, то и сравнивать такие файлы очень легко — достаточно просто сравнить две строки в сорок символов.

Больше всего нас интересует тот факт, что хэши идентифицируют коммиты. В этом смысле хэш — продвинутый аналог ревизий Subversion. Несколько примеров использования хэшей в качестве способа адресации:

найти разницу текущего состояния проекта и коммита за номером… сами видите, каким:

git diff f292ef5d2b2f6312bc45ae49c2dc14588eef8da2

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

git diff f292ef5

Иногда хватает и четырех символов:

git diff f292

Читаем лог с коммита по коммит:

git log febc32. f292

Разумеется, человеку пользоваться хэшами не так удобно, как машине, именно поэтому были введены другие объекты — тэги.

git tag — тэги как способ пометить уникальный коммит

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

Кроме этого в git представленные так называемые «легковесные тэги» (lightweight tags), состоящие только из имени и ссылки на коммит. Такие тэги, как правило, используются для упрощения навигации по дереву истории; создать их очень легко.

Создать «легковесный» тэг, связанный с последним коммитом; если тэг уже есть, то еще один создан не будет:

git tag stable-1

Пометить определенный коммит:

git tag stable-2 f292ef5

git tag -d stable-2

git tag -l

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

git tag -f stable-1.1

После создания тэга его имя можно использовать вместо хэша в любых командах вроде git diff , git log и так далее:

git diff stable-1.1. stable-1

Обычные тэги имеет смысл использовать для приложения к коммиту какой-либо информации, вроде номера версии и комментария к нему. Иными словами, если в комментарии к коммиту пишешь «исправил такой-то баг», то в комментарии к тэгу по имени «v1.0» будет что-то вроде «стабильная версия, готовая к использованию».

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

git tag -a stable

Создать обычный тэг, сразу указав в качестве аргумента комментарий:

git tag -a stable -m "production version"

Команды перечисления, удаления, перезаписи для обычных тэгов не отличаются от команд для «легковесных» тэгов.

Относительная адресация

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

git diff master^

Если после «птички» поставить цифру, то можно адресоваться по нескольким предкам коммитов слияния:

найти изменения по сравнению со вторым предком последнего коммита в master; HEAD здесь — указатель на последний коммит активной ветки:

git diff HEAD^2

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

что привнес «дедушка» нынешнего коммита:

git diff master^^

git diff master~2

Обозначения можно объединять, чтобы добраться до нужного коммита:

git diff master~3^~2 git diff master~6

файл .gitignore — объясняем git, какие файлы следует игнорировать

Иногда по директориям проекта встречаются файлы, которые не хочется постоянно видеть в сводке git status . Например, вспомогательные файлы текстовых редакторов, временные файлы и прочий мусор.

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

Пример содержимого такого файла:

#комментарий к файлу .gitignore #игнорируем сам .gitignore .gitignore #все html-файлы. *.html #. кроме определенного !special.html #не нужны объектники и архивы *.[ao]

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

Серверные команды репозитория¶

; git update-server-info : Команда создает вспомогательные файлы для dumb-сервера в $GIT_DIR/info и $GIT_OBJECT_DIRECTORY/info каталогах, чтобы помочь клиентам узнать, какие ссылки и пакеты есть на сервере.

; git count-objects : Проверка, сколько объектов будет потеряно и объём освобождаемого места при перепаковке репозитория.
; git gc : Переупаковка локального репозитория.

Рецепты¶

Создание пустого репозитория на сервере

repo="repo.git" mkdir $repo cd $repo git init --bare chown git. -R ./ cd ../

Импорт svn репозитория на Git-сервер

repo="repo.svn" svnserver="http://svn.calculate.ru" git svn clone -s $svnserver/$repo $repo mv $repo/.git/refs/remotes/tags $repo/.git/refs/tags rm -rf $repo/.git/refs/remotes rm -rf $repo/.git/svn mv $repo/.git $repo.git rm -rf $repo cd $repo.git chown git. -R ./ cd ../

Ссылки¶

• правка коммитов
• Перенос SVN-репозитория в git
• Учебник-введение в git
• Руководство пользователя GIT
• 20 повседневных команд git
• Внутренности git
• Введение в структуру хранилища git
• Практическое введение в git
• Работа с git для начинающих
• Переходим с SVN на Git
• ХХ полезных советов для пользователей Git среднего уровня. Часть 1
• ХХ полезных советов для пользователей Git среднего уровня. Часть 2
• Внешние зависимости в гите: submodule или subtree?
• Командная работа в Git