Git за полчаса руководство для начинающих


Оглавление (нажмите, чтобы открыть):

Git для чайника. Команды которые помогут начать работу.

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

С помощью Git Вы сможете размещать свой код на GitHub, BitBucket и Google Code.

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

С чего начать?

Нам понадобиться программа Git Bash, это шелл сделанный на основе Cygwin, поэтому возможно использование Unix-команд, вроде ls, cd, mkdir. Скачать его можно по следующей ссылке https://git-scm.com/.

Настройка Git

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

Также нам нужно настроить параметры установок окончания строк, для Windows мы вводим две команды

На этом настройка заканчивается, можем начинать работу с проектом.

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

Допустим у нас есть папка с проектом, которую мы хотим разместить на GitHub.

1. Создаем репозиторий на сайте.

2. Инициализируем папку для Git репозитория. Это нужно сделать только один раз для каждого проекта.

3. Связываем папку с удаленным репозиторием

4. Добавляем все новые и измененные файлы

5. Помечаем все новые и измененные файлы сообщением (commit)

— вместо message вписываем сообщение, например Initial Commit. или Bugfix.

6. Закачиваем код на удаленный репозиторий

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

7. Можно посмотреть статус изменений, которые были сделаны.

8. Для скачивания репозитория используется команда

Второй компьютер

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

1. Клонирование репозитория

В результате git скачает удаленный репозиторий в новую папку test-project

2. После каких-то изменений в коде, выполняем все те же команды

Откат изменений

1. Полный откат до предыдущего коммита

2. Сброс изменений в файле на версию коммита

3. Откат до установленного тега, например v1

Для более лучшего пониманию лучше ознакомиться с интерактивным туром по Git

Что Такое GIT – Руководство по Основам GIT

Введение

Система контроля версий или VCS может значительно облегчить работу разработчиков, пытающихся проанализировать изменения и вклады в общий код. Проще говоря, система контроля версий – это ключевой элемент в системе управления настройками программного обеспечения, которые отвечают потребностям проекта. VCS дают возможность назначать для определенных изменений/ревизий/обновлений буквенные или числовые значения. Также могут предоставить информацию о временных метках и идентификаторе человека внесшего изменения. В этом руководстве мы расскажем вам о самой часто используемой системе контроля версий – GIT. Вы узнаете, что такое GIT и какие он имеет преимущества перед остальными VCS, а также мы расскажем об установке GIT на разные системы и его правильном использовании.

Что такое GIT?

В 2005 году, Линус Торвальдс (человек, известный тем, что стоял за созданием ядра Linux OS) разработал GIT для управления версиями ядра Linux, однако, чуть позднее его поддержкой занялся другой человек, японский инженер-программист – Джунио Хамано. На сегодняшний день, GIT – это одна из самых известных систем контроля версий с открытым исходным кодом, на которую полагаются миллионы проектов по всем миру (включая как коммерческие, так и бесплатные проекты). GIT – это полностью бесплатное программное обеспечение, поддерживающее множество ОС, таких как Mac, Linux, Windows и Solaris. Скачать соответствующие дистрибутивы можно с официального сайта GIT. Вот несколько функций GIT достойных упоминания:

  1. Распределенная система управления версиями, GIT следует принципу одноранговой сети – peer to peer (равный к равному) в отличии от других систем вроде Subversion (SVN), которая основана на модели client-server (клиент-сервер).
  2. GIT позволяет разработчикам иметь множество совершенно независимых веток кода. Создание, удаление и объединение этих веток происходит без каких-либо проблем и больших затрат времени.
  3. В GIT все операции атомарны; это означает, что любое действие может быть полностью удачным или провалиться (без каких-либо изменений). Это действительно важно, так как в некоторых системах контроля версий (вроде CVS), где действия не атомарны, некоторые повисшие операции по всему хранилищу, могут оставить его в нестабильном состоянии.
  4. В отличии от других VCS, таких как SVN или CVS где метаданные хранятся в скрытых папках (.cvs, .svn, и т.д.), в GIT все данные расположены в каталогах .git.
  5. Он использует модель данных, которая помогает обеспечить криптографическую целостность всего, что присутствует в репозитории. Каждый раз когда файлы добавляются или коммитятся, генерируются их контрольные суммы; аналогичный процесс происходит при их извлечении.
  6. Еще одна превосходная функция, присутствующая в GIT – это его индекс. В пределах индекса, разработчики могут форматировать коммиты и просматривать их до фактического применения.

Вот пожалуй мы и ответили на вопрос “Что такое GIT”.

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

Шаг 1 — Установка GIT

В данной части руководства будут показаны простейшие способы установки GIT на разные операционные системы:

