Еще один важный практический вопрос при работе с Git - это операции с файлами.

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

1

rm

1

mv

1

git rm

1

git mv

Команда git rm

Для удаления файлов в системе Git, как уже упоминалось выше, имеется специальная команда

1

git rm

1

rm

Как хорошо известно, в системе Git файл может одновременно существовать в трех ипостасях: в области “Working Directory”, в области “Staging Area”, в области “Repository”. Удаление файла из области “Working Directory” не приведет к его удалению из областей “Staging Area” и “Repository”.

Поэтому, чтобы удалить файл, нужно (в идеале) выполнить три команды подряд для удаления файла из Рабочей области “Working Directory”, затем из области индекса “Staging Area” и потом из области репозитория “Repository”:

$ rm index.html
$ git add .
$ git commit -m 'Delete file index.html'

Команда

1

git rm

$ rm index.html
$ git add .

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

1

git rm

1

index.html

Удалим его командой

1

git rm

Видим, что файл

1

index.html

1

git status

Любой последующий commit зафиксирует удаление этого файла:

Команда git rm -cached

У команды

1

git rm

1

--cached

1

git rm

1

second.html

Удалим его командой

1

git rm --cached

Отлично! Видим, что произошло удаление файла

1

second.html

1

git status

1

second.html

Команда git rm -f

В предыдущем разделе я рассмотрел вариант, когда созданный и проиндексированный файл удаляется из области индексирования “Staging Area”, но остается в области “Working Directory”. Выполняется это с помощью команды

1

git rm --cached

Логическим продолжением этой команды является та же самая команда

1

git rm

1

-f

1

git rm -f

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

1

third.html

1

git rm -f

Файл

1

third.html

1

git rm -f

1

git rm

Команда git mv - перемещение или переименование файлов

В системе Git имеется “своя” команда для перемещения или переименования файлов. Слово “своя” здесь не даром взято в кавычки - аналогия с командой

1

git rm

1

git mv

Остается только зафиксировать эти изменения любым коммитом:

$ git commit -m 'Move index.html to papka'
  [master 868d428] Move index.html to papka
   1 file changed, 0 insertions(+), 0 deletions(-)
   rename index.html => papka/index.html (100%)

Переименуем файл

1

index.html

1

git mv

Вот и все несложные операции по перемещению\переименованию или удалению файлов с помощью команд

1

git rm

1

git mv

Продолжаю открывать для себя возможности системы Git и сервиса GitHub.

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

Благодаря им я знаю, что у меня никогда и ничто не потеряется; и все, что нужно - у меня всегда под рукой. На работе поработал над чем-либо - отправил на GitHub; домой пришел - “стянул” наработки с GitHub и продолжил работу с прерванного места.

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

GitHub - команда push

В предыдущей статье я познакомился с возможностью создания репозитория на сервисе GitHub. И возможностью клонирования этого репозитория на локальную машину - “GitHub и Git - создание и работа с репозиторием”.

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

$ git clone git@github.com:gearmobile/arbeit.git

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

После внесений изменений в локальный репозиторий - индексации и фиксации - необходимо было отправить произведенные изменения на удаленный сервер, на GitHub.

Для этой цели существует (и я ею воспользовался) команда

1

push

$ git add .

$ git commit -m 'Continue write article about push and pull in GitHub'
[master 5af3abc] Continue write article about push and pull in GitHub
 1 file changed, 18 insertions(+)

$ git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)
nothing to commit, working directory clean

$ git push
...
Counting objects: 7, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 1.65 KiB | 0 bytes/s, done.
Total 4 (delta 1), reused 0 (delta 0)
To git@github.com:semenencko/articles
   022b756..5af3abc  master -> master

Вот - все наработки, которые я сделал на домашнем компьютере, оказались с считанные секунды помещенными на сервере GitHub, под бдительным оком Git.

GitHub - команда pull

Продолжим логическую картину моего рабочего процесса (workflow). На следующий день я прихожу на работу и у меня есть время и возможность поработать над своим проектом. Естественно, я хочу продолжить с того места, на котором остановился дома. Для этого я воспользуюсь командой

1

pull

В данном случае команда

1

pull

В выводе консоли (на картинке) видно, что было произведено добавление одного измененного файла по имени README.md, в котором были добавлены две строки.

Обратите внимание на разницу между командами

1

clone

1

pull

1

clone

1

pull

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

GitHub - команда fetch

Существует разновидность команды

1

pull

1

fetch

Команда

1

pull

Команда

1

fetch

На картинке выше показано, что была выполнена команда

1

git fetch

1

git status

1

git pull

Помимо этого, имеются изменения в локальном репозитории, которые не проиндексированы и не зафиксированы. Что же, исправляю ситуацию - последовательно ввожу команды:

$ git pull
$ git add .
$ git commit -m 'Added fetch image'
$ git push

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

1

git fetch

Вернувшись к вышесказанному, можно сделать вывод, что команда

1

pull

1

fetch

1

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 ~/.ssh
  id_rsa id_rsa.pub known_hosts

Один из этих ключей

1

id_rsa

1

id_rsa.pub

Если показанная выше команда “скажет” вам, что директории

1

.ssh

Установка пакета SSH

Под Linux Mint его нужно установить командой:

$ sudo apt-get install ssh

Создание пары ssh-ключей

Теперь можно приступать к созданию пары ssh-ключей. Выполняется это командой:

$ ssh-keygen -t rsa -C "g***e@gmail.com"

Чтобы было немного понятно, что это я сделал в данной команде, немного расшифрую ее. Утилита

