Git bash что это – Разница в использовании git cmd и git bash под windows

Еще записи по теме

rgblog.ru

Установка git в Windows (на этот раз подробно)

Установка и настройка

Итак, установка git. Сразу оговорюсь что мы будем ставить msysgit, и заодно произведём необходимые действия для подключения к GitHub. Конечно, можно использовать git и в одиночку, для себя — но здесь, как и с играми, в онлайне намного интереснее 🙂

Идём на страницу git, в раздел Download и ищем там msysgit для Windows. Сайт git отправляет нас на Google Code. Берём Full Installer for official Git.

Запускаем, устанавливаем. При установке будет предложено выбрать тип запуска Git:

• Git bash only: git ставится и вызывается командой контекстного меню «Git bash here»/»Git gui here»
• Run from the Windows command prompt: Устанавливает Git и прописывает путь к консольной версии в PATH. Команду ‘Git Bash here’ всё равно можно использовать.
• Run Git and tools from Windows Command Prompt: то же что предыдущий вариант, но дополнительно прописывает в Windows путь к различным Unix-утилитам типа find и sort. Git предупреждает нас что при этом вместо windows-приложений с соответствующими именами будут вызываться unix-аналоги

Я предпочитаю второй вариант, т.к. использую git исключительно из командной строки. Так что это руководство будет по большей части консольным 🙂

Продолжаем установку. В конце git предложит просмотреть файл примечаний к релизу. Собственно, на этом установка заканчивается 🙂 Теперь идём в командную строку (если Вы выбрали этот вариант) и вводим свои данные в git, чтобы он нормально подписывал коммиты.

git config --global user.name "Ваше имя"
$ git config --global user.email "ваш[email protected]"

Не забудьте подставить своё имя/ник и email 🙂 Параметр —global говорит нам что мы изменяем глобальные настройки. Чтобы изменить настройки только одного репозитория, перейдите в его папку и сделайте то же без —global:

cd my_repo
git config user.name "Ваш ник"
$ git config user.email "другой[email protected]"

Кстати, создаётся репозиторий командой git init в нужной папке. Всё, git можно пользоваться в локальном режиме 🙂

Давайте теперь что нибудь утянем с Github. Идём туда, делаем поиск или Explore Github, открываем понравившийся проект. Прямо под названием проекта будет Clone URL:

Жмём, копируем команду. Получится примерно что то такое:

git clone git://github.com/quickredfox/jquery-builds.git

Переходим в каталог куда мы хотим положить проект, и выполняем команду. Имейте в виду, git создаст для проекта каталог чтобы его туда положить. То есть, если мы выполним эту команду в D:\Source, проект будет в папке D:\Source\jquery-builds.

Конфигурация для использования GitHub

Чтобы хранить свой проект в GitHub, надо ещё немного покопаться с настройкой 🙂 Нам понадобится пара ключей SSH. Открываем консоль Git bash, всё равно где. В msysgit процесс генерации пары ключей упрощён почти до предела. Делаем:

ssh-keygen -t rsa -C "ваш[email protected]"

У Вас спросят куда положить ключи (не потеряйте их, лучше выбрать предлагаемое программой место), дважды спросят пароль (passphrase). Пароль должен быть сложным. После этого Вы получите два файла и RSA fingerprint примерно такого вида:

e8:ae:60:8f:38:c2:98:1d:6d:84:60:8c:9e:dd:47:81 [email protected]

Теперь идём и регистрируемся на Гитхабе, в бесплатном варианте.

Внимание, бесплатный аккаунт на GitHub — аккаунт для Open-Source проектов. Вы не сможете закрыть свой код, или скрыть его от других. Не используйте его для проприетарного кода и рабочих проектов!

В поле SSH Public Key вставляем содержимое файла id_rsa.pub, или как Вы его там назвали при создании ключей. Если Вы создали ключи в своей папке пользователя, ssh самостоятельно его найдёт. Иначе, надо будет добавить ключи вручную:

ssh-add <путь к файлу ключей>

Завершаем регистрацию. Теперь можно уже проверить что получилось. В простой командной строке подключаемся к серверам github:

ssh github.com

В ответ должно прийти:

Hi username! You’ve successfully authenticated, but GitHub does not provide shell access.

Это значит что всё в порядке.

Если Вы видите No supported authentication methods available, значит Git не может найти программу, способную достучаться до сервера Гитхаба. Строка вызова используемой программы хранится в переменной GIT_SSH. Чтобы использовать программу ssh (самый простой способ), надо сделать в командной строке:

set GIT_SSH=ssh

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

Ссылки по теме

Понравилось это:

Нравится Загрузка…