Вариант 1 — Установка GIT на Windows

Установка GIT на Windows, осуществляется также просто, как и установка любого другого приложения; загрузка установщика и его запуск. Выполните данные шаги для установки GIT на Windows:

  1. Посетите этот сайт и скачайте установщик GIT для Windows.
  2. После загрузки, запустите установку двойным нажатием мыши. Следуйте инструкциям на экране, продолжайте нажимать Next (Далее) и наконец Finish(Финиш) для успешного завершения установки.
  1. Запустите командную строку и впишите следующие команды в терминале:

ЗАМЕТКА! Не забудьте изменить John Smith и example@email.com на ваши собственные личные данные. Любые впоследствии созданные коммиты будут связаны с этими данными.

Это все что нужно для установки GIT на Windows.

Вариант 2 — Установка GIT на Mac

Существует множество способов для установки GIT на Mac, есть даже вероятность того, что GIT уже установлен на вашем компьютере. Eсли у вас установлен XCode; выполните следующую команду в терминале для проверки:

Если ваш результат будет схож с таким git version 2.7.0 (Apple Git-66), тогда можете смело приступать к работе с GIT, если нет, то выполните следующие шаги:

  1. Посетите этот сайт и скачайте последнюю версию установщика для Mac.
  2. Следуйте инструкциям установщика и завершите установку.
  1. Используйте команду git –version снова, для подтверждения того, что установка была успешна.
  2. Выполните следующие команды в терминале для настройки вашего имени пользователя и адреса электронной почты, которые будут связаны с вашим GIT аккаунтом:

ЗАМЕТКА! Не забудьте изменить John Smith и example@email.com на ваши собственные данные. Любые созданные в дальнейшем коммиты будут связаны с ними.

Вариант 3 — Установка GIT на Linux

Если вы являетесь пользователем Linux, вы должны уметь устанавливать программы и пакеты на ваш компьютер используя простые команды apt-get или yum install; чтож, установка GIT ничем отличается:

Для пользователей Debian/Ubuntu (apt-get):

  1. Откройте терминал и выполните следующую команду:
  1. Проверьте правильности установки командой git –version.
  2. Выполните следующие команды в терминале для настройки вашего имени пользователя и адреса электронной почты, которые будут связаны с вашим GIT аккаунтом:

ЗАМЕТКА! Не забудьте изменить John Smith и example@email.com на ваши собственные данные. Любые созданные в дальнейшем коммиты будут связаны с ними.

Fedora (yum/dnf):

Вы можете получить пакеты GIT, используя как yum, так и dnf.

  1. Откройте терминал и выполните следующие команды:
  1. Проверьте правильность установки командой git –version.
  2. Выполните следующие команды в терминале для настройки вашего имени пользователя и адреса электронной почты, которые будут связаны с вашим GIT аккаунтом:

ЗАМЕТКА! Не забудьте изменить John Smith и example@email.com на ваши собственные данные. Любые созданные в дальнейшем коммиты будут связаны с ними.

Шаг 2 — Использование GIT

Теперь, когда GIT настроен на вашем устройстве Windows / Mac / Linux, давайте изучим основы GIT и то, как вы можете начать с ним работу.

  • Создание/настройка/клонирование репозитория:

Репозиторий является одним из самых сильных инструментов любого проекта с контролем версий. Для превращения любого каталога в репозиторий GIT поможет простая команда git init . После выполнения команды, в месте где была выполнена команда должен появиться каталог с названием .git.

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

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

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

После завершения создания, вы сможете управлять своим репозиторием нажав кнопку Управление.

  • Рабочий процесс:

Теперь, когда репозиторий настроен, давайте поговорим о его структуре. Каждый локальный репозиторий состоит из трех деревьев: рабочего каталога – который состоит из файлов, индекса – который играет роль места где проходят все изменения перед их применением и HEAD – являющегося указателем на последний коммит пользователя. Сам рабочий процесс можно объяснить таким образом: пользователь добавляет файл или изменение из рабочего каталога в индекс, далее после его просмотра и анализа оно применяется к HEAD.

  • Команды Add и Commit:

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

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

ЗАМЕТКА! Как только команда commit будет выполнена (из рабочего каталога), будет произведен коммит файла к HEAD, однако отправка на удаленный репозиторий произведена не будет, для этого используется отдельная команда.

  • Дальнейшее продвижение изменений:

После коммита ваших изменений (и если они готовы к отправке в оригинальный репозиторий), вы можете использовать команду push.

После выполнения команды git push origin master из рабочего каталога, все изменения присутствующие в HEAD будут отправлены на удаленный репозиторий. В вышеупомянутой команде, значение master должно быть изменено на название ветки для которой вы хотите произвести коммит изменений.