1

ssh-keygen

1

ssh

1

-t rsa

1

rsa

Обязательный параметр

1

"g***e@gmail.com"

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

1

ssh-keygen

$ ssh-keygen -t rsa -C "g***e@gmail.com"
  Generating public/private rsa key pair.
  Enter file in which to save the key (/home/aaron/.ssh/id_rsa):

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

$ ssh-keygen -t rsa -C "g***e@gmail.com"
  Generating public/private rsa key pair.
  Enter file in which to save the key (/home/aaron/.ssh/id_rsa):
  Enter passphrase (empty for no passphrase):

Здесь

1

passphrase

После успешного ввода

1

passphrase

$ ssh-keygen -t rsa -C "g***e@gmail.com"
  Generating public/private rsa key pair.
  Enter file in which to save the key (/home/aaron/.ssh/id_rsa):
  Enter passphrase (empty for no passphrase):
  Enter same passphrase again:
  Your identification has been saved in /home/aaron/.ssh/id_rsa.
  Your public key has been saved in /home/aaron/.ssh/id_rsa.pub.

В состав пакета

1

ssh

1

ssh-agent

$ eval "$(ssh-agent -s)"
  Agent pid 17461
  $ ssh-add ~/.ssh/id_rsa
  Enter passphrase for /home/aaron/.ssh/id_rsa:
  Identity added: /home/aaron/.ssh/id_rsa (/home/aaron/.ssh/id_rsa)

Можно посмотреть, что утилита

1

shh-add

$ ssh-add -l
  2048 e4:4d:fe:73:cb:b9:bb:ee:26:32:6b:f5:f1:6a:db:38 /home/aaron/.ssh/id_rsa (RSA)

Под операционную систему Linux имеется консольная утилита

1

xclip

$ sudo apt-get install xclip

… а затем передам ей на вход содержимое публичного ключа

1

id_rsa.pub

$ xclip -sel clip < ~/.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

В поле

1

Key

1

xclip

Жму на зеленую кнопку

1

Add key

Проверка SSH-соединения с GitHub

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

Для этой цели ввожу команду:

$ ssh -T git@github.com
  The authenticity of host '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: Permanently added 'github.com,192.30.252.131' (RSA) to the list of known hosts.
Hi gearmobile! 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-соединения возможны и ошибки. В этом случае может помочь статья - Error: Permission denied (publickey).

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

Создаем новый репозиторий на GitHub. Ввожу новое уникальное имя для репозитория, краткое его описание и включаю галочку “Initialize this repository with a README”:

Отлично! На GitHub я только что создал новый репозиторий

1

arbeit

$ mkdir arbeit
$ git clone git@github.com:gearmobile/arbeit.git
  Cloning into 'arbeit'...
  Warning: Permanently added the RSA host key for IP address '192.30.252.130' to the list of known hosts.
  remote: Counting objects: 3, done.
  remote: Compressing objects: 100% (2/2), done.
  remote: Total 3 (delta 0), reused 0 (delta 0)
  Receiving objects: 100% (3/3), done.
  Checking connectivity... done

Переходим в локальную копию репозитория

1

arbeit

$ git add .
$ git commit -m 'Added changes'
$ git push

Команда

1

git commit -m 'Added changes'

1

git push

Вот, таким образом я наладил Git-работу своей машины с GitHub.

В системе Git можно настроить возможность автоматического игнорирования файлов.

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

1

.gitignore

К примеру, если развертывать в проекте Compass, то будет создан каталог

1

.sass

Давайте на практике разберемся, каким образом можно настроить игнорирование файлов в Git с помощью

1

.gitignore

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

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

1

git_ignore

$ mkdir git_ignore
$ cd git_ignore/
$ touch index.html style.css

Инициализирую репозиторий Git в директории

1

.git_ignore

$ git init
Initialized empty Git repository in /home/aaron/Projects/git_ignore/.git/
$ git add .
$ git commit -m 'First Commit'

Вывод команды

1

git status

$ git status
On branch master
nothing to commit, working directory clean

Настройка игнорирования в .gitignore

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

1

.gitignore

$ touch .gitignore

Откроем созданный файл

1

.gitignore

$ nano -w .gitignore

… и пропишем в нем следующие строки:

*.txt
*.md

Тем самым мы говорим Git, что нужно игнорировать все файлы с расширением

1

.txt

1

.md

1

git_ignore

Проиндексируем и зафиксируем изменения (создание файла настроек

1

.gitignore

1

git_ignore

$ touch main.css readme.txt humans.md

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

$ git add .

И смотрю, что мне показывает команда

1

git status

$ git status
  On branch master
  Changes to be committed:
    (use "git reset HEAD <file>..." to unstage)

    new file:   main.css

Система Git увидела только новый файл

1

main.css

1

readme.txt

1

humans.md

Можно создать еще пару файлов в разных директориях и посмотреть на вывод команды

1

git status

Усложнить задачу игнорирования в .gitignore

Можно усложнить задачу игнорирования в Git, добавив в файл

1

.gitignore

1

ignore

1

.ignore

Добавлю в файл

1

.gitignore

$ cat .gitignore
*.txt
*.md
ignore/
.ignore/

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

$ mkdir ignore
$ mkdir .ignore
$ touch ignore/reset.css
$ touch .ignore/normilize.css

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

$ git status
  On branch master
  nothing to commit, working directory clean

Все сработало - Git не захотел видеть директории

1

ignore

1

.ignore

Шаблоны в файле .gitignore

Для файла

1

.gitignore