Похожее

kuroikaze85.wordpress.com

Моя шпаргалка по работе с Git

Некоторое время назад я открыл для себя 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 ключей, если не создавали ее ранее:

ssh-keygen
cat ~/.ssh/id_rsa.pub

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

cd ~/projects/haskell
git clone [email protected]:afiskon/hs-textgen.git
cd hs-textgen

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

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

git add TODO.TXT
git commit -a

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

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

git branch new_feature
git checkout new_feature

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

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

git commit -a # делаем коммит всех изменений в new_feature
git checkout master # переключаемся на master
git merge new_feature # мержим ветку new_feature

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

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

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

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

Следует отметить, что мне лично TortoiseGit показался каким-то глючноватым и вообще не слишком удобным. Возможно, это всего лишь дело привычки, но мне кажется намного удобнее работать с Git из консоли, чем с помощью контекстного меню в Проводнике. Так что по возможности я бы советовал работать с Git в Юниксах. В крайнем случае можно поставить виртуальную машину, установить под ней FreeBSD (безо всяких GUI) и работать в этой виртуальной машине.

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

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

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

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

git config —bool core.bare true

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

Refusing to update checked out branch: refs/heads/master
By default, updating the current branch in a non-bare repository
is denied, because it will make the index and work tree inconsistent
with what you pushed, and will require ‘git reset —hard’ to match
the work tree to HEAD.

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

git clone [email protected]:afiskon/hs-textgen.git

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

git remote add remotename [email protected]:repo.git

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

Удалить файл:

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

Сделать коммит:

git commit -a -m «Commit description»

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

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

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

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

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

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

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

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

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

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

git checkout -b some_branch origin/some_branch

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

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

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

git branch # звездочкой отмечена текущая ветвь

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

git branch -a # | grep something

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

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

git branch -d some_branch

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

git branch -D some_branch

История изменений:

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

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

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

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

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

git show d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4

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

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

git push origin :branch-name

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

git reset —hard d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4

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

git reset —soft d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4

Попытаться обратить заданный commit (но чаще используется branch/reset + merge):

git revert d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4

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

git diff # подробности см в «git diff —help»

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

git config —global merge.tool vimdiff

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

git config —global mergetool.prompt false

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

git config —global core.pager ‘less -x4’

Создание глобального файла .gitignore:

git config —global core.excludesfile ~/.gitignore_global

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

Создание тэга:

git tag some_tag # за тэгом можно указать хэш коммита

Удаление untracked files:

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

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

mkdir -p /tmp/git-copy
cd /tmp/git-copy
git clone —bare [email protected]:afiskon/cpp-opengl-tutorial1.git
cd cpp-opengl-tutorial1.git
git push —mirror [email protected]:afiskon/cpp-opengl-tutorial2.git

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

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

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

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

Добавить сабмодуль:

git submodule add https://github.com/glfw/glfw glfw

Инициализация сабмодулей:

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

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

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

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

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

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

Дополнение: Практика работы с системами контроля версий

Метки: Разработка.

eax.me

Git для начинающих. Часть 2. Установка Git

Для того, чтобы начать работать с системой контроля версий Git ее необходимо предварительно установить. Рассмотрим варианты установки этой VCS под MS Windows и Linux.

Установка Git под Windows

Для установки Git под Windows необходимо предварительно скачать дистрибутив. Для этого перейдите на страницу https://git-scm.com/

Если вы зашли из под операционной системы (ОС) Windows, главная страница сайта будет выглядеть примерно так, как показано на рисунке ниже. Для других ОС отличие будет заключаться в том, что изменится область для скачивания дистрибутива (см. правый нижний угол).

Для того чтобы скачать Git нужно нажать на кнопку Downloads for Windows, расположенную в правой части окна.

Процесс дальнейшей установки Git выглядит так.

1. Запустить установочный файл

2. Ознакомиться, если есть желание, с лицензионным соглашением и нажать на кнопку Next

3. Выбрать компоненты, которые следует установить

4. Указать способ использования Git

В этом окне доступны три возможных варианта:

• Use Git from Git Bash only

Переменная PATH не модифицируется и работа с Git возможна только через специализированную оболочку, которая называется Git Bash.

• Use Git from the Windows Command Prompt

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

• Use Git and optional Unix tools from the Windows Command Prompt

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

Наша рекомендация: опция Use Git from the Windows Command Prompt.

5. Настройка правил окончания строки

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

• Checkout Windows-style, commit Unix-style line endings

Checkout (операция извлечения документа из хранилища и создания рабочей копии) производится в Windows стиле, а commit (операция отправки изменений в репозиторий) в Unix стиле.