Однако, если существующий репозиторий еще не был клонирован и вы хотите установить соединение между вашим репозиторием и удаленным сервером, сделайте это, запустив следующую команду:

ЗАМЕТКА! Замените значение в коде на адрес удаленного сервера, который вам необходим в данный момент.

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

Еще одной превосходной и продвинутой особенностью GIT является возможность разработчикам и руководителям проектов создавать несколько независимых веток в рамках одного проекта. Основная цель ветки – это разработка функций, которые при этом находятся изолированно и не влияют друг на друга. Стандартная ветвь в любом проекте всегда является главной веткой. По мере необходимости, может быть создано любое количество веток, которые в конечном итоге могут быть объединены с главной веткой.

Новая ветка может быть создана с помощью данной команды:

feature_n это имя ветки

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

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

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

  • Обновление и объединение:

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

Для объединения активной ветки с какой-либо другой воспользуйтесь этой командой: git merge feature_n.

Используете ли вы pull или merge, GIT всегда пытается справиться с возникающими конфликтами самостоятельно, но это не всегда у него получается. В случае неудачи выполнения команды, пользователь должен разрешить возникший конфликт вручную. После того, как вы отредактировали файлы (для устранения конфликта), пометьте их как merged с помощью команды:

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

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

1c2d2d56fa в вышеприведенной команде относится к первым 10 символам commit-id, на которые ссылается тег. Идентификатор коммита или Commit ID можно найти в журнале.

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

Сжатую версию журнала (один коммит на строке) можно просмотреть при помощи команды :

Для просмотра измененных файлов:

  • Замена локальных изменений:

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

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

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

Заключение

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

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

Введение¶

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

Мастер Йода рекомендует:  Как включить поддержку javascript в наиболее популярных браузерах Javascript

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ветвление¶

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рецепты¶

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

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

Git для начинающих

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

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

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

Установка Git

На официальном сайте Git есть подробная информация о его установке на различные системы — Linux, Mac, Windows. В нашем случае мы будем использовать Ubuntu 13.04, и Git мы будем устанавливать посредством apt-get .

Начальная конфигуация

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

Первым делом надо инициализировать Git-репозитарий в директории проекта. Сделать это можно командой init , которая создает директорию .git со всей информацией о вашем проекте.

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

Стоит отметить, что если вы не укажете ваш адрес и имя, то вместо них будут использоваться значения по умолчанию. В нашем случае значениями по умолчанию будут donny и donny@ubuntu.

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

Готовим файлы для коммита

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

Проверяем состояние репозитария

Теперь, когда в вашем проекте есть файлы, давайте посмотрим, как Git с ними обращается. Чтобы проверить текущий статус репозитария, используйте команду git status

Добавляем файлы в Git

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

Проверив статус репозитария видим, что один из файлов уже добавлен в него.

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

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

Удаляем файлы

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

Коммитим изменения

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

Указывайте сообщение, которое будет содержать полезную информацию, так как они помогают понять, что же именно было изменено в рамках данного коммита. Избегайте каких-то общих сообщений, типа “Правил баги”. Если у вас есть баг-трекер, вы можете указать сообщение типа “Поправлен баг #123”. Хорошая практика — указывать в сообщении имя ветки или улучшения. Например, “Управление активами — добавлена возможность генерировать PDF на основе актива” — понятное и доходчивое сообщение.

Git определяет коммит длинным шестнадцатеричным номером. Обычно, нет необходимости копировать всю строку, первых 5-6 символов достаточно для идентификации конкретного коммита. По скриншоту видно, что наш коммит идентифицируется числом 8dd76fc .

Дальнейшие коммиты

Давайте изменим несколько файлов после того, как мы их закоммитили. После того, как мы их изменили, git status сообщит о том, что у нас есть измененные файлы.

Можно посмотреть, что же изменилось в этих файлах с момента предыдущего коммита, с помощью команды git diff . Если вы хотите просмотреть изменения для конкретного файла, можно использовать git diff .

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

Можно избежать использования этой команды, если добавить параметр -a к git commit . Эта команда проиндексирует все измененные файлы, и закоммитит их. Но такой подход может быть довольно опасным, так по ошибке можно закоммитить то, что не хотелось. Например, скажем, что вы открыли файл, и случайно его изменили. При индексировании измененных файлов вы будете оповещены об изменениях в каждом файле. Но если вы отправите на коммит все измененные файлы не глядя с помощь. git commit -a , то будут закоммичены все файлы, включая те, которые вы коммитить не хотели.

Как только вы проиндексировали файлы, можно приступать к коммиту. Как упоминалось ранее, к коммиту можно указать сообщение с помощью ключа -m . Но также можно указывать и многострочные комментарии с помощью команды git commit , которая открывает консольный редактор для ввода комментария.

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

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

