Git commands in linux

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

Моя шпаргалка по работе с 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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удаление untracked files:

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

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

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

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

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

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

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

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

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

Дополнительные материалы

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

Как обычно, любые замечания, дополнения и вопросы категорически приветствуются. И кстати, с наступающим вас!

Источник

Путешествие в мир Linux и Git

Во время пандемии я, честно говоря, не собиралась изучать Linux, не думала, что умение работать в этой ОС сделает меня продуктивнее. Но, как оказалось, Linux-навыки, и правда, помогают мне быстрее справляться с делами. Всё началось с того, что мне посоветовали «взглянуть на Linux». Я тогда подумала, что делать мне, всё равно, нечего, да ещё и сентябрьский выпуск #IBelieveinDoing оказался как раз о Linux.

Я почувствовала, что всё у меня получится, и отправилась в путешествие по миру Linux. В том выпуске #IBelieveinDoing были уроки не только по Linux, но и по Git. Между этими системами можно провести некоторые параллели. Linux — это опенсорсная ОС, которой пользуются программисты, а Git — это система управления версиями, которую применяют для отслеживания изменений в исходном коде при разработке программ. Надо отметить, что изучение Linux и Git оказалось весьма увлекательным занятием. Но Git — довольно сложная система, поэтому и освоить её основы было тяжелее, чем основы Linux.

В этом материале я хочу поделиться с вами тем, что узнала, осваивая Linux и Git.

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

pwd : эта команда применяется для вывода сведения о рабочей директории.

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

cd : данная команда предназначена для смены каталога.

Эксперименты с командами Linux

cp : эта команда предназначена для копирования файлов и папок.

mv : с помощью данной команды можно переименовывать или перемещать файлы и папки.

touch : эта команда применяется для создания пустых файлов и для изменения временной метки файлов.

cat : данная команда позволяет просматривать содержимое файлов, с её помощью можно создавать копии файлов, присоединять содержимое одних файлов к другим.

tree : эта команда позволяет выводить сведения о директориях в древовидном формате. Команда, по умолчанию, выводит сведения о папках и файлах и информацию о количестве файлов и папок в выведенной ей структуре. Вот пример её использования

Пример использования команды tree

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

echo : эта команда применяется для вывода передаваемых ей данных на экран.

grep : данная команда предназначена для работы с текстовыми данными. В частности, она позволяет выполнять поиск строк.

tail : с помощью этой команды можно вывести 10 последних строк файла.

Примеры использования команд grep и cat

awk : эта команда предназначена для работы с соответствующей утилитой, которая даёт в наше распоряжение мощные средства по обработке строк, возможности которых сравнимы с возможностями, имеющимися в полноценных языках программирования.

В Linux можно пользоваться конвейерами, представляющими собой однонаправленные каналы, с помощью которых можно организовывать взаимодействие процессов. При описании конвейеров используют символ ( | ). С использованием этого символа можно, например, направить выходные данные одной команды на вход другой.

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

ssh : данная команда позволяет работать с ssh-клиентом, который используется для подключения к удалённым системами и для выполнения команд на них. Протокол SSH направлен на организации безопасного взаимодействия компьютеров.

rm : эта команда используется для удаления файлов и папок. Например, её вызов в виде rm file приводит к удалению файла, а в виде rm -r director y — к удалению директории и всего её содержимого.

Структура директорий Linux

В Linux используется древовидная структура директорий. Начало этой иерархической структуры находится в корневой директории. В эту директорию вложены все остальные директории. Для разделения имён директорий при указании путей к файлам и папкам используется прямая косая черта ( / ).

Вот как может выглядеть структура файловой системы в Linux-системе.

Структура директорий в Linux

Вот — характеристика некоторых важных папок.