• Checkout as-is, commit Unix-style line endigns

Checkout производится в том формате, в котором данные хранятся в репозитории, а commit осуществляется в Unix стиле.

• Checkout as-is, commit as-is

Checkout и commit производятся без дополительных преобразований.

Наша рекомендация: опция Checkout Windows-style, commit Unix-style line endings.

6. Выбор эмулятора терминала, который будет использован с Git Bash

Возможен выбор из двух вариантов:

• Use MinTTY (the defaul terminal of MSYS2)

Git Bash будет использовать в качестве эмулятора терминала MinTTY.

• Use Windows’ default console window

Git будет использовать Windows консоль (“cmd.exe”).

Наша рекомендация: опция Use MinTTY (the defaul terminal of MSYS2).

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

Доступны следующие параметры:

• Enable file system caching

Включение операции кэширования при работе с файлами. Эта опция позволит значительно повысить производительность.

• Enable Git Credential Manager

Предоставляет возможность работы с защищенным хранилищем.

Активирует работу с символьными ссылками.

Наша рекомендация: опции Enable file system caching и Enable Git Credential Manager.

8. Завершение установки

После нажатия на кнопку Install будет произведена установка Git на Windows, по окончании установки пользователь получит соответствующее сообщение.

Установка Git под Linux

Для установки Git под Linux, также необходимо зайти на сайт  https://git-scm.com/ и перейти в раздел Downloads. В зависимости от используемой вами версии операционной системы Linux необходимо выбрать тот или иной способ установки Git.

Debian/Ubuntu

> apt-get install git

Fedora
(Fedora 21)

> yum install git

(Fedora 22)

> dnf install git

Gentoo

> emerge --ask --verbose dev-vcs/git

Arch Linux

> pacman -S git

openSUSE

> zypper install git

Mageia

> urpmi git

FreeBSD

> pkg install git

Solaris 9/10/11 (OpenCSW)

> pkgutil -i git

Solaris 11 Express

> pkg install developer/versioning/git

OpenBSD

> pkg_add git

Alpine

> apk add git

Рекомендуем классный курс по git от GeekBrains, перейдите по ссылке и найдите в разделе “Курсы” курс “Git. Быстрый старт”. Это бесплатный видеокурс, зарегистрируйтесь и начинайте получать новые знания.

<<< Git для начинающих. Часть 1. Что такое системы контроля версий?

Git для начинающих. Часть 3. Настройка Git>>>

devpractice.ru

Git — Book

2nd Edition (2014)

Download Ebook

The entire Pro Git book, written by Scott Chacon and Ben Straub and published by Apress, is available here. All content is licensed under the Creative Commons Attribution Non Commercial Share Alike 3.0 license. Print versions of the book are available on Amazon.com.>

1. 1. 1.1 О системе контроля версий
   2. 1.2 Краткая история Git
   3. 1.3 Основы Git
   4. 1.4 Командная строка
   5. 1.5 Установка Git
   6. 1.6 Первоначальная настройка Git
   7. 1.7 Как получить помощь?
   8. 1.8 Заключение
2. 1. 2.1 Создание Git-репозитория
   2. 2.2 Запись изменений в репозиторий
   3. 2.3 Просмотр истории коммитов
   4. 2.4 Операции отмены
   5. 2.5 Работа с удалёнными репозиториями
   6. 2.6 Работа с метками
   7. 2.7 Псевдонимы в Git
   8. 2.8 Заключение
3. 1. 3.1 О ветвлении в двух словах
   2. 3.2 Основы ветвления и слияния

git-scm.com

что такое? Git для начинающих: описание

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

Описание

Git является распределенной системой для управления версиями разрабатываемых файлов. Создана она была в 2005 году автором ОС Linux. Эта система осуществляет синхронизацию работы с сайтом, а также сохраняет и обновляет изменения в файлах. Это очень удобный подход в случае работы над проектом нескольких разработчиков. На сегодняшний день во многих известных проектах используется именно Git. Что такое использование дает? К примеру, разработкой операционной системы Android занимается большое число программистов. Было бы крайне неудобно, если бы один из них вносил изменения, а другие об этом не знали. Git же позволяет всем быть в курсе всех изменений, а в случае ошибок вернуться к предыдущим версиям файлов.

Использование слепков, а не патчей