Она отобразит полную историю проекта в виде списка коммитов и информацию о них. Информация о коммите содержит хеш коммита, автора, время и сообщение коммита. Есть множество видов команды git log , с которыми придется познакомиться в случае использования ветвления в Git. Чтобы посмотреть детали конкретного коммита, и измененные файлы, выполните следующую команду:

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

Данный урок подготовлен для вас командой сайта ruseller.com
Источник урока: https://www.sitepoint.com/git-for-beginners/
Перевел: Станислав Протасевич
Урок создан: 23 Мая 2014
Просмотров: 55630
Правила перепечатки

5 последних уроков рубрики «Разное»

Как разместить свой сайт на хостинге? Правильно выбранный хороший хостинг — это будущее Ваших сайтов

Проект готов, Все проверено на локальном сервере OpenServer и можно переносить сайт на хостинг. Вот только какую компанию выбрать? Предлагаю рассмотреть хостинг fornex.com. Отличное место для твоего проекта с перспективами бурного роста.

Разработка веб-сайтов с помощью онлайн платформы Wrike

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

20 ресурсов для прототипирования

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


Топ 10 бесплатных хостингов

Небольшая подборка провайдеров бесплатного хостинга с подробным описанием.

Быстрая заметка: массовый UPDATE в MySQL

Ни для кого не секрет как в MySQL реализовать массовый INSERT, а вот с UPDATE-ом могут возникнуть сложности. Чтобы не прибегать к манипуляциям события ON_DUPLICATE можно воспользоваться специальной конструкцией CASE … WHEN … THEN.

