Git — GIT проблема


Содержание

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

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

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

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

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

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

Pro Git

Страницы

Git шпаргалка

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

Создание репозитория в папке где выполняется команда
$ git init

Создание репозитория в указанном каталоге
$ git init

Создание репозитория Git для совместной работы

$ git init —bare —share sharedproject.git

Данная команда создает каталог с именем sharedproject.git c правами на запись в него. Подробнее тут.

Клонирование удаленного репозитория в локальный

Клонирование удаленного репозитория в локальный каталог с именем по умолчанию
$ git clone https://github.com/n0tb0dy/RemoreBranches.git

Клонирование удаленного репозитория в локальный каталог с указанным именем
$ git clone https://github.com/n0tb0dy/RemoreBranches.git LocalBranches

Клонирование локального репозитория на удаленный

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

1. Связываем локальный репозиторий с удаленным
$ git remote add origin https://github.com/n0tb0dy/UpRemote.git

2. Верифицируем что удаленный репозиторий связан с нашим
$ git remote -v

3. Публикуем ветку master на удаленном репозитории
$ git push -u origin master

Более подробно можно почитать тут.

Задаем имя пользователя и электронную почту

Глобально для всех проектов текущего пользователья
$ git config —global user.name «John Doe»
$ git config —global user.email johndoe@example.com

Для конкретного проекта (эти настройки переопределят глобальные)
$ git config —local user.name «John Doe»
$ git config —local user.email johndoe@example.com

Просмотр настроек Git

Всех (глобальных, системных и локальных). Некоторые параметры могут появится в списке несколько раз, так как читаются из трех файлов настроек. Подробнее тут.
$ git config —list

Локальных для определенного проекта
$ git config —local —list

Системных
$ git config —system —list

Получение справки (помощи) по команде Git

Например выведем справку по команде config (откроется браузер со справкой)
$ git help config

Настройка русских шрифтов (cp1251) в Git

Настраиваем правильное отображение файлов с русскими названиями в командах Git
$ git config —local core.quotepath false

Настраиваем кодировку Windows cp1251 для коммитов в Git
$ git config —local core.pager «iconv.exe -f cp1251 -t utf-8 | less»
$ git config —local i18n.commitEncoding utf8
$ git config —local i18n.logoutputencoding cp1251

Эти команды замечательно работают в msysgit 1.9.5 . Как будет в других версия не знаю. Но надеюсь, что в более новых тоже будет работать. Более подробно про настройку русского языка в Git можно почитать тут. Так же они правильно работают при установке Git из пакетов Cygwin , подробнее можно почитать тут.

Так же можно задать кодовую страницу для файлов проекта командой
$ git config —local i18n.filesEncoding windows-1251

ну или просто строкой в разделе [i18n]
filesEncoding = windows-1251

А вообще лучше вести проекты в кодировке UTF-8, если это возможно конечно.

Просмотр информации о состоянии файлов в Git

Основной инструмент, используемый для определения, какие файлы в каком состоянии находятся — это команда:
$ git status

И ее более краткий вывод:
$ git status -s

Просмотр разницы (что конкретно было изменено в файлах) между рабочим каталогом и индексом (staged area)
$ git diff

Просмотр разницы между последним коммитом и индексом
$ git diff —staged

Более подробно смотрим тут.


Фиксация изменений (коммит)

Если дать команду git commit без дополнительных параметров, то сперва будет вызван редактор для ввода комментария к коммиту и после сохранения комментария будет произведен коммит (фиксация изменений)
$ git commit

Чтобы включить в комментарий к коммиту информацию о том какие именно были сделаны изменения в каких файлах надо дать команду
$ git commit -v

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

Чтобы редактор не вызывался, можно написать комментарий прямо в командной строке в ключе -m
$ git commit -m «Commit Comment»

Автоматически добавить все измененные файлы в коммит
$ git commit -a

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

Удаление файла из отслеживаемых Git, а так же его физическое удаление из рабочего каталога
$ git rm

Удаление проиндексированного измененного файла
$ git rm -f

Удаление файла из индекса, но сохранение его в рабочем каталоге
$ git rm —cached

Более подробно смотрим тут.

Просмотр истории коммитов

Самый простой вариант это git log с разными ключами (смотрим help). Тут приведу просто примеры. А подробнее тут или в мануале.

Вывод простой истории коммитов
$ git log

Вывод последних n записей, в примере вывод двух последних записей
$ git log -2

Вывод дельты (diff) разницы между последними двумя изменениями (на уровне строк)
$ git log -p -2

Вывод изменений между двумя последними коммитами на уровне слов
$ git log -p -2 —word-diff

Вывод краткой статистики по 2 последним коммитам
$ git log -2 —stat

И очень полезный ключ —pretty (позволяет изменить формат вывода лога)
$ git log —pretty=oneline

$ git log —pretty=format:»%h — %an, %ar : %s»

Параметры ключа format

Параметр Описание выводимых данных
%H Хеш коммита
%h Сокращённый хеш коммита
%T Хеш дерева
%t Сокращённый хеш дерева
%P Хеши родительских коммитов
%p Сокращённые хеши родительских коммитов
%an Имя автора
%ae Электронная почта автора
%ad Дата автора (формат соответствует параметру —date= )
%ar Дата автора, относительная (пр. «2 мес. назад»)
%cn Имя коммитера
%ce Электронная почта коммитера
%cd Дата коммитера
%cr Дата коммитера, относительная
%s Комментарий

Можно так же посмотреть ASCII граф веток коммитов по ключу —graph
$ git log —pretty=format:»%h %s» —graph

Есть параметры, ограничивающие по времени, такие как —since и —until, весьма полезны. Например, следующая команда выдаёт список коммитов, сделанных за последние две недели:
$ git log —since=2.weeks

Другой полезный фильтр это опция –S, которая как параметр принимает строку и показывает только те коммиты где эта строка была изменена, добавлена или удалена.
$ git log -S

Пример будет искать строку MyStringForSearch
$ git log -SMyStringForSearch

Список коммитов с хэшем (короткое число)
$ git log —oneline

Изменение комментария к последнему комииту, но только в том случае, если после последнего коммита не было ни каких изменений в рабочем каталоге
$ git commit —amend

Отмена индексации файла (исключение из индекса)
$ git reset HEAD

Отмена изменений файла (до внесения файла в коммит)
$ git checkout —

С этой командой надо быть особо осторожным, подробнее тут.

Удаление раз и навсегда последнего коммита. Его больше ни кто ни когда не увидит. И вы в том числе :). Произойдет откат на предыдущий коммит. Все изменения которые были в последнем коммите будут утеряны. Хорошо подумайте прежде чем это делать.
$ git reset —hard HEAD

Работа с удаленными репозиториями

Просмотр удаленных репозиториев
$ git remote

Более подробный вывод о них
$ git remote -v

Добавление удаленного репозитория (вместо origin можно задать любое слово)
$ git remote add origin https://github.com/n0tb0dy/UpRemote.git
$ git remote add tr https://github.com/n0tb0dy/UpRemote.git

Получение изменений с удаленного репозитория под именем tr в локальную ветку tr
$ git fetch tr

Отправка данных на удаленный репозиторий. Формат git push [удал. сервер] [локальная ветка]
$ git push origin master

Инспекция удаленного репозитория git remote show [удал. сервер]
$ git remote show origin

Переименование удаленных репозиториев (по существу переименование локальной ссылки на удаленный репозиторий)
$ git remote rename
$ git remote rename tr newtr

Удаление удаленного репозитория :) (попросту отключение от него — в примере от origin)
$ git remote rm origin

Подробней о работе с удаленными репозиториями тут.