Главным отличием Git от других систем контроля версий является то, как она смотрит на данные. Большая часть программ хранит информацию в виде списка изменений, называемых патчами для файлов. Такие системы к хранимым данным относятся как к набору файлов, а также набору изменений, которые сделаны для каждого файла, относительно времени. Как хранит свои данные Git? Что такое есть в этой системе, что отличает ее от других? Вместо патчей, хранимые данные здесь считаются набором слепков маленькой файловой системы. Всякий раз, когда пользователь фиксирует новую версию проекта, система просто сохраняет слепок состояния файлов на текущий момент. Чтобы повысить эффективность в том случае, когда файл не изменялся, система не сохраняет его, а делает ссылку на ранее сохраненный экземпляр, в который были внесены последние изменения.

Это очень важное отличие от других систем контроля, которое присуще Git. Что такое отличие дает? Git становится похожей на маленькую файловую систему, обладающую очень мощными инструментами, которые работают поверх нее.

Преимущественно локальные операции

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

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

Наблюдение за целостностью данных

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

Данные чаще всего добавляются

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

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

Работа с Git для начинающих подразумевает запоминание того, что файл может находиться в одном из трех состояний:

• Зафиксированное, то есть файл сохранен в локальном хранилище.
• Измененное, когда правки были внесены, но сохранение еще не выполнено.
• Подготовленное – измененные файлы, которые отмечены для сохранения.

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

• Каталог Git, где хранятся метаданные, а также база данных объектов. Эта часть системы самая важная.
• Рабочий каталог, который является извлеченной из базы данных копией какой-то версии проекта.
• Файл, содержащий информацию о последующем сохранении.

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

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

• Установка Git из исходников.
• Установка пакета для используемой платформы.

Установка Git из исходников

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

Для установки понадобятся необходимые библиотеки: expat, curl, libiconv, openssl, zlib. После их инсталляции можно загрузить последнюю версию системы контроля версий, скомпилировать ее и установить.

Установка в операционной системе Windows

Если у пользователя нет Linux, а хочется использовать Git, Windows также поддерживает эту систему. И установить ее очень просто. Существует проект msysGit, процедура установки которого является одной из самых простых. Необходимо просто загрузить файл инсталлятора, который можно найти на странице проекта в GitHub, а затем запустить его. По окончании установки на компьютере будет две версии — графическая и консольная.

Первоначальная настройка Git

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

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

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

Пользовательское имя

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

Если указать опцию –global, такие настройки нужно будет сделать один раз.

Выбор текстового редактора

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

Проверка параметров

Чтобы знать основы Git, необходимо уметь проверять используемые настройки. Для этого применяется команда git config –list. Она выводит все доступные параметры, которые сможет найти. Некоторые имена настроек могут присутствовать в списке несколько раз. Это происходит из-за того, что Git считывает один ключ из различных файлов. В такой ситуации для каждого ключа используется последнее значение. Есть возможность проверять значения определенных ключей, вписав в команду вместо «—list» — «{ключ}».

Как создать репозиторий

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

Создание в данном каталоге

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

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

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

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

Удалить из системы любой файл можно, если исключить его из индекса, то есть из отслеживаемых файлов. Для этого нужна команда git rm. Она также убирает файл из рабочего каталога пользователя. Затем нужно выполнить коммит. После него файл попросту исчезнет и отслеживаться больше не будет. Если же он изменен и уже проиндексирован, то применяют принудительное удаление с параметром -f. Такой способ предотвратит удаление тех данных, которые еще не записались в снимок состояния и которые нет возможности восстановить из системы.

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

В любой момент может появиться необходимость в отмене какого-либо действия. Если пользователь выполнил коммит рано, забыв внести некоторые файлы, то можно перевыполнить его, используя опцию —amend. Такая команда использует для коммита индекса. Если после выполнения последнего сохранения не производилось никаких изменений, то проект будет в таком же состоянии, и появится редактор для комментариев, где пользователь сможет отредактировать все, что нужно. Нужно помнить, что не каждую операцию отмены можно будет отменить. Иногда можно безвозвратно удалить необходимые данные. Следует быть внимательными.

Итоги

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

fb.ru

Подключение Git Bash к GitHub.com с использованием SSH — sergey vasin

Эта статья подразумевает, что у вас уже есть учетная запись на github.com, вы скачали и установили Git Bash с сайта git-scm.com и теперь хотите работать со своими репозиториями, используя SSH.

Собственно о том, как настроить этот самый SSH и пойдет речь в этой статье.

Но сначала о том, что особенного в этом методе подключения.

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

Использование SSH избавляет вас от необходимости использовать имя и пароль, так как вместо этого используется пара ключей — открытый и закрытый (public and private), однако в целях безопасности закрытый ключ должен быть зашифрован при помощи пароля.

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

Запустим Git Bash и введем команду

ls -al ~/.ssh

