Еще один важный практический вопрос при работе с Git - это операции с файлами.
В частности, это операции удаления и переименования файлов. В системе Git имеются специальные команды, которые очень похожи на консольные команды
1
rm
и
1
mv
в Linux/Mac OS. Но для Git они выглядят несколько иначе:
1
git rm
- для удаления файлов и
1
git mv
- для переименования файлов. Ниже я рассмотрю обе эти комадны более подробно.
Команда git rm
Для удаления файлов в системе Git, как уже упоминалось выше, имеется специальная команда
1
git rm
. Ее отличие от обычной консольной команды
1
rm
(в том же Linux) заключается в особенности самой системы Git.
Как хорошо известно, в системе Git файл может одновременно существовать в трех ипостасях: в области “Working Directory”, в области “Staging Area”, в области “Repository”. Удаление файла из области “Working Directory” не приведет к его удалению из областей “Staging Area” и “Repository”.
Поэтому, чтобы удалить файл, нужно (в идеале) выполнить три команды подряд для удаления файла из Рабочей области “Working Directory”, затем из области индекса “Staging Area” и потом из области репозитория “Repository”:
является ни чем иным, как “вшитым” в Git сокращением двух первых команд:
$rmindex.html$gitadd.
Сделано это всего лишь для удобства пользования системой Git. Давайте на примере посмотрим работу команды
1
git rm
. Предположим, что имеется файл
1
index.html
, который проиндексирован и зафиксирован.
Удалим его командой
1
git rm
:
Видим, что файл
1
index.html
был сразу удален из двух областей: рабочего каталога “Working Directory” и области индексации “Staging Area”. Но в репозитории файл все же остался, о чем говорит вывод команды
1
git status
.
Любой последующий commit зафиксирует удаление этого файла:
Команда git rm -cached
У команды
1
git rm
имеется пара полезных ключей, одним из которых является ключ
1
--cached
. Задача этого ключа - позволить команде
1
git rm
удалить файл из области индексирования “Staging Area”, но при этом оставить его в области рабочего проекта “Working Directory”. Давайте рассмотрим пример, когда создан файл
1
second.html
и произведена его индексация (но не фиксация):
Удалим его командой
1
git rm --cached
:
Отлично! Видим, что произошло удаление файла
1
second.html
. Кроме того, команда
1
git status
показывает, что в рабочей области “Working Directory” имеется неотслеживаемый (untracked) файл по имени
1
second.html
.
Команда git rm -f
В предыдущем разделе я рассмотрел вариант, когда созданный и проиндексированный файл удаляется из области индексирования “Staging Area”, но остается в области “Working Directory”. Выполняется это с помощью команды
1
git rm --cached
.
Логическим продолжением этой команды является та же самая команда
1
git rm
, но с ключом
1
-f
-
1
git rm -f
. Такая команда удаляет проиндексированный (но еще не зафиксированный) файл как из области “Staging Area”, так и из области “Working Directory”.
Давайте рассмотрим на примере созданного и проиндексированного файла
1
third.html
его удаление с помощью команды
1
git rm -f
:
Файл
1
third.html
удален как из области “Staging Area”, так и из области “Working Directory”. В итоге можно сказать, что между командой
1
git rm -f
и командой
1
git rm
практически нет никакой разницы.
Команда git mv - перемещение или переименование файлов
В системе Git имеется “своя” команда для перемещения или переименования файлов. Слово “своя” здесь не даром взято в кавычки - аналогия с командой
1
git rm
полная. Команда
1
git mv
перемещает или переименовывает файлы, автоматически “уведомляя” об этих событиях область “Staging Area”:
Остается только зафиксировать эти изменения любым коммитом:
$gitcommit-m'Move index.html to papka'[master868d428]Moveindex.htmltopapka1filechanged,0insertions(+),0deletions(-)renameindex.html=>papka/index.html(100%)
Переименуем файл
1
index.html
с помощью команды
1
git mv
:
Вот и все несложные операции по перемещению\переименованию или удалению файлов с помощью команд
Продолжаю открывать для себя возможности системы Git и сервиса GitHub.
Уже сейчас, обладая минимальными базовыми знаниями Git и владея учетной записью на сервере GitHub, я не представляю, как я мог жить раньше без обоих этих вещей. Это действительно удобно и надежно!
Благодаря им я знаю, что у меня никогда и ничто не потеряется; и все, что нужно - у меня всегда под рукой. На работе поработал над чем-либо - отправил на GitHub; домой пришел - “стянул” наработки с GitHub и продолжил работу с прерванного места.
Вот на последнем я хотел бы остановиться подробнее. Конечно, веб-разработчик, давно и хорошо знакомый с Git и GitHub, может только улыбнуться насчет того, чем я собираюсь поделиться. Настолько все это просто и понятно. Но это просто и понятно для него, опытного web-разработчика. А для начинающего веб-программиста - это новое и неизведанное. Впрочем, достаточно лирики - переходим к практике.
GitHub - команда push
В предыдущей статье я познакомился с возможностью создания репозитория на сервисе GitHub. И возможностью клонирования этого репозитория на локальную машину - “GitHub и Git - создание и работа с репозиторием”.
Напомню, что в том примере было произведено клонирование репозитория с помощью команды:
$gitclonegit@github.com:gearmobile/arbeit.git
Другими словами, было произведено копирование существующего репозитория с удаленного сервера на локальную машину. Причем, копирование как есть - полностью весь репозиторий, со всеми его файлами, коммитами, индексами и тому подобным.
После внесений изменений в локальный репозиторий - индексации и фиксации - необходимо было отправить произведенные изменения на удаленный сервер, на GitHub.
Для этой цели существует (и я ею воспользовался) команда
1
push
(отправить). К примеру, давайте я внесу еще кое-какие изменения в локальном репозитории, затем проиндексирую и зафиксирую их, а затем отправлю на GitHub:
$gitadd.$gitcommit-m'Continue write article about push and pull in GitHub'[master5af3abc]ContinuewritearticleaboutpushandpullinGitHub1filechanged,18insertions(+)$gitstatusOnbranchmasterYourbranchisaheadof'origin/master'by1commit.(use"git push"topublishyourlocalcommits)nothingtocommit,workingdirectoryclean$gitpush...Countingobjects:7,done.Deltacompressionusingupto4threads.Compressingobjects:100%(4/4),done.Writingobjects:100%(4/4),1.65KiB|0bytes/s,done.Total4(delta1),reused0(delta0)Togit@github.com:semenencko/articles022b756..5af3abcmaster->master
Вот - все наработки, которые я сделал на домашнем компьютере, оказались с считанные секунды помещенными на сервере GitHub, под бдительным оком Git.
GitHub - команда pull
Продолжим логическую картину моего рабочего процесса (workflow). На следующий день я прихожу на работу и у меня есть время и возможность поработать над своим проектом. Естественно, я хочу продолжить с того места, на котором остановился дома. Для этого я воспользуюсь командой
1
pull
, чтобы “стянуть” с GitHub последние изменения.
В данном случае команда
1
pull
будет выглядеть так:
В выводе консоли (на картинке) видно, что было произведено добавление одного измененного файла по имени README.md, в котором были добавлены две строки.
Обратите внимание на разницу между командами
1
clone
и
1
pull
в данном случае. Команда
1
clone
копирует весь репозиторий целиком, как есть - со всеми его файлами. Команда
1
pull
копирует разницу между удаленным и локальным репозиторием. Эту разницу можно назвать дельта или patch.
В результате вышеприведенной команды в считанные секунды я получаю на рабочем компьютере точную копию того проекта, над которым работал дома. И могу продолжать с того места, на котором остановился.
GitHub - команда fetch
Существует разновидность команды
1
pull
- это команда
1
fetch
. И одна, и вторая команда выполняют одинаковые задачи - получение patch удаленного репозитория. Но делают они это по разному.
Команда
1
pull
получает patch репозитория и автоматически производит слияние удаленной и локальной ветвей репозитория. Если произойдет конфликт слияния, то только в этом случае слияния не произойдет и решать конфликт придется вручную.
Команда
1
fetch
также производит получение patch удаленного репозитория. Но при этом автоматического слияния ветвей удаленного и локального репозиториев не происходит:
На картинке выше показано, что была выполнена команда
1
git fetch
после того, как на стороне сервиса GitHub было произведено редактирование файла README.md. Однако, последующая команда
1
git status
показала, что изменения есть, но они не слиты с локальной ветвью репозитория. И порекомендовала выполнить команду
1
git pull
, чтобы произвести такое слияние.
Помимо этого, имеются изменения в локальном репозитории, которые не проиндексированы и не зафиксированы. Что же, исправляю ситуацию - последовательно ввожу команды:
Как новичок в работе с системой GitHub, столкнулся с вопросом - как удалить созданный на GitHub репозиторий?
Оказалось, что ничего сложного в этом нет. Однако, задача эта и не такая простая, как может показаться. По крайней мере, чисто интуитивно у меня не получилось ее выполнить - пришлось искать ответ в Сети.
Итак, у меня есть учетная запись на GitHub, под которой создана пара репозиториев. Один из этих репозиториев был создан в учебных целях, поэтому для моей дальнейшей работы он мне не пригодиться и его можно удалить.
Список репозиториев на GitHub
Для начала открою свою страничку на GitHub и посмотрю, какие репозитории у меня уже есть:
Один из репозиторев -
1
arbeit
- можно удалить.
Для этой цели нужно просто зайти в него по ссылке:
В правом нижнем углу окна браузера, в списке, имеется строка
1
Settings
. Открываем ее, сразу же копируем имя репозитория в поле
1
Repository name
(оно нам понадобиться еще здесь) и прокручиваем страницу вниз, пока не находим раздел с устрашающим названием
1
Danger Zone
. В этой опасной зоне находим подраздел
1
Delete this repository
с одноименной кнопкой
1
Delete this repository
.
Жмем на эту кнопку и получаем в результате окно с предупреждением об удаленни репозитория. В окне запроса имени удаляемого репозитория вводим (или вставляем из буфера обмена) -
1
arbeit
:
Снова жму на кнопку, на этот раз с еще более страшным напоминанием о последствиях совершаемого мною шага. И все! Репозиторий
1
arbeit
удален:
Ничего сложного, но так сразу и не догадаешься, что нужно делать. Разработчики GitHub постарались и обезопасили пользователей от случайного удаления репозиториев с данными.
Данная статья является попыткой осмыслить (в первую очередь для себя, конечно) такой вопрос, как создание git-репозитория на GitHub, клонирование этого репозитория на локальный компьютер, внесение изменений в клонированный репозиторий, отправка изменений обратно на GitHub.
Вот такие получаются шаги, которые нужно осветить. Profit у всех этих сложностей, описанных мною выше, один - но большой! Заключается он в том, что проект, над которым вы работаете (даже в гордом одиночестве) находится на удаленном сервере, к которому можно подключиться из любого места и с любой машины. Так как он находиться на remote server, то с ним ничего не случиться, даже если ваша машина упадет\утонет\разобьется.
В статье большая часть времени будет посвящена автоматизации процесса авторизации на сервисе GitHub с помощью такой вещи, как ssh-ключи. Такие ключи предназначены как раз для возможности авторизации пользователя на каком-либо сервисе, без необходимости каждый раз вводить логин\пароль. Естественно, на стороне сервиса должна быть настроена такая возможность - на GitHub она настроена и даже является почти обязательным условием настройки аккаунта.
Все действия, описанные в этой статье, будут производиться под операционной системой Linux Mint 17 Cinnamon, в консоли. Поэтому пользователи Mac OS X найдут для себя почти все идентичным. Система Windows остается в стороне.
Создание SSH-ключей под Linux
Первоначально необходимо создать (если их еще нет) ssh-ключи, которые будем использоваться для авторизации на GitHub. В системе Linux такие ключи расположены в домашней директории пользователя и выглядят примерно так:
$ls~/.sshid_rsaid_rsa.pubknown_hosts
Один из этих ключей
1
id_rsa
- это приватный ключ, который должен храниться только у пользователя. Другой ключ
1
id_rsa.pub
- это публичный ключ, который предоставляется всем и который я отправлю на GitHub. Представленные выше имена ключей являются создаваемыми по умолчанию, но можно указать и свои собственные.
Если показанная выше команда “скажет” вам, что директории
1
.ssh
не существует, то это означает, что у вас с системе установлен пакет SSH, отвечающий за создание и обработку ssh-ключей.
Установка пакета SSH
Под Linux Mint его нужно установить командой:
$sudoapt-getinstallssh
Создание пары ssh-ключей
Теперь можно приступать к созданию пары ssh-ключей. Выполняется это командой:
$ssh-keygen-trsa-C"g***e@gmail.com"
Чтобы было немного понятно, что это я сделал в данной команде, немного расшифрую ее. Утилита
1
ssh-keygen
входит в комплект пакета
1
ssh
и предназначена для одной цели - создания ssh-ключей. Часть команды -
1
-t rsa
- указывает, что необходимо создать ssh-ключи типа
1
rsa
.
Обязательный параметр
1
"g***e@gmail.com"
- электронный адрес, к которому “привязывается” создаваемый ssh-ключ; данный email будет также использоваться мною для регистрации на GitHub.
Как только будет введена представленная выше команда, утилита
1
ssh-keygen
запросит имя файла и местоположение для создаваемых ssh-ключей. Можно ничего не вводить, а просто нажать Enter. В этом случае программулька создаст и положит их по пути по умолчанию (который показан ею в скобочках):
- это пароль к создаваемым ssh-ключам. Каждый раз, когда придется использовать эти ключи, нужно вводить данный пароль. Это обезопасит их в случае кражи. В качестве пароля можно использовать любую текстовую строку.
Под операционную систему Linux имеется консольная утилита
1
xclip
, которая умеет получать содержимое любого файла и отправлять это содержимое в буфер обмена, и все это в консоли. По умолчанию такой утилиты нет в системе (в том числе и у меня), поэтому первоначально установлю ее:
$sudoapt-getinstallxclip
… а затем передам ей на вход содержимое публичного ключа
1
id_rsa.pub
, который буду применять на сервисе GitHub:
$xclip-selclip<~/.ssh/id_rsa.pub
Если вам, уважаемый читатель, такой путь покажется слишком сложным, то можно открыть файл
1
id_rsa.pub
в любом редакторе кода и скопировать его содержимое в буфер обмена.
Добавление ssh-ключа на GitHub
Переходим на сервис GitHub и создаем на нем новую учетную запись. Описывать процесс создания такой записи на GitHub не буду, так как там все просто. Более интересный момент - это добавление ssh-ключа в профиль пользователя GitHub.
Для этого нажимаю на значок шестеренки в правом верхнем углу окна браузера - настройки профиля пользователя. В открывшемся окне (в его левой части) находим строку
1
SSH key
и нажимаем ее:
Откроется окно для добавления новых ssh-ключей в учетную запись пользователя на GitHub. Здесь все элементарно просто - нажимаем кнопку
1
Add SSH key
. В поле
1
Title
вводим название (произвольное) для импортируемого ssh-ключа.
В поле
1
Key
просто нажимаем Ctrl+V - содержимое буфера обмена (которое я получил ранее с помощью утилиты
1
xclip
) вставиться в это поле:
Жму на зеленую кнопку
1
Add key
внизу окна. Ключ добавлен на GitHub и появиться в списке SSH-ключей:
Проверка SSH-соединения с GitHub
В предыдущих шагах мною были созданы пара ssh-ключей, а также учетная запись на GitHub. В эту учетную запись был импортирован публичный ssh-ключ. Теперь неплохо было бы проверить, что все шаги пройдены мною успешно и ssh-связь с сервисом GitHub устанавливается. Проще сказать - что сервис GitHub авторизует меня у себя с помощью ssh-ключей.
Для этой цели ввожу команду:
$ssh-Tgit@github.comTheauthenticityofhost'github.com (192.30.252.131)'can't be established.
RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
Are you sure you want to continue connecting (yes/no)? yes
На ошибку в строке
1
The authenticity of host 'github.com (192.30.252.131)' can't be established.
не стоит обращать внимание. В запросе командной строки печатаем
1
yes
и получаем:
Warning:Permanentlyadded'github.com,192.30.252.131'(RSA)tothelistofknownhosts.Higearmobile!You've successfully authenticated, but GitHub does not provide shell access.
Отлично! GitHub “узнал” меня и поприветствовал в строке
1
Hi gearmobile! You've successfully authenticated, but GitHub does not provide shell access.
. Это говорит о том, что ssh-соединение моей машины с GitHub установлено успешно и GitHub авторизует меня.
Создаем новый репозиторий на GitHub. Ввожу новое уникальное имя для репозитория, краткое его описание и включаю галочку “Initialize this repository with a README”:
Отлично! На GitHub я только что создал новый репозиторий
1
arbeit
. Теперь можно скопировать (склонировать) его на свою локальную машину командами:
доступны шаблоны, с помощью которых можно задать маски для выборки необходимых типой файлов. Однако, обширная тема шаблонов выходит за рамки данной статьи. При желании можно почитать по теме шаблонов в книге “Pro Git - профессиональный контроль версий”.