Если у вас свой собственный репозиторий Git на сервере с само подписанным сертификатом, то перед любыми командами работы у удаленным репозиторием (clone, fetch, push, pull и т.п.), Git будет ругаться на само подписанный сертификат. Решить проблему можно изменив чуток конфиг
$ git config —local http.sslVerify false

Или же перед каждой операцией работы с удаленным репозиторием вставлять доп команду
$ git -c http.sslVerify=false push origin newbranch

А вообще настройка своего сервера Git это отдельная тема. Частично рассмотрена мной тут.

Работа с ветками

Посмотреть локальные ветки
$ git branch

Посмотреть последний коммит на каждой из локальных веток
$ git branch –v

Чтобы посмотреть все существующие локальные и удаленные ветки можно дать команду
$ git branch –a

Посмотреть последние коммиты на всех ветках (локальных и удаленных)
$ git branch –a -v

Посмотреть отслеживаемые ветки
$ git branch –vv

Сделать ветку локальную ветку serverfix отслеживаемой
$ git branch -u origin/serverfix

Создать ветку
$ git branch


Создать ветку на определенном коммите
$git branch new_branch 5a0eb04

Переименовать ветку
git branch -m

Переименовать текущую ветку
git branch -m

Переключится на ветку
$ git checkout

Создать ветку и сразу же переключится на нее
$ git checkout -b

Слияние веток (в примере находимся на ветке master и сливаем с ней ветку hotfix)
$ git checkout master
$ git merge hotfix

Удалить ветку
$ git branch -d

Удалить ветку serverfix на удаленном сервере
$ git push origin —delete serverfix

Работа с метками

Посмотреть все (перечисляет в алфавитном порядке, а не по времени их создания)
$ git tag

Посмотреть попадающие под маску
$ git tag -l ‘v1.4.2.*’

Создать метку на текущем коммите (ключ ) с меточным сообщением (ключ -m)
$ git tag -a v1.4 -m ‘my version 1.4’

Если ключ -m не указывать то откроется окно редактора чтобы ввести сообщение

Создание легковесной метки на текущем коммите
$ git tag
$ git tag MyTAG

Посмотреть метки вместе с комментариями к коммитам, а так же с именами поставивших метки
$ git show
$ git show MyTAG

Так же можно выставлять метки и на уже пройденные коммиты. Подробнее о метках тут.

Задание псевдонимов для команд Git

Псевдонимы можно создать как в конфигурационных файлах Git, так и в конфиге Bash, но важно понимать в чем разница.

Задание псевдонимов в конфигах Git

$ git config —global alias.co checkout
$ git config —global alias.br branch
$ git config —global alias.ci commit
$ git config —global alias.st status

Теперь достаточно давать команды
$ git co
$ git br
$ git ci
$ git st

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

Кроме того в эти команды так же можно подставлять параметры
$ git config —global alias.unstage ‘reset HEAD —‘

Это делает эквивалентными следующие две команды:
$ git unstage fileA

$ git reset HEAD fileA

Более подробно по алисы в конфигах Git читаем тут.

Об алиасах заданных через Bash читаем тут.

Сравнение файла в разных коммитах

$ git diff ffd6b37 c258082 —cc test.txt

С помощью внешних утилит ExamDiffPro и P4Merge

Смотрим изменения файла test.txt между двумя коммитами
$ git difftool 9491cc8 02c1df6 —tool=edp —cc test.txt
$ git difftool 9491cc8 02c1df6 —tool=p4m —cc test.txt

Самая главная и нужная команда слияния, это отмена слияния :)
$ git merge —abort

Просмотр истории перемещения указателя HEAD
$ git reflog

Почему не работает git push?

Есть git репозиторий проекта FreePBX. Делаю ветку себе, после делаю клон себе, делаю изменения в исходниках, делаю добавление с помощью команды:

$ git add [имя_файла]

После делаю комит:

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

$ git push -u origin master

или как угодно еще, но в любом случае получаю сообщение: Everything up-to-date

Ранее никогда такого не видел, даже не знаю из-за чего может не выгружаться изменения.

Вот собственно что выводит команда git status:

Кстати, git diff ничего не показывает, а git diff —cached показывает сделанные изменения. Все вроде как надо, но изменения не выгружаются.

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

По идеи, насколько я знаю, опция -a позволяет обходиться без команды git add, больше она ничего особенного не делает, но я все равно чего-то не до понимаю, я ведь добавлял измененный файл.

В результате вопрос остается открытым. Что сделал не так, если коммит выполнился только с опцией -a?

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

Работа с Git через консоль

Итак, вы получили задание: сделать форк вашего репозитория в GitHub, создать ветку и начать работу.

Когда получил непонятное задание.

Что за GitHub, какие команды, зачем, а главное, как всем этим пользоваться? Давайте разбираться.

Система контроля версий Git

Для начала определим, что такое система контроля версий.

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

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

Одна из самых популярных систем называется Git. Её отличие от других программ — отсутствие графической версии. Поэтому работа с Git ведётся через командную строку. В разных операционных системах свои программы для взаимодействия с Git.


В Windows их две: PowerShell и cmd.exe. В Ubuntu это Terminal. Самая популярная программа на macOS тоже называется Terminal. Если вам не подходит встроенная в систему программа для работы с командной строкой, вы можете поставить свою. Например, написанную на JavaScript программу Hyper, которая работает на любой операционной системе. На Windows популярны программы Cmder и Git Bash, а на macOS — iTerm.

В мире разработки такие программы называют «терминал» или «консоль». А работает это так: мы вводим команду и получаем реакцию машины: сообщение об ошибке, запрос на подтверждение информации, результат выполненных действий.

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

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

Установка в Linux

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

  • Если у вас 21 или более ранняя версия Fedora, используйте yum install git .
  • Для 22 и последующих версий Fedora вводите dnf install git .
  • Для дистрибутивов, основанных на Debian, например, Ubuntu, используйте apt-get: sudo apt-get install git .

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

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

  1. Скачиваем Git со страницы проекта.
  2. Запускаем загруженный файл.
  3. Система может показать окно с ошибкой, где будет написано, что файл скачан с неавторизованного сайта и инсталлятор не может быть запущен. В таком случае нужно зайти в «Системные настройки» — «Безопасность» (Security and Privacy), в появившемся окне будет сообщение об ошибке и кнопка Open anyway (Всё равно открыть). Нажимаем.
  4. Система покажет окно, уточняющее хотите ли вы запустить установку. Подтверждаем действие.
  5. Установщик проведёт через все необходимые шаги.

Установка в Windows

Скачайте exe-файл инсталлятора с сайта Git и запустите его. Это Git для Windows, он называется msysGit. Установщик спросит добавлять ли в меню проводника возможность запуска файлов с помощью Git Bash (консольная версия) и GUI (графическая версия). Подтвердите действие, чтобы далее вести работу через консоль в Git Bash. Остальные пункты можно оставить по умолчанию.

Проверим, что Git установлен

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

Настройка Git

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

Откройте терминал и используйте следующую команду, чтобы добавить своё имя: git config —global user.name «ваше имя»

Для добавления почтового адреса вводите: git config —global user.email адрес

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

Регистрация на GitHub

Что такое GitHub?

GitHub — веб-сервис, который основан на системе Git. Это такая социальная сеть для разработчиков, которая помогает удобно вести коллективную разработку IT-проектов. Здесь можно публиковать и редактировать свой код, комментировать чужие наработки, следить за новостями других пользователей. Именно в GitHub работаем мы, команда Академии, и студенты интенсивов.

