Основы Git - 1

Внизу документа прикреплены презентации по Git из замечательной книги Pro Git

В данной инструкции описывается работа с Git в Bash shell. Это такая терминальная среда или просто говоря командная строка. Все описанные ниже команды работают как в Linux, так и в Shell для Windows.

Сперва нужно установить Git, если он еще не установлен на вашем ПК. В Linux для этого открываем терминал и выполняем (знак $ копировать не надо - это просто обозначение команд терминала) :

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

Рассмотрим оба этих способа. В дальнейшем не рекомендуется использовать программу TortoiseGit. Если вы ее уже установили, то просто удалите ее.

Устанавливается Git для Windows из проекта http://git-scm.com/download/win. При установке оставляем все параметры по умолчанию. Единственное, необходимо проследить, чтобы при установке была включена опция "Git Bash here". Это даст возможность запускать Git bash из Проводника прямо в необходимой вам папке. Иначе придется осуществлять навигацию через сам Git bash, что может быть неудобно неопытным пользователям компьютера.

Теперь, чтобы приступить к работе с Git, необходимо в Проводнике Windows кликнуть правой кнопкой мыши по папке с вашим проектом, который вы хотите добавить в версионный контроль, и выбрать опцию Git bash here:

Другим вариантом получить Git является Git for Windows Portable. Он скачивается по той же ссылке, что и обычный Git. В этом случае устанавливать ничего не надо. Достаточно распаковать архив в удобную для вас директорию (желательно ближе к корню диска и чтобы весь путь к папке имел только латинские символы), а затем запустить в этой директории файл git-bash.exe

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

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

Далее работаем в открывшемся терминале Git bash. После установки Git-у надо сообщить свое имя и email, поскольку без этой информации вы не сможете делать коммитов, т.к. каждый коммит (версия вашего проекта в определенный момент времени) должен содержать в себе автора этого коммита. Делается это также в терминале следующим образом:

Здесь стоит сказать несколько слов о способах навигации и базовых принципах работы с консолью в Git bash. Для перемещения между папками используется стандартная команда cd. Ее аргументом является либо папка, куда мы хотим переместиться, либо специальные символы. Путь к папке указывается относительным или абсолютным путем. Наиболее часто используются следующие два символа:

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

Обратите внимание, что для навигации используются обычные прямые слэши /, а не обратные \ как в Windows.

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

Кстати, в Git bash есть удобный автокомплит. Если вы начали вводить команду или адрес в консоль и нажимаете клавишу tab. то консоль подставляет наиболее подходящую недостающую часть команды или адреса. Чтобы вставить в консоль скопированный текст, можно просто нажать в консоли средней кнопкой мыши. Чтобы выбрать какую-то старую команду, то можно сделать это клавишей up. Чтобы просмотреть всю историю команд в консоли используется команда history .

Думаю неплохо было бы объяснить понятия домашней и корневой директорий. Для пользователей Windows это довольно сложно к восприятию. Домашняя директория это папка пользователя, которая создается ОС и к ней имеет полный доступ только сам пользователь. В Windows по умолчанию это папка C:\Users\NameOfUser. Разумеется NameOfUser должно заменяться именем вашего пользователя. Собственно говоря, обычно (но не всегда) Git bash именно C:\Users\NameOfUser определяет как домашнюю директорию. Здесь все просто. Корневая директория представляет папку в которую устанавливается ОС Linux. Обозначается она одинарным слэшом /. В Git bash это просто папка, куда установлен сам Git bash.

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

Если необходимо создать директорию, то используется команда mkdir :

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

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

Теперь мы можем непосредственно приступить к версионному контролю вашего проекта. Сначала заходим в папку с проектом и выполняем команду инициализации пустого репозитория (если еще не создавали):

Кроме того, вы можете не инициализировать репозиторий, а склонировать готовый (адрес которого указан в настройках вашего проекта) и уже туда скопировать файлы вашего проекта:

Адрес репозитория по умолчанию вы можете найти на главной странице вашего проекта на сайте в секции "Main Git Repository":

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

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

Теперь вы можете сохранить новую версию вашего кода в Git или, если сказать по другому - закоммитить:

Атрибут -m означает, что мы пишем комментарий к коммиту в теле самой команды. Разумеется, комментарии от коммита к коммиту должны изменяться. Если запустить git commit без -m. то запуститься текстовый редактор vim, где вам необходимо будет написать этот комментарий. Так что не отвертишься. Кстати, рекомендуется писать комментарии к коммиту как можно более подробно, чтобы потом при чтении истории проекта не возникало вопросов, что же вы делали в субботу вечером.

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

Или в более удобном виде:

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