Путь к директории	Примечания
	Корневая директория.
	Директория, в которой хранятся материалы пользователя.
	Тут хранятся файлы, необходимые для запуска Linux.
	Здесь находятся исполняемые файлы.
	Содержит различные файлы, используемые системой и установленными в ней программами. Это могут быть файлы журналов, базы данных, кешированные материалы веб-страниц.

Абсолютная и относительная адресация

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

Относительные пути задаются относительно текущей директории.

Эксперименты по работе с путями

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

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

Примеры использования особых относительных путей

Мягкие и жёсткие ссылки на файлы

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

Жёсткая ссылка представляет собой ссылку на то место жёсткого диска, где расположен файл. Система считает файл существующим до тех пор, пока есть хотя бы одна жёсткая ссылка на него. Фактически, если у файла есть несколько жёстких ссылок, это можно сравнить с тем, что у файла есть несколько имён.

Для создания жёстких и мягких ссылок на файлы используется команда ln . Вот пример создания с её помощью символической ссылки:

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

Поведением команд Linux можно управлять, передавая им при их вызове аргументы (ключи, опции, флаги) командной строки. Они обычно выглядят как дефис ( — ), за которым идёт однобуквенное имя ключа (такая конструкция может выглядеть, например, как -a ). Они могут выглядеть и как два дефиса ( — ), за которыми идёт более длинное имя ключа (вроде —all ).

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

Справка по команде ls

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

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

Например, команда ls часто используется с ключом -l , который позволяет вывести подробные сведения о содержимом директории.

Использование команды ls -l

На предыдущем изображении вы могли заметить конструкции вида drwxr-xr-x . Это — описание прав доступа к файлам.

Права доступа к файлам

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

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

1. Первый символ указывает на то, с чем именно мы имеем дело. А именно, если здесь стоит знак ( — ), то перед нами — файл. Буква ( d ) указывает на директорию. Буква ( l ) — на ссылку.
2. Три следующих символа позволяют узнать о том, какими разрешениями по работе с данным файлом обладает его владелец: r — чтение, w — запись, x — выполнение. Полный набор разрешений представлен последовательностью rwx , если некое разрешение отсутствует, вместо него в соответствующей позиции ставится символ ( — ).
3. Следующая последовательность из трёх символов указывает на то, какие разрешения на работу с файлом есть у группы пользователей (как правило, у группы владельца файла). Её содержимое читается по тем же правилам, что и описание прав владельца файла.
4. Последняя последовательность из трёх символов, устроенная так же, как две предыдущих, описывает права всех пользователей кроме его владельца и тех пользователей, которые входят в группу файла.

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

Поговорим о некоторых особенностях настройки прав доступа к файлам с помощью chmod . Так, для назначения некоего разрешения всем пользователям используются конструкции, похожие на вышеописанную +x . Оператор ( + ) применяется для добавления разрешений, оператор ( — ) позволяет убирать разрешения, оператор ( = ) используется для установки определённых прав для пользователя-владельца файла ( u , user), для группы ( g , group), для остальных пользователей ( o , others) и для всех пользователей ( a , all). Делается это в конструкциях вида chmod u=rwx,g=rx,o=rx filename .

При назначении разрешений часто используют их запись в числовом виде. Определённым правам соответствуют восьмеричные коды. Так, x соответствует код 1 , w соответствует код 2 , а r соответствует код 4 . Код 0 соответствует полному отсутствию разрешений на работу с файлом. Права на файл описываются трёхзначным числом, порядок цифр в котором соответствует вышеописанному порядку расположения групп разрешений. То есть — первая цифра описывает разрешения владельца файла, вторая — разрешения группы, третья — разрешения остальных пользователей. Каждая из этих цифр представляет собой сумму кодов разрешений r , w и x .

Например, команда вида chmod 444 filename означает, что все будут иметь право лишь на чтение файла ( r—r—r— ), а команда вида chmod 700 filename указывает на то, что у владельца будет право чтения, записи и запуска файла ( rwx, 4+2+1 ), а никто другой не имеет права выполнять с файлом никаких действий ( rwx—— ).