Работа с 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 . Отправляем изменения в форк.

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

      DVCS Git и TortoiseGit в картинках. Пособие для начинающих чайников.

      Что такое git? git — это распределенная система управления версиями.

      Не так давно проект «Google API в Delphi» успешно переехал на новый адрес и теперь находится под управлением распределенной системы контроля версий Git

      Небольшое введение. О чем вообще пойдет речь

      Git — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux.

      То обстоятельство, что система создавалась «под Linux» уже как бы намекает на то, что без консоли нам не обойтись. Но не стоит махать руками и кричать «консоль отстой, git — в печь» и все такое. Поверьте — консоль Linux и консоль Windows имеют для обычного пользователя только одно общее свойство — чёрный экран при первом запуске. Команды Linux (ИМХО) просты и запоминаются без проблем, а работать с консолью не составляет особого труда даже для такого чайника, как я.

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

      Это обстоятельство и поставило меня в начале работы с Git в тупик.
      Как это так commit и не в центральный репозиторий?
      Как правильно отправлять данные на сервер?
      Как вообще начинать работу?

      Эти и ещё многие другие вопросы посещали меня на старте работы с Git. Сейчас я не буду углубляться далеко в теоретические вопросы Git, да и вообще любых систем контроля версия — всего этого полно в Сети. А затрону один практический момент — как начать работу вообще, чтобы потом не было мучительно больно за бесцельно потерянные исходники.

      Качаем и устанавливаем софт

      Для работы с Git под Windows имеются вполне работоспособные и юзабельные решения, например, msysgit. Однако если Вы ранее имели опыт работы с SVN и использовали в работе TortoiseSVN, то видимо, Вам захочется иметь аналог подобного интерфейса и для Git? Нет проблем вот аналог TortoiseSVN для Git — TortoiseGit.
      По сути TortoiseGit после нажатия команды из контекстного меню запускает консольную команду из MSysGit и рисует в окошко ее вывод. Если вы не хотите или просто не хватает времени детально разобраться в консольных командах Git, то TortoiseGit — то, что Вам нужно.
      Итак, если Вы работаете под 32-х битной Windows, то Вам необходимо скачать следующий софт:

      1. msysgit — качаем Git-1.7.1-previewXXXXXXXX.exe (11,6 Mb) Git For Windows
      2. TortoiseGit. На момент написания статьи последней была версия TortoiseGit-1.5.2.0-32bit.msi (19.6 MB). Новые версии Вы можете найти также по приведенной ссылке.

      Получается, что скачать нам надо чуть больше 30 Mb.
      Теперь устанавливаем скачанные программы.

      При установке msysgit настройки по умолчанию можно не изменять.
      При установке TortoiseGit выбираем в окне «Choose SSH Client» второе значение:

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

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

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

      1. Регистрация на GitHub’e.

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

      Профиль на GitHub.com

      2. Генерируем ключ для доступа по SSH.
      Вот тут хочешь-не хочешь, а надо запускать консоль. После установки msysgit у Вас на рабочем столе появился новый ярлык — Git Bush — вот с помощью него и запускаем консоль.

        Набираем в консоли следующую команду

      ssh-keygen -t rsa -C «E-Mail из Вашего профиля»

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

      Заходим в директорию, открываем с помощью «Блокнота» файл ida_rsa.pub и копируем все его содержимое в буфер обмена.

      3. Заносим публичный ключ доступа в профиль.

      Для записи публичного ключа в профиль:

      1. Заходим в свой профиль github и жмем ссылку Account Settings (сверху)
      2. Выбираем пункт «SSH Public Keys»
      3. Жмем ссылку «Add another public key»

      Перед вами появится форма добавления нового публичного ключа. Вставляем из буфере весь скопированный ранее текст (из файла >только в поле key — поле Title оставляем пустым .

      На этом работа с публичными ключами закончена.

      4. Просимся в проект.

      Для этого достаточно найти наш проект на github и отправить одному из администраторов запрос на предоставление доступа к репозиторию. Или просто отправить мне email с логином на github. После того как вы будите записаны в список разработчиков проекта можно переходить к следующей фазе работы — получение исходников.

      Работа со своим первым репозиорием Git

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

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

      1. Вызываем контекстное меню и выбираем пункт «TortoiseGit — Settings«:

      В появившемся окне переходим сразу к пункту «Git — Config» и записываем свое имя и адрес электронной почты. Эти данные должны в точности совпадать с теми, что записаны в Вашем аккаунте на github, иначе ваш ключ просто не подойдет.

      2. Клонируем репозиторий. Для этого заходим на страницу проекта, и копируем в буфер адрес:

      Теперь жмем правой кнопкой мыши на директории, в которой будем хранить исходники и в меню выбираем «Git Clone..«:

      В открывшемся окне в поле URL вставляем скопированный адрес и жмем «Ok»:

      Начнется процесс клонирования репозитория.

      Всё вышесказанное можно было бы заменить всего двумя командами в консоли:

      После клонирования репозитория Вы автоматически переключитесь на нашу главную ветку (master). Так как каждый из нас занят определенной работой в проекте, то у каждого своя ветвь в репозитории, поэтому и Вам придется создавать свой branch. Делается это достаточно просто.

      3. Создаем свою ветку. Для этого жмем правую кнопку мыши на директории в которую мы клонировали репозиторий и выбираем в меню «TortoiseGit — Create Branch«:

      В открывшемся оке задаем название новой ветки и указываем на основании какой ветки репозитория мы будем создавать новую. Жмем «Ок», подтверждая создание ветки. Теперь переключаемся на свой новый branch.

      Выбираем в меню «TortoiseGit — Switch/Checkout…«:

      В открывшемся окне выбираем нашу новую ветку и жмем «Ок». Убеждаемся, что мы успешно переключились:

      По сути, все что касалось создания нового branch’a в консоли решилось бы всего одной командой:

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

      5. Вносим изменения в репозиторий. После того как внесены какие-то изменения нам необходимо их закрепить в Git. И здесь опять же проявляется отличие этой системы контроля версий от того же SVN. Дело в том, что Commit в Git не сбрасывается сразу на сервер. Для того, чтобы внести изменения в удаленный репозиторий используется команда PUSH . В общем виде работа может быть построена следующим образом:

      1. Вносятся изменения в проект

      2. Изменения закрепляются в вашем локальном репозитории, используя команду Commit в меню или, используя консоль:

      3. Когда Вам необходимо/удобно/требуется закрепить все изменения на сервере выполняем push в свою ветку (brunch). Команда консоли выглядит так:

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

      Для этого выбираем новый файл, вызываем меню и выбираем «Add…»:

      По рисунку можно видеть, что я вношу в индекс новый файл text.txt. Жмем «Ok».

      После того как файл добавлен, можно сразу же сделать Commit — кнопка Commit появится в окне с выводом консоли. Жмем её и откроется окно для внесения Commit’a:

      Заполняем поле с описанием, жмем «Ок» и коммит готов. Если хотите сразу отправить эти изменения в репозиторий, то в окне с выводом консоли появится также кнопка PUSH. Если же Вас не устраивает таскать по 1 файлику туда-сюда или изменения столь незначительны, что их нет смысла отправлять на сервер, то просто продолжаете дальше кодить, а push выполним позднее.

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

      1. Зажимаем Shift и вызываем контекстное меню. В меню должны появится дополнительные команды:

      Выбираем команду Push. Перед Вами откроется окно следующего содержания:

      Все, что от Вас требуется на данном этапе — нажать на кнопку (на рисунке она выделена красным) найти в списке удаленную ветку в которую вы делаете push и два раза нажать Ok. Все изменения, произведенные Вами в локальном репозитории отправятся в Сеть.

      Пошаговая инструкция по работе с git и github для студентов

      В первую очередь надо установить клиент git: обязательно потребуется консольный клиент, доступный по ссылке https://git-scm.com/downloads (поддерживаются основные ОС), графический клиент можно установить по желанию, исходя из своих предпочтений. На Unix системах можно воспользоваться менеджером пакетов (yum на fedora и подобных или apt-get на debian, ubuntu и подобных) вместо того, чтобы скачивать установщик с сайта.

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

      • Чтобы у вас складывалось понимание происходящего и при возникновении проблем вы могли четко объяснить, что вы делали, и было видно, что пошло не так.
      • Все нажатия кнопок в графических клиентах в итоге сводят к выполнению определнных команд консольного клиента, в то же время возможности графических клиентов ограничены по сравнению с консольным
      • У тех, кто будет работать в классе на стоящих там компьютерах, не будет другого выбора, кроме как пользоваться консольным клиентом (на сколько мне известно, никаких графических клиентов для git там не установлено)

      Аккаунт и репозитории на github.com

      Затем надо зарегистрироваться на https://github.com/. После чего можно будет создавать свои репозитории или присоединиться к работе над проектами коллег, сделав fork другого репозитория. Вам предлагается начать с создания fork-а к заведенному мной репозиторию https://github.com/andreiled/mipt-cs-4sem, где я буду выкладывать примеры кода к занятиям и задания. О механизме обмена кодом между пользователями мы поговорим на следующем занятии.

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

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

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

      1. Открываем консольный клиент.
      • На Windows после установки клиента появляется пункт Git Bash в контекстом меню папки. Достаточно перейти в желаемую папку и воспользоваться этим пунктом меню.
      • На Unix системах достаточно открыть терминал и перейти в нужную директорию. При стандартной установке консольного клиента будет доступна команда git без дополнительных усилий.
      1. Выполняем команду git clone https://github.com/%user_login%/%repo_name%.git . Полную https ссылку на репозиторий для его выкачивания можно также найти на странице самого репозитория на github. После этого в текущей папке появится новая папка с именем %repo_name% , содержащая копию удаленного (remote) репозитория.
      2. Переходим в свежесозданную папку репозитория и настраиваем его:
      3. git config user.name ivan.ivanov
      4. git config user.email ivanov@example.com

      Внесение и оформление изменений в локальном репозитории

      1. Воспользовавшись командой git status можно узнать, на какой ветке (branch) репозитория вы сейчас находитесь, какие изменения присутствуют в вашей рабочей копии и другую информацию.
        Рабочей копией называется совокупность файлов в локальной папке репозитория за исключением служебных файлов.
      2. После внесения каких-либо изменений в рабочую копию их можно закоммитить в локальный репозиторий:
      3. сначала нужная часть изменений подготавливается к коммиту с использованием команды git add %file_path%
      4. после чего производится коммит командой git commit
        Использование команды без аргументов откроет текстовый редактор, где надо будет написать комментарий для коммита, коммит обязательно должен иметь комментарий. Другим вариантом задания комментария к коммиту является использование команды git commit -m «%commit_message%»
      5. Историю изменений можно посмотреть командой git log или git log —name-only . Если вся история изменений не умещается на экране, то можно пользоваться клавишами прокрутки на клавиатуре («стрелочки», PgUp, PgDown), выход из режима просмотра изменений осуществляется нажатием клавиши «q».

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

      После того, как были выполнены нужные локальные коммиты, изменения можно загрузить в удаленный репозиторий с помощью команды git push origin master . GIT клиент при этом запросит имя пользователя и пароль для доступа к github.
      Выполнение этой команды может закончиться с ошибкой, если в локально репозитории отсутствуют последние изменения, имеющиеся в удаленном репозитории. Для решения этой проблемы надо выполнить команду git pull , которая скачает последние изменения из удаленного репозитория и смержит их с вашими локальными правками, после чего можно повторить команду git push .

      Git для чайника. Команды которые помогут начать работу.

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

      С помощью Git Вы сможете размещать свой код на GitHub, BitBucket и Google Code.

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

      С чего начать?

      Нам понадобиться программа Git Bash, это шелл сделанный на основе Cygwin, поэтому возможно использование Unix-команд, вроде ls, cd, mkdir. Скачать его можно по следующей ссылке https://git-scm.com/.

      Настройка Git

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

      Также нам нужно настроить параметры установок окончания строк, для Windows мы вводим две команды

      На этом настройка заканчивается, можем начинать работу с проектом.

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

      Допустим у нас есть папка с проектом, которую мы хотим разместить на GitHub.

      1. Создаем репозиторий на сайте.

      2. Инициализируем папку для Git репозитория. Это нужно сделать только один раз для каждого проекта.

      3. Связываем папку с удаленным репозиторием

      4. Добавляем все новые и измененные файлы

      5. Помечаем все новые и измененные файлы сообщением (commit)

      — вместо message вписываем сообщение, например Initial Commit. или Bugfix.

      6. Закачиваем код на удаленный репозиторий

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

      7. Можно посмотреть статус изменений, которые были сделаны.

      8. Для скачивания репозитория используется команда

      Второй компьютер

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

      1. Клонирование репозитория

      В результате git скачает удаленный репозиторий в новую папку test-project

      2. После каких-то изменений в коде, выполняем все те же команды

      Откат изменений

      1. Полный откат до предыдущего коммита

      2. Сброс изменений в файле на версию коммита

      3. Откат до установленного тега, например v1

      Для более лучшего пониманию лучше ознакомиться с интерактивным туром по Git

      DVCS Git и TortoiseGit в картинках. Пособие для начинающих чайников.

      Что такое git? git — это распределенная система управления версиями.

      Не так давно проект «Google API в Delphi» успешно переехал на новый адрес и теперь находится под управлением распределенной системы контроля версий Git

      Небольшое введение. О чем вообще пойдет речь

      Git — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux.

      То обстоятельство, что система создавалась «под Linux» уже как бы намекает на то, что без консоли нам не обойтись. Но не стоит махать руками и кричать «консоль отстой, git — в печь» и все такое. Поверьте — консоль Linux и консоль Windows имеют для обычного пользователя только одно общее свойство — чёрный экран при первом запуске. Команды Linux (ИМХО) просты и запоминаются без проблем, а работать с консолью не составляет особого труда даже для такого чайника, как я.

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

      Это обстоятельство и поставило меня в начале работы с Git в тупик.
      Как это так commit и не в центральный репозиторий?
      Как правильно отправлять данные на сервер?
      Как вообще начинать работу?

      Эти и ещё многие другие вопросы посещали меня на старте работы с Git. Сейчас я не буду углубляться далеко в теоретические вопросы Git, да и вообще любых систем контроля версия — всего этого полно в Сети. А затрону один практический момент — как начать работу вообще, чтобы потом не было мучительно больно за бесцельно потерянные исходники.

      Качаем и устанавливаем софт

      Для работы с Git под Windows имеются вполне работоспособные и юзабельные решения, например, msysgit. Однако если Вы ранее имели опыт работы с SVN и использовали в работе TortoiseSVN, то видимо, Вам захочется иметь аналог подобного интерфейса и для Git? Нет проблем вот аналог TortoiseSVN для Git — TortoiseGit.
      По сути TortoiseGit после нажатия команды из контекстного меню запускает консольную команду из MSysGit и рисует в окошко ее вывод. Если вы не хотите или просто не хватает времени детально разобраться в консольных командах Git, то TortoiseGit — то, что Вам нужно.
      Итак, если Вы работаете под 32-х битной Windows, то Вам необходимо скачать следующий софт:

      1. msysgit — качаем Git-1.7.1-previewXXXXXXXX.exe (11,6 Mb) Git For Windows
      2. TortoiseGit. На момент написания статьи последней была версия TortoiseGit-1.5.2.0-32bit.msi (19.6 MB). Новые версии Вы можете найти также по приведенной ссылке.

      Получается, что скачать нам надо чуть больше 30 Mb.
      Теперь устанавливаем скачанные программы.

      При установке msysgit настройки по умолчанию можно не изменять.
      При установке TortoiseGit выбираем в окне «Choose SSH Client» второе значение:

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

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

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

      1. Регистрация на GitHub’e.

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

      Профиль на GitHub.com

      2. Генерируем ключ для доступа по SSH.
      Вот тут хочешь-не хочешь, а надо запускать консоль. После установки msysgit у Вас на рабочем столе появился новый ярлык — Git Bush — вот с помощью него и запускаем консоль.

        Набираем в консоли следующую команду

      ssh-keygen -t rsa -C «E-Mail из Вашего профиля»

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

      Заходим в директорию, открываем с помощью «Блокнота» файл ida_rsa.pub и копируем все его содержимое в буфер обмена.

      3. Заносим публичный ключ доступа в профиль.

      Для записи публичного ключа в профиль:

      1. Заходим в свой профиль github и жмем ссылку Account Settings (сверху)
      2. Выбираем пункт «SSH Public Keys»
      3. Жмем ссылку «Add another public key»

      Перед вами появится форма добавления нового публичного ключа. Вставляем из буфере весь скопированный ранее текст (из файла >только в поле key — поле Title оставляем пустым .

      На этом работа с публичными ключами закончена.

      4. Просимся в проект.

      Для этого достаточно найти наш проект на github и отправить одному из администраторов запрос на предоставление доступа к репозиторию. Или просто отправить мне email с логином на github. После того как вы будите записаны в список разработчиков проекта можно переходить к следующей фазе работы — получение исходников.

      Работа со своим первым репозиорием Git

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

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

      1. Вызываем контекстное меню и выбираем пункт «TortoiseGit — Settings«:

      В появившемся окне переходим сразу к пункту «Git — Config» и записываем свое имя и адрес электронной почты. Эти данные должны в точности совпадать с теми, что записаны в Вашем аккаунте на github, иначе ваш ключ просто не подойдет.

      2. Клонируем репозиторий. Для этого заходим на страницу проекта, и копируем в буфер адрес:

      Теперь жмем правой кнопкой мыши на директории, в которой будем хранить исходники и в меню выбираем «Git Clone..«:

      В открывшемся окне в поле URL вставляем скопированный адрес и жмем «Ok»:

      Начнется процесс клонирования репозитория.

      Всё вышесказанное можно было бы заменить всего двумя командами в консоли:

      После клонирования репозитория Вы автоматически переключитесь на нашу главную ветку (master). Так как каждый из нас занят определенной работой в проекте, то у каждого своя ветвь в репозитории, поэтому и Вам придется создавать свой branch. Делается это достаточно просто.

      3. Создаем свою ветку. Для этого жмем правую кнопку мыши на директории в которую мы клонировали репозиторий и выбираем в меню «TortoiseGit — Create Branch«:

      В открывшемся оке задаем название новой ветки и указываем на основании какой ветки репозитория мы будем создавать новую. Жмем «Ок», подтверждая создание ветки. Теперь переключаемся на свой новый branch.

      Выбираем в меню «TortoiseGit — Switch/Checkout…«:

      В открывшемся окне выбираем нашу новую ветку и жмем «Ок». Убеждаемся, что мы успешно переключились:

      По сути, все что касалось создания нового branch’a в консоли решилось бы всего одной командой:

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

      5. Вносим изменения в репозиторий. После того как внесены какие-то изменения нам необходимо их закрепить в Git. И здесь опять же проявляется отличие этой системы контроля версий от того же SVN. Дело в том, что Commit в Git не сбрасывается сразу на сервер. Для того, чтобы внести изменения в удаленный репозиторий используется команда PUSH . В общем виде работа может быть построена следующим образом:

      1. Вносятся изменения в проект

      2. Изменения закрепляются в вашем локальном репозитории, используя команду Commit в меню или, используя консоль:

      3. Когда Вам необходимо/удобно/требуется закрепить все изменения на сервере выполняем push в свою ветку (brunch). Команда консоли выглядит так:

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

      Для этого выбираем новый файл, вызываем меню и выбираем «Add…»:

      По рисунку можно видеть, что я вношу в индекс новый файл text.txt. Жмем «Ok».

      После того как файл добавлен, можно сразу же сделать Commit — кнопка Commit появится в окне с выводом консоли. Жмем её и откроется окно для внесения Commit’a:

      Заполняем поле с описанием, жмем «Ок» и коммит готов. Если хотите сразу отправить эти изменения в репозиторий, то в окне с выводом консоли появится также кнопка PUSH. Если же Вас не устраивает таскать по 1 файлику туда-сюда или изменения столь незначительны, что их нет смысла отправлять на сервер, то просто продолжаете дальше кодить, а push выполним позднее.

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

      1. Зажимаем Shift и вызываем контекстное меню. В меню должны появится дополнительные команды:

      Выбираем команду Push. Перед Вами откроется окно следующего содержания:

      Все, что от Вас требуется на данном этапе — нажать на кнопку (на рисунке она выделена красным) найти в списке удаленную ветку в которую вы делаете push и два раза нажать Ok. Все изменения, произведенные Вами в локальном репозитории отправятся в Сеть.

      Git для начинающих

      Чему вы научитесь

      1. Работать с git из командной строки
      2. Настраивать git и алиасы к нему
      3. Создавать ветки и переключатся между ними
      4. Заливать свой код на гитхаб
      5. Работать с git с правильным workflow
      6. Использовать gitflow для оптимизации работы
      7. Мерджить конфликты

      Необходимые знания

      1. Базовое владение консолью

      Для кого этот курс

      1. Для всех, кто не умеет пользоваться системами контроля версий
      2. Для тех, кто хочет научиться работать с git из консоли
      Мастер Йода рекомендует:  10 команд для Docker, без которых вам не обойтись
  • Добавить комментарий