commit - первые 4 (или более) символа контрольной суммы SHA-1, увидеть можно с помощью команды $git log. Постарайтесь ничего не изменять в проекте после переключения на более старый код, т.к. здесь требуется комбинация довольно хитрых шагов, без выполнения которых вы рискуете поломать репозиторий. Используйте такое переключение только для того, чтобы ознакомиться со старым кодом. Чтобы переключиться обратно на последний коммит, достаточно указать той же команде текущую ветку разработки:

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

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

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

Теперь изменения из iss53 попали в master .

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

picture411-1.png (10,214 КБ) Александр Дмитриев, 17.12.2014 22:28

gitbashhere.png (7,16 КБ) Дмитриев Александр, 20.11.2015 01:58

terminal.png (8,71 КБ) Дмитриев Александр, 20.11.2015 02:08

Git 1.ppt (731 КБ) Дмитриев Александр, 15.09.2016 20:41

Git ветвления.ppt (1,036 МБ) Дмитриев Александр, 15.09.2016 20:41

Git ветвления2.ppt (1,461 МБ) Дмитриев Александр, 15.09.2016 20:41

Разница в использовании git cmd и git bash под windows - Stack Overflow на русском

Установил Git for Windows с сайта https://git-scm.com/
После установки есть возможность запускать две консоли - git cmd и git bash .
Я так понимаю, что git cmd - командная строка windows, а git bash - командная строка linux. Первые шаги при использовании не выявили существенных отличий в работе обоих. Заметил лишь, что в git bash есть удобное и достаточно приятное выделение цветом, а также подсказки для команд при двойном нажатии Tab. Наверняка есть более глобальные отличия между git cmd и git bash. которые заставят любителя cmd запускать bash. Вопрос: какие? Ибо тогда зачем в сборку для windows добавлять альтернативу cmd?

задан 13 апр в 14:28