Этой командой мы получаем список файлов из папки .ssh, находящейся в профиле текущего пользователя — ~. Если вы там обнаружите что-то вроде id_rsa и id_rsa.pub, то, возможно, ключ у вас уже есть, и если вместо генерации новых вы решите использовать существующий, то можете сразу переходить к шагу добавления ключей к ssh-агенту. Мы же тут сделаем вид, что никаких ключей у нас нет и приступим к их генерации.

Генерируем ключи

Для генерации новой пары ключей в консоли git bash введите следующую команду:

ssh-keygen -t rsa -b 4096 -C "[email protected]"

В этой команде параметр -t задает тип, в данном случае мы используем rsa. Параметр -b задает длину ключа, 4096 выглядит вполне подходящим значением. Параметр -C задает комментарий к генерируемым ключам, в котором мы указываем свой email адрес.

Git bash сообщит что происходит генерация ключа, а после попросит указать место сохранения файлов с ключами. Мы можем либо нажать Enter и согласиться с местоположением и именем по умолчанию: ~/.ssh/id_rsa и ~/.ssh/id_rsa.pub, либо указать свой вариант.

Добавляем ключи к ssh-агенту

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

Тут есть интересная вещь, если у вас установлен Git Desktop, то вы можете управлять репозиториями через него и не обращать внимания на то, о чем мы тут говорим. Однако же, управление Git через консоль с помощью какой либо утилиты, вроде Git for Windows, о чем мы здесь и рассуждаем, является более предпочтительным методом, поэтому стоит обратить внимание на вопросы запуска ssh-агента. Далее в статье мы рассмотрим, как настроить его автоматический запуск, сейчас же мы запустим его вручную, командой:

eval $(ssh-agent -s)

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

$ ssh-add ~/.ssh/id_rsa

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

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

Добавление ключа к вашей учетной записи на GitHub.com

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

Для этого сначала получим значение открытого ключа при помощи следующей команды:

clip < ~/.ssh/id_rsa.pub

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

Далее заходим на сайт GitHub.com под своей учетной записью и, щелкнув на своем аватаре, выбираем Settings. В меню, расположенном в левой части, выбираем SSH and GPG keys и нажимаем New SSH key. Заполняем поле Title, для того, чтобы нам самим было понятнее, что это за ключ, вставляем содержимое файла открытого ключа из буфера в поле Key и нажимаем Add SSH key.

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

Теперь давайте проверим ssh-соединение. Для этого в консоли Git Bash введем команду:

ssh -T [email protected]

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

После ввода пароля вы можете получить что-то вроде:

The authenticity of host 'github.com (192.30.252.1)' can't be established.
RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
Are you sure you want to continue connecting (yes/no)?

или:

The authenticity of host 'github.com (192.30.252.1)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no)?

В этом случае проверьте, что и вы и Git Bash имеете в виду один и тот же ключ, сверив выведенное значение отпечатка (fingerprint) с тем, что было получено при генерации ключей. Ели все в порядке, отвечайте на вопрос утвердительно.

В итоге вы должны получить сообщение:

Hi username! You've successfully authenticated, but GitHub does not
provide shell access.

где вместо username должно присутсвовать имя вашей учетной записи.

Изменение пароля шифрования закрытого ключа

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

ssh-keygen -p

Автоматический запуск ssh-агента при старте Git Bash

Для того, чтобы ssh-агент каждый раз запускался автоматически при старте Git Bash, добавьте в файл ~/.profile или ~/.bashrc следующий код:

env=~/.ssh/agent.env

agent_load_env () { test -f "$env" && . "$env" >| /dev/null ; }

agent_start () {
    (umask 077; ssh-agent >| "$env")
    . "$env" >| /dev/null ; }

agent_load_env

# agent_run_state: 0=agent running w/ key; 1=agent w/o key; 2= agent not running
agent_run_state=$(ssh-add -l >| /dev/null 2>&1; echo $?)

if [ ! "$SSH_AUTH_SOCK" ] || [ $agent_run_state = 2 ]; then
    agent_start
    ssh-add
elif [ "$SSH_AUTH_SOCK" ] && [ $agent_run_state = 1 ]; then
    ssh-add
fi

unset env

Теперь при запуске Git Bash также будет запускаться и ssh-агент. Если при генерации ключей (или позже) мы задали пароль для шифрования закрытого ключа, при запуске, ssh-агент будет проявлять интерес к его значению. Поянтно, что после закрытия Git Bash, его содержимое будет забыто и закрытый ключ будет в безопасности.

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

ssh-add -t 300

Страницы в социальных сетях:

Twitter: https://twitter.com/vsseth
Facebook: https://fb.com/inpowershell
VKontakte: https://vk.com/inpowershell

sergeyvasin.net