Чтобы начать работу с GitHub, нужно зарегистрироваться на сайте, если вы ещё этого не сделали. За дело.

  1. Переходим на сайт GitHub. Cтартовая страница GitHub.
  2. Есть два варианта начала регистрации:
    • Нажимаем кнопку Sign up (зарегистрироваться), попадаем на страницу регистрации, где вводим обязательные данные: имя пользователя, адрес электронной почты и пароль. После заполнения полей нажимаем Create an account (создать аккаунт).
    • Cразу вводим имя, почту и пароль на главной странице GitHub и нажимаем Sign up for GitHub (зарегистрироваться на GitHub).

    Первый шаг регистрации профиля на стартовой странице GitHub.

  3. На втором этапе нужно выбрать тарифный план. GitHub — бесплатный сервис, но предоставляет некоторые платные возможности. Выбираем тарифный план и продолжаем регистрацию. Выбор тарифа на втором шаге регистрации.
  4. Третий шаг — небольшой опрос от GitHub, который вы можете пройти, заполнив все поля и нажать Submit или пропустить, нажав skip this step. Опрос на третьем шаге регистрации.
  5. После прохождения всех этапов на сайте, на указанный при регистрации ящик вам придёт письмо от GitHub. Откройте его и подтвердите свой почтовый адрес, нажав Verify email address (подтвердить электронный адрес) или скопируйте вспомогательную ссылку из письма и вставьте её в адресную строку браузера. Переход в ваш профиль.

Так выглядит ваш профиль после регистрации.

Теперь у вас есть профиль на GitHub.

Устанавливаем SSH-ключи

Git установлен, профиль на GitHub создан. Осталось добавить SSH-ключ и можно приступать к работе с проектом.

Что такое SSH-ключ и зачем он нужен?

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

Каждый SSH-ключ содержит пару: открытый (публичный) и закрытый (приватный) ключ. Открытый ключ отправляется на сервер, его можно не прятать от всех и не переживать, что кто-то его увидит и украдёт. Он бесполезен без своей пары — закрытого ключа. А вот закрытый ключ — секретная часть. Доступ к нему должен быть только у вас.

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

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

Сначала проверим, есть ли уже на компьютере ключ. По умолчанию SSH-ключи хранятся в каталоге

/.ssh , поэтому нужно проверить содержимое этого каталога.

  1. Открываем консоль.
  2. Вводим cd