Работа с Git

При работе с Git обычно используется следующая последовательность действий:

1. Модификация файла в локальной рабочей директории.
2. Индексирование файлов (команда git add ).
3. Сохранение слепка проиндексированных данных во внутренней базе данных ( git commit ).
4. Отправка изменений из локального репозитория в удалённый ( git push ).
5. Загрузка изменений из удалённого репозитория в локальный ( git pull ).

Вот схема, иллюстрирующая данную последовательность действий.

Типичная последовательность действий, используемая при работе с Git

Файлы при работе с Git могут пребывать в различных состояниях.

• Untracked (неотслеживаемый) — это файл, за изменениями которого Git не наблюдает. Этот файл может быть добавлен в индекс и оказаться в состоянии Staged.
• Unmodified (немодифицированный) — файл, за которым организовано наблюдение, но содержимое которого не менялось. Если удалить этот файл, наблюдение за ним прекратится. Если его изменить — он перейдёт в состояние Modified.
• Modified (изменённый) — файл, за которым организовано наблюдение, содержимое которого изменилось. Он может быть подвергнут индексированию и переведён в состояние Staged.
• Staged (проиндексированный) — это файл, за которым осуществляется наблюдение, и который был включён в индекс. Соответствующие изменения могут быть включены в базу данных Git.

Рассмотрим некоторые команды Git.

git init : эта команда создаёт в директории пустой Git-репозиторий. Это — первый шаг, выполняемый при создании нового репозитория. После выполнения этой команды можно пользоваться командами git add и git commit .

Команда git init

git add : данная команда добавляет файлы в индекс. Она поддерживает, в виде git add . , добавление в индекс всех непроиндексированных файлов, в виде git add filename — добавление в индекс конкретного файла, в виде git add dirname — добавление в индекс директории.

Команда git add

git commit : эта команда записывает изменения в локальный репозиторий. Эти изменения называют, по аналогии с именем команды, «коммитами». У каждого коммита имеется уникальный идентификатор, что облегчает работу с коммитами.

Команда git commit

git status : эта команда позволяет получить сведения о текущем состоянии репозитория.

Команда git status

git config : данная команда позволяет настраивать Git. Среди настроек Git можно отметить user.name и user.email . Они содержат имя пользователя и адрес его электронной почты, используемые в коммитах и указывающие на то, кто их сделал. Если при вызове команды git config используется флаг —global — настройки применяются ко всем локальным репозиториям. Без этого флага настройки применяются только к текущему репозиторию.

Команда git config

git checkout : эта команда применяется для переключения между ветками репозитория (в виде git checkout
). С её помощью можно создать новую ветку и переключиться на неё ( git checkout -b ).

git merge : эта команда позволяет объединять ветки репозитория. Она берёт изменения, имеющиеся в одной ветке, и включает их в состав другой ветки. Например, есть ветка, в которой работают над новой возможностью проекта. После того, как работа над этой возможностью будет завершена, изменения переносят в ветку, хранящую стабильные возможности.

git clone : данная команда используется для создания локальной рабочей копии удалённого репозитория. При её выполнении производится загрузка материалов удалённого репозитория на компьютер. Клонирование существующего репозитория сопоставимо с созданием нового репозитория командой git init . Но при клонировании в нашем распоряжении оказывается репозиторий, в котором уже что-то есть, а при выполнении команды git init — пустой репозиторий.

git pull : эта команда предназначена для загрузки свежих данных из удалённого репозитория.

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

Итоги

Я рассказала вам обо всём, что узнала во время моего путешествия в мир Linux и Git. Это было очень увлекательно. Надеюсь, вам захочется сделать нечто подобное и изучить что-то новое, что-то такое, что расширит ваши профессиональные горизонты.

Если вы недавно освоили что-то интересное — просим об этом рассказать.

Источник