из того, что я знаю - это использование glob (cmd вряд ли поймет git add **/*.cpp ). Также в bash доступные многие удобные утилиты, которых нет в cmd. И конечно же, многие мануалы по настройке гита будут легко настраиваться с баш консоли, но не cmd (придется правильно угадывать пути и тому подобное). – KoVadim 13 апр в 14:40

Не бывает git cmd или git bash. Есть только сервисные утилиты, а точнее одна сервисная утилита с разными именами: git-cmd.exe и git-bash.exe .

Оба эти exe-шника делают

1. Инициализация переменных окружения (PATH, и пр.)
2. Запуск терминала.

Разница между ними только одна - по умолчанию git-bash.exe запускает терминал mintty с bash внутри. git-cmd.exe запускает стандартный терминал Windows с cmd.exe. Более того, git-cmd.exe имеет ключик --command=. с помощью которого можно запустить bash вместо cmd при желании.

git.exe это самостоятельная программа рядом с которой лежат все необходимые утилиты из пакета msys (например ls. vim. sed. и прочая), а недостающие утилиты можно "доставить" с помощью pacman. Предполагаемая проблема с "путями" не имеет оснований - все команды выполняет сам гит. git add **/*.cpp будет обрабатываться самим гитом.

• Из командной строки cmd.exe несколько меняется синтаксис, т.к. ^ это управляющий символ cmd.exe. Например, вместо git.exe rebase -i 2385397^1 нужно писать git.exe rebase -i 2385397^^1 .
• Маски файлов, вроде вышеописанного git add *.cpp не "разворачиваются" в список файлов, то есть аргументы передаются без изменений и git самостоятельно выполняет поиск подходящих файлов. В итоге мы имеем ошибочное поведение когда git add *.cpp добавляет файлы из подкаталогов.
• В консоли cmd.exe (если только она не в ConEmu запущена) нельзя использовать 256 цветов в Vim.

Вот наверное и всё.

называется "не разобрался, но критикую". Говоря о путях, я имел ввиду то, что в большинстве инструкций для гита они указываются в юникс стиле, и bash.exe (с окружением) их прекрасно поймет. А вот cmd - нет. С глобами не все тоже так прозрачно. Обычно баш сам раскрывает их, но в большинстве случаев гит сам раскрывает пути точно также. И это очень прозрачно. – KoVadim 14 апр в 7:19

Работаем с Git, основные команды для начинающих

Кто вносил изменения в код можно определить по имени пользователя git. Для этого сообщим git свое имя и email-адрес. Для этого введите:

Превратим наш проект в репозиторий git. Для начала просто создайте папку git_site. затем введите следующие команды:

Где mkdir - команда для создания новых каталогов;
cd - переход в указанную папку; команда cd используется для смены текущего каталога.
cd. на уровень выше
cd \ в корень текущего диска
d: перейти на диск D
cd c:\windows перейти в каталог windows

После инициализации каталога будет выведено соответствующее сообщение:

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

Далее в наш каталог ( git_site ) можно поместить файлы сайта. Скопируем файлы сайта в папку git_site. Далее, давайте добавим файлы в репозиторий.

Для этого понадобится выполнить команду:

Команда $ git status позволяет отследить состояние репозитория. Эта команда позволяет узнать, какие изменения необходимо зарегистрировать git (при необходимости, отменить).

Чтобы зарегистрировать добавление вышеприведенных файлов необходимо выполнить следующую команду:

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

Подтверждение с описанием выполненных действий.

Мы сделали "снимок кода". Теперь мы можем редактировать файлы и регистрировать наши изменения.

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

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

На изображении у нас одно незарегистрированное изменение. В самом файле эти изменения не будут отображены.

Восстановить же изменения поможет следующая команда:

Чтобы объединить ветки. например, ветку hotfix с веткой master. необходимо выполнить следующие команды:

Давайте удалим ветку hotfix. Для этого воспользуемся следующей командой:

Ветка позволяет отделить работу, например, над каким-то компонентом от основного кода сайта.

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

Этим мы к тому же переключились на новую ветку hotfix. Теперь все внесенные в файлы изменения будут относиться к ветке hotfix .

Теперь давайте внесем изменения в файл index.html. Например, давайте подключим стилевой файл. И в самом стилевом файле увеличим размер шрифта у параграфа. Сделаем git status и зарегистрируем изменения:

Теперь, если мы переключимся на ветку master. мы не найдем там изменения, внесенные на ветке hotfix. Таким образом, git меняет содержимое файлов при изменении ветки.

Чтобы проинициализировать Git репозиторий введите команду:

Будет создана папка /.git/. Репозиторий - это скрытая папка, в которой работает Git.

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

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

Сейчас git отслеживает наш файл test.txt. Давайте выполним

снова, чтобы понять, что изменилось!

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

git commit -m "Add cute octocat story"

Если вы опустите метку -m из командной строки, git перенесет вас в редактор по вашему выбору. В первой строке введите комментарий: «Added h1 tag». Сохраните файл и выйдите из редактора (для этого в редакторе по-умолчанию (Vim) вам нужно нажать клавишу ESC. ввести :wq и нажать Enter ). Вы увидите. (http://githowto.com/ru/commiting_changes )

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

Коммитится только то, что проиндексировано. Индексирование происходит функцией add (она и добавляет файлы и индексирует их).

Коммит идет не сразу: файлы, которые находятся под присмотром ГИТ необходимо проиндексировать (то есть если нам нужно сделать коммит для 1-файла, то мы помещаем его в индекс и закоммитится только он). С помощью ключа –a мы индексируем ВСЕ файлы и, соответственно, сразу выполняем коммит (например,

git commit --amend

Эта команда берет область индексирования (add) и включает в коммит всю обнаруженную там информаци. Например,

Второй коммит заменит результат первого и в итоге останется 1 коммит

Зарегистрируйтесь на GitHub. Создайте репозиторий.

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

Эта команда принимает имя удаленного репозитория и его URL. В нашем случае это https://github.com/try-git/try_git.git

Выполняем команду с указанными аргументами:

git remote add origin https://github.com/try-git/try_git.git

Где origin - имя удаленного репозитория.

На bitbucket.org можно создавать неограниченное количество приватных репозиториев (плата взимается, если к репо привязываются более 5 пользователей). На GitHub большинство проектов open source, также для приватного репо уже приходится платить – даже для 1-го пользователя. Для своих проектов я рекомендую все же использовать bitbucket.org.

Переходим на боевой сервере по SSH и стягиваем (PULL) с GitHub, при этом разработка идет на ПК разработчика (может быть более 1-го разработчика, с локального ПК делаем PUSH на GitHub).

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

Ключ –v показывает путь к удаленному репо.

Подробно о любой команде можно узнать:

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

То по команде git push произойдет следующее: если на боевом репо есть 2 ветки, которые соответствуют 2-м локальным веткам, то на удаленный репо протолкнутся эти 2 ветки.

В данном случае протолкнется лишь текущая ветка.

Команда git remote позволяет просмотреть удаленные репозитории

git remote -v параметр -v позволяет увидеть URL-адреса.

Добавление удаленных репозиториев под короким именем:

git remote add [сокращенное имя] [url]

git remote add kuku [url] - теперь вместо полного URL-адреса в командную строку можно вводить имя kuku

В уже сущест. реп. добавляем реп. сторонний и стягиваем из него ветку master

Иниц. пустой реп.
Добавляем реп.
извлекаем все данные (.git)
и стягиваем ветку master из реп. kuku

Команда git remote show [имя удал. реп.] позволяет просмотреть дополнительную информацию о конкретном удал. реп.

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

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

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

Команда git push говорит Git, куда отправить наши изменения, когда все готово. Итак, запушим наши локальные изменения в наш удаленный репозиторий на GitHub. Имя удаленного репозитория origin. а ветка по умолчанию называется master (не думайте пока что о ветках). Параметр -u позволит нам в будущем не указывать дополнительные параметры, а просто выполнять git push. Git будет знать, что нужно делать.

git push -u origin master

где origin – это куда отправляем (удаленный репозитарий ), а
master это то, что отправляем (в нашем случае master ).

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

git pull origin master

Забираем изменения из ветки ( master ) на удаленном сервере ( origin ) и проводим слияние с активной веткой.

Команда git diff показывает не все изменения, сделанные с момента последней фиксации состояния, а только те, которые еще не проиндексированы.

Команда git dif --cached покажет проиндексированные изменения

Ой! Похоже, кто-то еще вносил изменения в наш проект! Давайте посмотрим, что изменилось, с нашего последнего коммита, с помощью команды

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

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

Вы можете удалять файлы из промежуточной области с помощью git reset .

git reset octofamily/octodog.txt

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

покажет список последних коммитов и их хеши SHA1.

На самом верху мы видим самый последний коммит. Функция log очень богатая – позволяет смотреть, что было до и что было после, у git хорошая помощь (faq), чтобы просмотреть все возможности log можно воспользоваться командой:

Например, мы можем выводить историю в более удобном формате :

%h – короткий код самого коммита;
%an – автор;
%ar – когда был сделан;
%s - комментарий.

Ограничиваем коммиты по времени :

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

--stat используется для получения краткой статистики по каждому коммиту.

--graph добавляет графику с историей ветвлений и слияний

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

git checkout -- <name_file>

git checkout -- octocat.txt

git checkout 82f5

Для указания коммита достаточно первых нескольких символов его хеша ( 82f5 ), но можете скопировать и весь хеш.

Для получения собственной копии [имя_ветки] (из уд. реп.) можно воспользоваться командой :

(?) или просто git checkout [имя_ветки] ; но тут главное, чтобы [имя_ветки] присутствовала в уд. реп.

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

Давайте создадим новую ветку и назовем ее clean_up :

git branch clean_up

Вы можете использовать команда git branch -d <branch name> для удаления ветки. Сделаем это:

git branch -d clean_up

Команда git branch -vv позволяет получить список всех веток, за которыми идет наблюдение (за какой веткой следит на уд. сервере и на сколько опережает соотв. ветку на уд. сервере).

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

Команды git rm. которая не только удалит файлы с диска, но и добавит сведения об их удалении в Git.

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

Настал момент, когда вы должны смержить изменения из ветки clean_up в ветку master.

Мы уже находимся в ветке master (вы уже знаете, как в этом убедиться). Осталось только сказать Git, что мы хотим смержить в текущую ветку другую - clean_up.

git merge clean_up

$ git clone <git url>

По url создаем локальный репозиторий, склонировав удаленный, например, с gitHub. Предварительно необходимо выполнить команду git init.

$ mkdir epicgame & cd epicgame
$ git init
$ git remote add <upstream name> <git url>
$ git clone <git url>

Если при push появляется rejected. то это говорит о том, что необходимо скачать изменения с удаленного сервере и уже затем push -ть.

Сообщение о конфликте:

В статусе ( git st ) появляется блок:

То есть у нас появились файлы, которые автоматически не с merg -сь.

То есть в самом файле:

Это указатель на тот commit, с которым мы сейчас работаем. Нужно выбрать или оставить свои изменения ( // Fry comment ) или оставить строку пользователя Bender ( // Bender comment ).

(config – работаем с конфигом; --global – ключ для глобального конфига; user.name - имя).

(задаем email глобально)

(данные о гите и о пользователе; хранятся в c:\users\name_user\.gitconfig )

На одном уровне с папкой .git создаем текстовый документ. gitignore (убираем разрешение .txt, то есть сохраняем с All types(.) в Notepad++).

В самом файле указываем игнорирование, например:

Файл name_file.txt станет обратно ( untracked ; от track - следить), то есть вернется в состояние перед командой git add.

Без ключа –m откроется редактор vim ( :x – означает сохранить и выйти).

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

Изменения можно проверить в C:\Users\name_user\.gitconfig

Создаем ветку new_f и тут же переходим в нее.

С использованием –v показывает ветки с последними коммитами.

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

Далее в случае наличия CONFLICT прописываем (этим мы запускаем утилиту):

Но для GIT kdiff3 необходимо предварительно скачать (http://kdiff3.sourceforge.net/).

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

Или прописать в .gitconfig :

Далее можно merge-ть (решать конфликты):

Далее придется удалить куче неотслеживаемых файло (БЭКАПОВ) командой (http://stackoverflow.com/questions/61212/how-do-i-remove-local-untracked-files-from-my-current-git-branch):

Полезные статьи (источник):