/.ssh , чтобы перейти в нужный каталог. Переходим в нужную директорию.

  • Используем ls , чтобы увидеть список всех файлов в каталоге. Открываем список файлов в директории. Ищем пару файлов с названиями вида имя и имя.pub . Обычно имя — id_rsa , id_dsa , id_ecdsa или id_ed25519 . Файл с расширением .pub — ваш публичный ключ, а второй — ваш приватный, секретный ключ. Если таких файлов или даже каталога .ssh у вас нет, вы можете их сгенерировать. Для этого делаем следующее.
    • Открываем консоль и вводим команду: Указываем тот адрес электронной почты, который вводили при регистрации на GitHub. Генерируем ключ.
    • Далее нужно указать расположение файла для сохранения ключа. Если вы не введёте путь до файла и просто нажмёте Enter, ключ сохранится в файле, указанном в скобках.
    • Теперь нужно установить пароль к вашему ключу и дважды ввести его. Если вы не хотите вводить пароль каждый раз, когда используете ключ, пропустите этот шаг, нажав «Enter», и ничего не вводите. Указываем расположение ключа и вводим пароль.
  • Добавляем ключ в ssh-agent (сгенерированный или уже существующий). Проверяем доступность ключа командой eval «$(ssh-agent -s)» и добавляем с помощью ssh-add

    /.ssh/your_key_name , где указываем верный путь до файла с ключом и его имя. Добавляем ключ в shh-agent. Несколько важных примечаний:

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

    /.ssh/config связь ключа с доменом.
    Если у вас Windows и вы пользуетесь программой Cmder, возможны проблемы с командой eval «$(ssh-agent -s)» . Может появиться такое сообщение об ошибке: «eval не является внутренней или внешней командой, исполняемой программой или пакетным файлом».

    В Сmder для запуска ssh-agent можно использовать команду start-ssh-agent .


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

    Если у вас macOS Sierra версии 10.12.2 и выше, нужно изменить ваш

    /.ssh/config файл, чтобы автоматически загрузить ключи в ssh-agent и хранить пароли.

    Вы можете добавить свой приватный ключ в ssh-agent и сохранить пароль к нему с помощью команды ssh-add -K

    /.ssh/id_rsa . Если у вашего ключа другое имя, не забудьте заменить id_rsa в команде на правильное название.

    Если у вас Linux, может понадобится переназначить для

    /.ssh права доступа командой chmod 700

    /.ssh/

  • После того как создан ключ, его нужно добавить на GitHub. Для этого копируем его содержимое с помощью одной из следующих команд:
    • Если вы на Windows clip .
    • Для пользователей macOS pbcopy .
    • На Linux используйте sudo apt-get install xclip , чтобы установить необходимый для копирования пакет xclip , а затем введите xclip -sel clip . Или введите команду cat

      /.ssh/id_rsa.pub , контент документа появится прямо в консоли и вы сможете скопировать ключ оттуда.

      Можно пойти другим путём, открыть файл id_rsa.pub прямо в папке и просто скопировать содержимое оттуда.

      Переходим на страницу для работы с ключами в вашем профиле на GitHub. Страница с настройками ключей в вашем профиле.

      Нажимаем кнопку New SSH key (новый SSH-ключ). Вводим имя ключа (можно придумать абсолютно любое) в поле Title (название), а в Key (ключ) вставляем сам ключ из буфера обмена. Теперь нажимаем Add SSH key (добавить SSH-ключ).

      Добавляем в свой профиль SSH-ключ.

      Если всё сделано верно, в списке появится новый ключ.

      Успешно добавленный ключ.

      Теперь, наконец-то, мы можем начать работу с самим проектом.

      Работа с репозиториями

      Для начала определим, что такое репозиторий. Это рабочая директория с вашим проектом. По сути, это та же папка с HTML, CSS, JavaScript и прочими файлами, что хранится у вас на компьютере, но находится на сервере GitHub. Поэтому вы можете работать с проектом удалённо на любой машине, не переживая, что какие-то из ваших файлов потеряются — все данные будут в репозитории при условии, что вы их туда отправите. Но об этом позже.

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

      Как сделать форк мастер-репозитория?

      Заходим в нужный репозиторий, нажимаем на «вилку» с надписью fork. Форк репозитория создан и находится в вашем профиле на GitHub.

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

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

      Если вы правильно настроили SSH-ключи, Git начнёт процесс копирования репозитория на ваш компьютер. Если вы видите ошибку, в которой написано Error: Permission denied (publickey) , скорее всего, вы ошиблись где-то при выполнении инструкции по настройке SSH-ключа. Вернитесь на несколько абзацев ранее и попробуйте повторить процесс настройки.

      Если вы не хотите вручную вводить адрес репозитория, вы можете зайти на страницу проекта, нажать зелёную кнопку Clone or download (клонировать или скачать), выбрать Clone with SSH (клонировать по SSH) и скопировать адрес, который находится в текстовом поле. Этот адрес вы можете вставить в команду git clone .

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

      Теперь, на вашем компьютере, в папке your_project или в той, название которой вы указали самостоятельно, находится полная копия репозитория c GitHub.

      Чтобы начать работу с проектом, надо оказаться в его директории. Для этого используем команду cd , после которой указываем название проекта на вашем компьютере: cd your-project

      Сделали копию репозитория.

      Работу над проектом принято вести в ветках. В каждом репозитории есть как минимум одна ветка. Это основная ветка, которую создаёт сам Git, она называется master . Обычно в ней находится стабильная версия программы без ошибок. Если вы хотите исправить баг, добавить новую функциональность в проект, попробовать какую-то технологию, но не хотите сломать код в основной ветке, вы ответвляетесь из master и трудитесь в своей новой ветке. Здесь вы можете реализовывать свои идеи, не переживая, что рабочий код сломается. Каждая ветка — что-то вроде второстепенной дороги, которая затем снова соединяется с основной.

      Создадим новую ветку. Открываем терминал, вводим команду git branch . Она показывает список веток, с которыми мы работаем в проекте, и выделяет текущую. Если мы находимся в master создаём новую ветку: git checkout -b имя-новой-ветки .

      Если текущая ветка не master , сначала переключимся в основную ветку: git checkout master . Мы делаем это, чтобы новая ветка содержала свежую, на момент создания, рабочую версию проекта.

      Эта команда позволяет переключаться между существующими ветками в проекте, после git checkout надо указать название нужной ветки.

      Переключаемся между ветками.

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

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

      Если вы хотите сохранить изменения не во всех файлах, для начала можно ввести команду git status . Она покажет текущее состояние в вашей ветке, а именно список с названиями изменённых файлов, если они есть, и укажет на те, которые ожидают записи и сохранения (обычно они выделены красным цветом).

      Перед тем, как зафиксировать изменения отдельных файлов, нужно добавить файлы в набор этих изменений. Воспользуйтесь командой git add имя-файла . Если название очень длинное, вы можете начать его писать, затем нажать Tab и консоль сама предложит вам продолжение пути к файлу.

      Если вы хотите сохранить все изменения разом, вводите git add -A .

      Теперь мы можем сделать коммит, то есть зафиксировать все сохранённые изменения и дать им название. Это делается с помощью команды git commit -m «ваше сообщение» . Текст сообщения должен быть лаконичным и в то же время сообщать о том, что делает коммит (внесённые изменения). Например, «добавляет имя наставника в Readme», «вводит функцию сортировки изображений», «правит ошибку в поиске городов на карте».

      Сохранения зафиксированы, всё? Они теперь в репозитории и видны коллегам? Пока нет. Те изменения, которые мы внести и сохранили, пока локальны. Их нужно послать на GitHub.

      Чтобы отправить свои изменения (коммиты) в репозиторий на GitHub, введите команду git push origin название-текущей-ветки , где origin означает репозиторий, который был склонирован на компьютер, то есть ваш форк.

      Теперь заходим на страницу нашего форка и создаём пулреквест, чтобы слить свой код с данными в мастер-репозитории. Что такое пулреквест? Это предложение изменить код в репозитории.

      Любое предложение можно принять или отвергнуть. Так же и с пулреквестом. После его создания, он должен получить ревью и одобрение так называемого коллаборатора — пользователя GitHub, который имеет права администратора в мастер-репозитории. Им может быть ваш коллега-разработчик, техлид, наставник. Если к вашему коду нет вопросов, пулреквест принимается и изменения из вашей ветки попадают в master главного репозитория. Если в код нужно внести изменения, пулреквест отклоняется, и вам нужно снова пройти по цепочке локальные изменения — сохранение — коммит — пуш, только пулреквест заново делать не нужно. Если вы продолжаете вести работу в той же ветке и пулреквест ещё не принят, все ваши изменения автоматически добавятся в пулреквест, созданный из этой ветки после команды git push origin название-текущей-ветки .

      Вы исправили код, наставник или техлид одобрил ваши правки и принял пулреквест. Теперь код в мастер-репозитории обновился, а в вашем форке нет, вы ведь не обновляли свою версию репозитория с тех пор, как клонировали её себе на компьютер. Приведём форк в актуальное состояние.

      1. В локальном репозитории вводим команду git checkout master , переходим в master .
      2. Теперь забираем (подтягиваем) изменения из ветки master мастер-репозитория git pull academy master . Academy здесь — сокращённое название мастер-репозитория, такое имя используется в проектах студентов Академии, вы можете выбрать любое другое название. Забираем изменения из мастер-репозитория. Если консоль выдаёт ошибку и говорит, что не знает директории с таким именем, нужно добавить ссылку на этот репозиторий: Вместо academy указывайте своё название и оно закрепится за этим репозиторием.
      3. Теперь отправьте изменения уже из своей ветки master в ваш форк на GitHub с помощью команды git push origin master . Отправляем изменения в форк.

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

      Знакомство с Git и GitHub: руководство для начинающих

      Ищите, с чего бы начать изучение Git и GitHub? Хотите поработать с другими? Усердно трудитесь над проектом? Или вдруг заметили, что заслужить уважение среди технарей можно своим присутствием на GitHub?

      Тогда эта статья специально для вас!

      На самом деле, в Git нет ничего сложного. Если вы быстро читаете и не тратите уйму времени на установку и регистрацию, то начать работать с GitHub вы сможете уже через 10 минут.

      Прочитав данную статью вы научитесь клонировать существующий репозиторий, создавать ветки, вносить изменения и отправлять запросы на изменения. Параллельно освоите работу в терминале, терминальные команды и редактирование файла Markdown ( .md ).

      Если вы сможете все это сделать, то можно считать, что вы успешно справились с задачей. А еще вы сможете поучаствовать в своем первом open-source проекте Стене на GitHub.

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

      Что такое Git и GitHub?

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

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

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

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

      Если в статье вы видите команду с угловыми скобками: , то смело удаляйте эти скобки и меняйте их содержимое на нужный вам текст.

      Пример: git add . Здесь вы можете написать нечто подобное: git add hello_world.py . Это означает, что вы хотите добавить в репозиторий файл под названием hello_world.py .

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

      Затем к ним добавим еще вот эти:

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

      Не лишней будет и вот такая команда:

      О ней мы также поговорим ниже.

      (Если вы работаете на Mac, то у вас уже установлен терминал. Нажмите на иконку с лупой в верхнем правом углу экрана и напечатайте слово terminal ).

      Шаг 1: Регистрация и установка

      Зайдите на GitHub и создайте свой аккаунт. В принципе, этим можно и ограничиться. При желании можете установить Git. Но для работы с GitHub это вовсе не обязательно. Однако если вы планируете заниматься проектами на локальном компьютере, то установка вам все-таки нужна. Можете скачать установщик или установить файлы через менеджер пакетов.

      Теперь перейдите в терминал, и начнем работу. Если хотите задать одно имя пользователя для всех репозиториев на компьютере, то напишите:

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

      Теперь напишите свой адрес электронной почты. Проследите, чтобы он совпадал с адресом, указанным при регистрации на GitHub.

      При желании можете скрыть свой электронный адрес. Это сделать несложно, подробнее написано здесь. По сути, вам нужно проставить 2 галочки в своем GitHub-аккаунте.

      Теперь вы готовы к работе с Git на локальном компьютере.

      Начнем с создания нового репозитория на сайте GitHub. Вы также можете выполнить git init и создать новый репозиторий из директории проекта.

      Репозиторий состоит из трех «деревьев». Первое «дерево» — это рабочая директория, в которой хранятся актуальные файлы. Второе — это index или область подготовленных файлов. А еще есть head — указатель на ваш последний коммит.

      Вариант 1. Я уже знаком с терминалом

      Вот как начать работу с Git из терминала.

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

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

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

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

      или добавьте сразу все файлы через:

      Создать коммит с этими изменениями можно через команду:

      Если изменения вас устраивают, напишите:

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

      При внесении изменений следует обновить и сами файлы:

      Создайте коммит, добавьте нужное сообщение и отправьте этот коммит в репозиторий.

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

      Если с этим все понятно, то переходите к части 2: «Учимся работать с другими», в которой рассматривается градация веток и совместная работа над проектами.

      Вариант 2. Я вообще ничего не знаю

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

      Ну что ж, приступим к делу!

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

      Репозиторий — это место, в котором вы систематизируете свой проект. Здесь вы храните файлы, папки, видео, изображения, блокноты Jupyter Notebook, наборы данных и т.д. Перед началом работы с Git необходимо инициализировать репозиторий для проекта и правильно его подготовить. Это можно сделать на сайте GitHub.

      Лучше сразу добавлять в репозиторий README-файл с информацией о проекте. Это можно сделать в момент создания репозитория, поставив галочку в соответствующем поле.

      • Перейдите на сайт GitHub. Нажмите на значок + в верхнем правом углу, а затем выберите New repository.
      • Придумайте имя репозитория и добавьте короткое описание.
      • Решите, будет ли этот репозиторий размещаться в открытом доступе или останется закрытым для просмотра.
      • Нажмите Initialize this repository with a README для добавления README-файла. Настоятельно рекомендую снабжать все ваши проекты файлом-описанием, ведь README — это первая вещь, на которую люди обращают внимание при просмотре репозитория. К тому же, здесь можно разместить нужную информацию для понимания или запуска проекта.

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

      Вносить изменения в проект можно двумя способами. Вы можете изменять файлы/блокноты на компьютере либо делать это на сайте GitHub.

      Допустим, вам захотелось подкорректировать README-файл на сайте GitHub.

      • Для начала перейдите в ваш репозиторий.
      • Для выбора файла кликните по его названию (например, кликните по README.md для перехода к файлу-описанию).
      • В верхнем правом углу вы увидите иконку с карандашом. Нажмите на нее для внесения изменений.
      • Напишите короткое сообщение, передающее суть изменений (и подробное описание, если сочтете это нужным).
      • Нажмите кнопку Commit changes.

      Вы успешно внесли изменения в README-файл своего нового репозитория! Обратите внимание на небольшую кнопку на картинке выше. Она позволяет создавать новую ветку этого коммита и добавлять Pull request. Запомните ее, скоро к ней вернемся.

      Как вы видите — ничего сложного!

      Лично я предпочитаю работать с файлами на локальном компьютере, а не на сайте GitHub. Поэтому давайте научимся и этому.

      Подайте мне вот этот проект!

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

      Для клонирования репозитория на компьютер перейдите в репозиторий на GitHub и нажмите большую зеленую кнопку под названием Clone or download (разумеется, вы можете просто скачать репозиторий и избежать всех заморочек с терминалом. Но я в вас верю, поэтому не будем сдаваться!). Проследите, чтобы появилась надпись Clone with HTTPS. Теперь нажмите на иконку буфера обмена для копирования-вставки (либо выделите ссылку и скопируйте ее).

      Откройте терминал и перейдите в директорию для копирования репозитория. Например, для перехода на Рабочий стол напечатайте вот это:

      Затем клонируйте туда репозиторий по следующей команде:

      Все просто! Не забудьте изменить информацию в угловых скобках на нужную вам. И удалите сами скобки .

      Если вы не очень хорошо ориентируетесь в терминале, то переход по директориям можно осуществлять через команду cd . Например, откройте терминал и напечатайте ls для отображения перечня доступных директорий. Вполне возможно, что в этом списке вы сразу увидите директорию Desktop . Либо напечатайте cd Desktop . Далее выполните команду git clone и склонируйте репозиторий на Рабочий стол.

      Бывает и так, что вместо перечня расположений, вы видите различные имена пользователей. Тогда до того, как перейти в Desktop , вам потребуется выбрать нужного пользователя через команду cd (замените на нужное вам имя). Затем снова напечатайте ls , чтобы увидеть весь список. И вот теперь, увидев в списке Desktop , смело печатайте cd Desktop . Сейчас уже можно выполнять git clone !

      Если вдруг в терминале вы захотите «откатиться» на шаг назад, то напишите cd ..

      Новый GitHub-репозиторий, склонированный на рабочий стол, готов! Данная команда создает точную копию репозитория в вашей системе. Здесь вы сможете с ним работать, редактировать, индексировать изменения, создавать коммиты с изменениями и отправлять их на GitHub.

      Совсем не обязательно создавать репозиторий на Рабочем столе. Клонировать можно в любое место на компьютере. Команду git clone можно выполнять и сразу после открытия терминала. Однако, если вы не очень любите копаться в папках на компьютере, то неплохо будет разместить проект на виду, то есть на Рабочем столе…

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

      Добавляем файлы в проект

      Вот, чем мы займемся:

      Но ничего сложного здесь нет!

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

      Проверьте статус проекта.

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

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

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

      Процесс создания коммитов с изменениями начинается с выполнения команды:

      Коммиты изменений добавляются в head (указатель), а не в удаленный репозиторий. Не забудьте заменить текст в скобках и убрать <> . После внесения изменений создается снимок состояния репозитория, для чего используется команда commit . А через –m добавляется сообщение об этом снимке.

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

      Теперь ваши изменения сохранены в указателе локальной копии проекта. Для отправки изменений на удаленный репозиторий выполните команду:

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

      Актуальность версии можно проверить в любое время через команду git status .

      Итог: у вас есть свой GitHub репозиторий, вы научились добавлять и изменять в нем файлы.

      Git Tutorial: 10 Common Git Problems and How to Fix Them

      Learning Git? This Git tutorial covers the 10 most common Git tricks you should know about: how to undo commits, revert commits, edit commit messages, discard local files, resolve merge conflicts, and more.


      Sometimes the best way to get a feel for a problem is diving in and playing around with the code. Unfortunately, the changes made in the process sometimes turn out to be less than optimal, in which case reverting the file to its original state can be the fastest and easiest solution:

      In case you’re wondering, the double dash ( — ) is a common way for command line utilities to signify the end of command options.

      Alas, sometimes it takes us a bit longer to realize that we are on the wrong track, and by that time one or more changes may already have been committed locally. This is when git reset comes in handy:

      Be careful with the —hard option! It resets your working tree as well as the index, so all your modifications will be lost for good.

      If you are not careful during a git add , you may end up adding files that you didn’t want to commit. However, git rm will remove it from both your staging area, as well as your file system, which may not be what you want. In that case make sure you only remove the staged version, and add the file to your .gitignore to avoid making the same mistake a second time:

      Typos happen, but luckily in the case of commit messages, it is very easy to fix them:

      But that’s not all git-amend can do for you. Did you forget to add a file? Just add it and amend the previous commit!

      Please keep in mind that —amend actually will create a new commit which replaces the previous one, so don’t use it for modifying commits which already have been pushed to a central repository. An exception to this rule can be made if you are absolutely sure that no other developer has already checked out the previous version and based their own work on it, in which case a forced push ( git push —force ) may still be ok. The —force option is necessary here since the tree’s history was locally modified which means the push will be rejected by the remote server since no fast-forward merge is possible.

      While —amend is very useful, it doesn’t help if the commit you want to reword is not the last one. In that case an interactive rebase comes in handy:

      This will open your configured editor and present you with the following menu:

      On top you’ll see a list of local commits, followed by an explanation of the available commands. Just pick the commit(s) you want to update, change pick to reword (or r for short), and you will be taken to a new view where you can edit the message.

      However, as can be seen from the above listing, interactive rebases offer a lot more than simple commit message editing: you can completely remove commits by deleting them from the list, as well as edit, reorder, and squash them. Squashing allows you to merge several commits into one, which is something I like to do on feature branches before pushing them to the remote. No more “Add forgotten file” and “Fix typo” commits recorded for eternity!

      Despite the fixes demonstrated in the previous tips, faulty commits do occasionally make it into the central repository. Still this is no reason to despair, since git offers an easy way to revert single or multiple commits:

      In case you don’t want to create additional revert commits but only apply the necessary changes to your working tree, you can use the —no-commit / -n option.

      The manual page at man 1 git-revert list further options and provides some additional examples.

      As every developer knows, fixing merge conflicts can be tedious, but solving the exact same conflict repeatedly (e.g. in long running feature branches) is outright annoying. If you’ve suffered from this in the past, you’ll be happy to learn about the underused reuse recorded resolution feature. Add it to your global config to enable it for all projects:

      Alternatively you can enable it on a per-project basis by manually creating the directory .git/rr-cache .

      This sure isn’t a feature for everyone, but for people who need it, it can be real time saver. Imagine your team is working on various feature branches at the same time. Now you want to merge all of them together into one testable pre-release branch. As expected, there are several merge conflicts, which you resolve. Unfortunately it turns out that one of the branches isn’t quite there yet, so you decide to un-merge it again. Several days (or weeks) later when the branch is finally ready you merge it again, but thanks to the recorded resolutions, you won’t have to resolve the same merge conflicts again.

      The man page ( man git-rerere ) has more information on further use cases and commands ( git rerere status , git rerere diff , etc).

      Tracking down the commit that introduced a bug after a big merge can be quite time consuming. Luckily git offers a great binary search facility in the form of git-bisect . First you have to perform the initial setup:

      After this git will automatically checkout a revision halfway between the known “good” and “bad” versions. You can now run your specs again and mark the commit as “good” or “bad” accordingly.

      This process continues until you get to the commit that introduced the bug.

      Some mistakes happen repeatedly, but would be easy to avoid by running certain checks or cleanup tasks at a defined stage of the git workflow. This is exactly the scenario that hooks were designed for. To create a new hook, add an executable file to .git/hooks . The name of the script has to correspond to one of the available hooks, a full list of which is available in the manual page ( man githooks ). You can also define global hooks to use in all your projects by creating a template directory that git will use when initializing a new repository (see man git-init for further information). Here’s how the relevant entry in

      /.gitconfig and an example template directory look like:

      When you initialize a new repository, files in the template directory will be copied to the corresponding location in your project’s .git directory.

      What follows is a slightly contrived example commit-msg hook, which will ensure that every commit message references a ticket number like “ #123 “.

      So far we covered quite a lot of ground on how to fix common errors when working with git . Most of them have easy enough solutions, however there are times when one has to get out the big guns and rewrite the history of an entire branch. One common use case for this is removing sensitive data (e.g. login credentials for production systems) that were committed to a public repository:

      This will remove the file secrets.txt from every branch and tag. It will also remove any commits that would be empty as a result of the above operation. Keep in mind that this will rewrite your project’s entire history, which can be very disruptive in a distributed workflow. Also while the file in question has now been removed, the credentials it contained should still be considered compromised!

      GitHub has a very good tutorial on removing sensitive data and man git-filter-branch has all details on the various available filters and their options.

      .2 Основы Git — Запись изменений в репозиторий

      Запись изменений в репозиторий

      Итак, у вас имеется настоящий Git-репозиторий и рабочая копия файлов для некоторого проекта. Вам нужно делать некоторые изменения и фиксировать “снимки” состояния (snapshots) этих изменений в вашем репозитории каждый раз, когда проект достигает состояния, которое вам хотелось бы сохранить.

      Запомните, каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (отслеживаемые) и нет (неотслеживаемые). Отслеживаемые файлы — это те файлы, которые были в последнем слепке состояния проекта (snapshot); они могут быть неизменёнными, изменёнными или подготовленными к коммиту (staged). Неотслеживаемые файлы — это всё остальное, любые файлы в вашем рабочем каталоге, которые не входили в ваш последний слепок состояния и не подготовлены к коммиту. Когда вы впервые клонируете репозиторий, все файлы будут отслеживаемыми и неизменёнными, потому что вы только взяли их из хранилища (checked them out) и ничего пока не редактировали.

      Как только вы отредактируете файлы, Git будет рассматривать их как изменённые, т.к. вы изменили их с момента последнего коммита. Вы индексируете (stage) эти изменения и затем фиксируете все индексированные изменения, а затем цикл повторяется. Этот жизненный цикл изображён на рисунке 2-1.

      Рисунок 2-1. Жизненный цикл состояний файлов.

      Определение состояния файлов

      Основной инструмент, используемый для определения, какие файлы в каком состоянии находятся — это команда git status . Если вы выполните эту команду сразу после клонирования, вы увидите что-то вроде этого:

      Это означает, что у вас чистый рабочий каталог, другими словами — в нём нет отслеживаемых изменённых файлов. Git также не обнаружил неотслеживаемых файлов, в противном случае они бы были перечислены здесь. И наконец, команда сообщает вам на какой ветке (branch) вы сейчас находитесь. Пока что это всегда ветка master — это ветка по умолчанию; в этой главе это не важно. В следующей главе будет подробно рассказано про ветки и ссылки.

      Предположим, вы добавили в свой проект новый файл, простой файл README. Если этого файла раньше не было, и вы выполните git status , вы увидите свой неотслеживаемый файл вот так:

      Понять, что новый файл README неотслеживаемый можно по тому, что он находится в секции «Untracked files» в выводе команды status . Статус «неотслеживаемый файл», по сути, означает, что Git видит файл, отсутствующий в предыдущем снимке состояния (коммите); Git не станет добавлять его в ваши коммиты, пока вы его явно об этом не попросите. Это предохранит вас от случайного добавления в репозиторий сгенерированных бинарных файлов или каких-либо других, которые вы и не думали добавлять. Мы хотели добавить README, так давайте сделаем это.

      Отслеживание новых файлов

      Для того чтобы начать отслеживать (добавить под версионный контроль) новый файл, используется команда git add . Чтобы начать отслеживание файла README, вы можете выполнить следующее:

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

      Вы можете видеть, что файл проиндексирован по тому, что он находится в секции “Changes to be committed”. Если вы выполните коммит в этот момент, то версия файла, существовавшая на момент выполнения вами команды git add , будет добавлена в историю снимков состояния. Как вы помните, когда вы ранее выполнили git init , вы затем выполнили git add (файлы) — это было сделано для того, чтобы добавить файлы в вашем каталоге под версионный контроль. Команда git add принимает параметром путь к файлу или каталогу, если это каталог, команда рекурсивно добавляет (индексирует) все файлы в данном каталоге.

      Индексация изменённых файлов

      Давайте модифицируем файл, уже находящийся под версионным контролем. Если вы измените отслеживаемый файл benchmarks.rb и после этого снова выполните команду status , то результат будет примерно следующим:

      Файл benchmarks.rb находится в секции “Changes not staged for commit” — это означает, что отслеживаемый файл был изменён в рабочем каталоге, но пока не проиндексирован. Чтобы проиндексировать его, необходимо выполнить команду git add (это многофункциональная команда, она используется для добавления под версионный контроль новых файлов, для индексации изменений, а также для других целей, например для указания файлов с исправленным конфликтом слияния). Выполним git add , чтобы проиндексировать benchmarks.rb, а затем снова выполним git status :

      Теперь оба файла проиндексированы и войдут в следующий коммит. В этот момент вы, предположим, вспомнили одно небольшое изменение, которое вы хотите сделать в benchmarks.rb до фиксации. Вы открываете файл, вносите и сохраняете необходимые изменения и вроде бы готовы к коммиту. Но давайте-ка ещё раз выполним git status :

      Что за чёрт? Теперь benchmarks.rb отображается как проиндексированный и непроиндексированный одновременно. Как такое возможно? Такая ситуация наглядно демонстрирует, что Git индексирует файл в точности в том состоянии, в котором он находился, когда вы выполнили команду git add . Если вы выполните коммит сейчас, то файл benchmarks.rb попадёт в коммит в том состоянии, в котором он находился, когда вы последний раз выполняли команду git add , а не в том, в котором он находится в вашем рабочем каталоге в момент выполнения git commit . Если вы изменили файл после выполнения git add , вам придётся снова выполнить git add , чтобы проиндексировать последнюю версию файла:

      Игнорирование файлов

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

      Первая строка предписывает Git’у игнорировать любые файлы заканчивающиеся на .o или .a — объектные и архивные файлы, которые могут появиться во время сборки кода. Вторая строка предписывает игнорировать все файлы заканчивающиеся на тильду (


      ), которая используется во многих текстовых редакторах, например Emacs, для обозначения временных файлов. Вы можете также включить каталоги log, tmp или pid; автоматически создаваемую документацию; и т.д. и т.п. Хорошая практика заключается в настройке файла .gitignore до того, как начать серьёзно работать, это защитит вас от случайного добавления в репозиторий файлов, которых вы там видеть не хотите.

      К шаблонам в файле .gitignore применяются следующие правила:

      • Пустые строки, а также строки, начинающиеся с #, игнорируются.
      • Можно использовать стандартные glob шаблоны.
      • Можно заканчивать шаблон символом слэша ( / ) для указания каталога.
      • Можно инвертировать шаблон, использовав восклицательный знак ( ! ) в качестве первого символа.

      Glob-шаблоны представляют собой упрощённые регулярные выражения используемые командными интерпретаторами. Символ * соответствует 0 или более символам; последовательность [abc] — любому символу из указанных в скобках (в данном примере a, b или c); знак вопроса ( ? ) соответствует одному символу; [0-9] соответствует любому символу из интервала (в данном случае от 0 до 9).

      Вот ещё один пример файла .gitignore:

      Шаблон **/ доступен в Git, начиная с версии 1.8.2.

      Просмотр индексированных и неиндексированных изменений

      Если результат работы команды git status недостаточно информативен для вас — вам хочется знать, что конкретно поменялось, а не только какие файлы были изменены — вы можете использовать команду git diff . Позже мы рассмотрим команду git diff подробнее; вы, скорее всего, будете использовать эту команду для получения ответов на два вопроса: что вы изменили, но ещё не проиндексировали, и что вы проиндексировали и собираетесь фиксировать. Если git status отвечает на эти вопросы слишком обобщённо, то git diff показывает вам непосредственно добавленные и удалённые строки — собственно заплатку (patch).

      Допустим, вы снова изменили и проиндексировали файл README, а затем изменили файл benchmarks.rb без индексирования. Если вы выполните команду status , вы опять увидите что-то вроде:

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

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

      Если вы хотите посмотреть, что вы проиндексировали и что войдёт в следующий коммит, вы можете выполнить git diff —cached . (В Git’е версии 1.6.1 и выше, вы также можете использовать git diff —staged , которая легче запоминается.) Эта команда сравнивает ваши индексированные изменения с последним коммитом:

      Важно отметить, что git diff сама по себе не показывает все изменения сделанные с последнего коммита — только те, что ещё не проиндексированы. Такое поведение может сбивать с толку, так как если вы проиндексируете все свои изменения, то git diff ничего не вернёт.

      Другой пример: вы проиндексировали файл benchmarks.rb и затем изменили его, вы можете использовать git diff для просмотра как индексированных изменений в этом файле, так и тех, что пока не проиндексированы:

      Теперь вы можете используя git diff посмотреть непроиндексированные изменения

      а также уже проиндексированные, используя git diff —cached :

      Фиксация изменений

      Теперь, когда ваш индекс настроен так, как вам и хотелось, вы можете зафиксировать свои изменения. Запомните, всё, что до сих пор не проиндексировано — любые файлы, созданные или изменённые вами, и для которых вы не выполнили git add после момента редактирования — не войдут в этот коммит. Они останутся изменёнными файлами на вашем диске. В нашем случае, когда вы в последний раз выполняли git status , вы видели что всё проиндексировано, и вот, вы готовы к коммиту. Простейший способ зафиксировать изменения — это набрать git commit :

      Эта команда откроет выбранный вами текстовый редактор. (Редактор устанавливается системной переменной $EDITOR — обычно это vim или emacs, хотя вы можете установить ваш любимый с помощью команды git config —global core.editor , как было показано в главе 1).

      В редакторе будет отображён следующий текст (это пример окна Vim’а):

      Вы можете видеть, что комментарий по умолчанию для коммита содержит закомментированный результат работы («выхлоп») команды git status и ещё одну пустую строку сверху. Вы можете удалить эти комментарии и набрать своё сообщение или же оставить их для напоминания о том, что вы фиксируете. (Для ещё более подробного напоминания, что же именно вы поменяли, можете передать аргумент -v в команду git commit . Это приведёт к тому, что в комментарий будет также помещена дельта/diff изменений, таким образом вы сможете точно увидеть всё, что сделано.) Когда вы выходите из редактора, Git создаёт для вас коммит с этим сообщением (удаляя комментарии и вывод diff’а).

      Есть и другой способ — вы можете набрать свой комментарий к коммиту в командной строке вместе с командой commit , указав его после параметра -m, как в следующем примере:

      Итак, вы создали свой первый коммит! Вы можете видеть, что коммит вывел вам немного информации о себе: на какую ветку вы выполнили коммит (master), какая контрольная сумма SHA-1 у этого коммита ( 463dc4f ), сколько файлов было изменено, а также статистику по добавленным/удалённым строкам в этом коммите.

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

      Игнорирование индексации

      Несмотря на то, что индекс может быть удивительно полезным для создания коммитов именно такими, как вам и хотелось, он временами несколько сложнее, чем вам нужно в процессе работы. Если у вас есть желание пропустить этап индексирования, Git предоставляет простой способ. Добавление параметра -a в команду git commit заставляет Git автоматически индексировать каждый уже отслеживаемый на момент коммита файл, позволяя вам обойтись без git add :

      Обратите внимание на то, что в данном случае перед коммитом вам не нужно выполнять git add для файла benchmarks.rb.

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

      Для того чтобы удалить файл из Git’а, вам необходимо удалить его из отслеживаемых файлов (точнее, удалить его из вашего индекса) а затем выполнить коммит. Это позволяет сделать команда git rm , которая также удаляет файл из вашего рабочего каталога, так что вы в следующий раз не увидите его как “неотслеживаемый”.

      Если вы просто удалите файл из своего рабочего каталога, он будет показан в секции “Changes not staged for commit” (“Изменённые но не обновлённые” — читай не проиндексированные) вывода команды git status :

      Затем, если вы выполните команду git rm , удаление файла попадёт в индекс:

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

      Другая полезная штука, которую вы можете захотеть сделать — это удалить файл из индекса, оставив его при этом в рабочем каталоге. Другими словами, вы можете захотеть оставить файл на винчестере, и убрать его из-под бдительного ока Git’а. Это особенно полезно, если вы забыли добавить что-то в файл .gitignore и по ошибке проиндексировали, например, большой файл с логами, или кучу промежуточных файлов компиляции. Чтобы сделать это, используйте опцию —cached :

      В команду git rm можно передавать файлы, каталоги или glob-шаблоны. Это означает, что вы можете вытворять что-то вроде:

      Обратите внимание на обратный слэш ( \ ) перед * . Он необходим из-за того, что Git использует свой собственный обработчик имён файлов вдобавок к обработчику вашего командного интерпретатора. Эта команда удаляет все файлы, которые имеют расширение .log в каталоге log/ . Или же вы можете сделать вот так:

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

      Перемещение файлов

      В отличие от многих других систем версионного контроля, Git не отслеживает перемещение файлов явно. Когда вы переименовываете файл в Git’е, в нём не сохраняется никаких метаданных, говорящих о том, что файл был переименован. Однако, Git довольно умён в плане обнаружения перемещений постфактум — мы рассмотрим обнаружение перемещения файлов чуть позже.

      Таким образом, наличие в Git’е команды mv выглядит несколько странным. Если вам хочется переименовать файл в Git’е, вы можете сделать что-то вроде:

      и это отлично сработает. На самом деле, если вы выполните что-то вроде этого и посмотрите на статус, вы увидите, что Git считает, что произошло переименование файла:

      Однако, это эквивалентно выполнению следующих команд:

      Git неявно определяет, что произошло переименование, поэтому неважно, переименуете вы файл так или используя команду mv . Единственное отличие состоит лишь в том, что mv — это одна команда вместо трёх — это функция для удобства. Важнее другое — вы можете использовать любой удобный способ, чтобы переименовать файл, и затем воспользоваться add/rm перед коммитом.

      Что такое GIT и как он работает?

      10.07.2020 Время прочтения: 3 минуты

      Что такое Git?

      Если ввести такой запрос в поисковик, большинство источников ответят так: Git (от англ. – Global Information Tracker) – это распределенная система управления версиями. И в этом определении, не очень понятном неподготовленному читателю, вся суть Git’а.

      Разберемся, что же значит «управление версиями» и когда система управления версиями становится «распределенной».

      Git – это разновидность VCS (Version Control System). А VCS – это программа для работы с постоянно изменяющейся информацией. Такое ПО может хранить множество версий одного и того же файла (документа) и возвращаться к более раннему состоянию (версии).

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

      Какие VCS есть в природе:


      • собственно Git;
      • SVN;
      • Mercurial;
      • CVS (Concurrent Versions System);
      • Team Foundation Server.

      Все они делятся на два типа:

      • распределенные (Git, Mercurial) – изменения хранятся в локальных хранилищах компьютеров и оттуда синхронизируются с другими компьютерами;
      • централизованные (CVS, SVN) – все данные хранятся на центральном сервере, и оттуда каждый локальный компьютер получает обновленные данные.

      Git относится к распределенным системам, поэтому не зависит от центрального сервера, где хранятся файлы. Git сохраняет данные в локальном репозитории. Что такое репозиторий Git? Это каталог на жестком диске рабочего компьютера программиста. Для большей стабильности и ускорения синхронизации разных версий проекта локальный репозиторий хранят онлайн в специальных сервисах: Github, Gitlab, Bitbucket.

      Зачем нужен Git

      Обычно вся работа над проектом (сайтом) со стороны разработчика сводится к трем простым операциям:

      • удаление;
      • добавление;
      • изменение.

      И когда сайт состоит из менее чем 10 файлов, то проблем с этим нет: и так понятно, где что удалено или добавлено.

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

      С приходом VCS работать стало гораздо проще:

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

      Как работает Git: основы

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

      Но подход «просто забэкапить этот файл» весьма опасен и может дать сбой. И цена ошибки – не один час потраченного времени на восстановление.

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

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

      Схема работы GIT

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

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

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

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

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

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

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

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

      Пошаговая инструкция по работе с системой контроля версий GIT и сервисом GitHub для новичков

      Наверняка многие слышали о системе контроля версий git. Сегодня мы рассмотрим весь путь от установки git до внесения своих изменений в удаленный репозиторий на примере библиотеки OsEngine.Для начала скачаем клиент git по ссылке и установим его. Вопросов возникнуть не
      должно, просто везде жмем Next. Далее взаимодействие с git будет рассмотрено на примере работы с консольным клиентом.Следующим шагом необходимо зарегистрироваться на сайте https://github.com/. Теперь мы можем присоединиться к работе над OsEngine. Для этого перейдем к репозиторию проекта и в правом верхнем углу нажмем кнопку Fork.

      Этим действием мы создали fork (другими словами ответвлние), который хранится в репозитории нашей учетной записи и теперь можно вносить в него изменения, не опасаясь чего-то сломать в главной ветке проекта. Далее этот самый наш репозиторий на github мы будем называть удаленным репозиторием.
      Теперь приступим к работе с самим git и первым делом нам надо создать на своем компьютере локальную копию удаленного репозитория. Для этого переходим в желаемую папку, в контекстном меню выбираем пункт Git Bash Here и у нас откроется консоль.

      Дальше идем на github в наш репозиторий и нажимаем на зеленую кнопку Clone or download (1) и затем на кнопку под номером 2 на снимке.

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

      $ git clone «здесь вставляем ссылку без кавычек»

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


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

      Настройка git

      Перед началом работы с git, его необходимо настроить. Откройте git bash, задайте логин и пароль командами:

      $ git config —global user.name “ваше имя”
      $ git config —global user.email “ваша почта”

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

      $ git config —global —list

      Работа с ветками

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

      $ git branch желаемое имя

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

      $ git checkout имя ветки

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

      $ git checkout master

      $ git branch –m новое имя

      команда $ git branch позволяет определить в какой ветке сейчас находимся. Удаляет ветку команда

      $git branch –D имя ветки

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

      $ git merge имя ветки

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

      Коммиты

      Вся суть использования git в commits (коммиты). Коммит – это так называемый снимок состояния проекта на определенном этапе
      разработки. Например: у нас есть библиотека OsEngine, мы добавили в
      нее новый индикатор и закоммитили, потом решили подправить какой-либо файл в
      движке и после этого приложение крашится или не хочет правильно работать. Чтобы
      не делать лишнюю работу и не править все обратно, мы можем просто напросто
      откатиться к прошлому коммиту, когда приложение работало как надо. Соответственно
      вся работа с git крутится вокруг создания, удаления, редактирования, слияния
      коммитов и веток.

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

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

      $ git add README

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

      $ git add .

      Заметьте, именно с точкой в конце и пробелом перед ней.

      Удаление файлов из индекса

      Если вы случайно проиндексировали не нужный файл, то удалить его из индекса поможет команда git reset, например удалить файл README из индекса:

      $ git reset README

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

      $ git checkout — имя файла

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

      Создание коммита

      Теперь можно коммитить изменения, делается это при помощи команды:

      $ git commit –m “Здесь должен быть комментарий в кавычках”

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

      $ git log

      $ git show покажет только последние изменения. Для выхода из режима просмотра нажмите q.

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

      $ git commit –a –m “комментарий в кавычках”

      -a означает: добавить все изменения в индекс до передачи.
      -m: комментарий.

      Редактирование, удаление, коммита

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

      $ git revert HEAD

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

      $ git revert HEAD

      Команда $ git reset —soft HEAD

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

      $ git reset — hard HEAD

      полностью удалит три последних коммита.

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

      $ git status – основная команда, отслеживающая состояние файлов. Она показывает есть ли изменения в отслеживаемых файлах или наличие не отслеживаемых файлов. Отслеживаемые файлы – это те файлы, которые есть в предидущем коммите. Если же мы добавили в проект новый файл, то он будет считаться не отслеживаемым.

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

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

      $ git push origin master

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

      $ git pull

      Использование SSH ключей

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

      $ ssh-keygen

      Далее 3 раза нажать enter и в дирректории по умолчанию C:\Users\имя пользователя\.ssh появиться папка с ключами. Нужно открыть файл
      id_rsa типа PUB в любом текстовом редакторе и скопировать его содержимое. Затем идем на github в настройки своей учетной записи

      После чего в колонке слева выбираем пункт: SSH and GPG keys и жмем зеленую кнопку справа New SSH key

      задаем Title, в поле Key вставляем данные, скопированные из ключа и жмем

      Слияние веток на github

      После того как вы внесли все необходимые изменения в свой удаленный репозиторий, можно отправить запрос на слияние с главным репозиторием проекта OsEngine. Просто нажмите кнопку New pull request

      В данной статье мы рассмотрели основные команды git, их хватит для начала работы над проектом OsEngine, используя git и сервис github.

      Цукерберг рекомендует:  Помощь - Помогите закончить проект на Spring Boot
  • Понравилась статья? Поделиться с друзьями:
    Все языки программирования для начинающих