Git для начинающих основы рабочего процесса и базовые команды


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

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

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

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

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

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

Нам понадобиться программа Git Bash, это шелл сделанный на основе Cygwin, поэтому возможно использование Unix-команд, вроде ls, cd, mkdir. Скачать его можно по следующей ссылке http://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

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

# Настройка

Флаг -global добавленный к командам выше позволит сохранить эти настройки для всех проектов:

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

Для того, чтобы использовать VS CODE как difftool запустите команду:

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

# Справка по команде

git help [command-name]

Если вы используете VS Code, как редактор по умолчанию, то установите расширение open in browser, чтобы открывать документацию в браузере.

# Инициализация проекта

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

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

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

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

# Commit

Создает коммит с комментарием после ключа -m . Предварительно должны быть указанны с помощью git add файлы.

Если не указать файлы командой git add , то команда git commit не создаст коммит. Эти два действия можно объединить, указав ключ -a . Данный ключ показывает, что нужно создать коммит всех измененных файлов, учитывая удаленные, но при этом новые файлы (которых еще нет в индексе) учитываться не будут.

# Pull и Push

Рассмотрим команды pull и push на практическом примере. Создадим на гитхабе новый тестовый проект. Поставьте галочку чтобы создать readme файл:

Затем создадим директорию, инициализируем в ней Git, и выполним команды remote add и pull :

Таким образом мы создали директорию и инициализировали в ней локальный репозиторий. С помощью команды remote add origin при привязали локальный репозиторий к удаленному. А с помощью команды git pull origin master были скопированы файлы (в данном случае файл readme) с удаленного репозитория на локальный из ветки origin master .

Теперь откроем файл README.md из локальной директории, добавим туда что-нибудь и выполним следующие команды:

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

  • git push — добавляет данные на удаленный сервер с локального компьютера
  • git pull — забирает данные на локальный компьютер с удаленного сервера

# Clone

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

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

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

# Branch

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

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

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

Перейти в ветвь:

Создать ветвь и сразу же в неё перейти:

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

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

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

Это удалит ветвь из локального репозитория. Для удаления ветви из удаленного репозитория выполните команду:

# Просмотр старых версий проекта

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

Посмотрите лог и скопируйте id интересующего коммита:

Затем выполните команду checkout для данного коммита, например:

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

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

Обратите внимание, что когда вы находитесь в предыдущей версии коммита с помощью команды checkout , то команда git log покажет лог только до текущего коммита, в котором вы находитесь. Чтобы увидеть все коммиты воспользуйтесь командой git reflog .

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

# Status

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

# Stash

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

Просмотреть стек спрятанных данных можно с помощью команды git stash list . Дополнительные данные покажет команда git stash show .

Строка вида stash@ , отображаемая при выполнении команды git stash list — это номер сохраненных изменений в стеке, по которому можно эти данные восстановить или удалить.

Для восстановления данных есть команда git stash apply , если запустить её без параметров, будет восстановлена рабочая область последнего в стеке сохранения. Чтобы восстановить конкретный номер в стеке укажите его: git stash apply stash@ <0>или с помощью сокращенного варианта git stash apply 0 .

Команда git stash pop применяет спрятанные изменения и удаляет их из стека.

Команда git stash drop [stash-name] удаляет указанную заначку, или последнюю, если номер явно не указан.

# Дополнительно

Для получения подробной информации по командам смотрите их описание на официальном сайте.

Git для начинающих: основы рабочего процесса и базовые команды

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

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

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

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

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

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

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

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

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

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

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

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

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

HTTPie — удобный инструмент похожий на cURL

cURL — это самый известный инструмент для отправки HTTP запросов из командной строки. В этом уроке мы познакомим вас с более удобным аналогом, который называется HTTPie.

Основные GIT Команды

Введение

Когда дело доходит до систем контроля версий, очень немногие могут затмить GIT в актуальности, производительности и распространенности. GIT был разработан Линусом Торвальдсом в 2005 году, и сегодня, миллионы компаний используют его для эффективного управления кодом и контроля над версиями своих проектов. Программное обеспечение с открытым исходным кодом может быть загружено для различных платформ, таких как Linux, Windows, Solaris и Mac; больше информации об основах GIT можно получить здесь. В этом руководстве вы узнаете основные GIT команды.

Что вам понадобится

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

  • GIT установленный на вашей системе

Основные GIT команды

  • git config

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

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

Команда git add может быть использована для добавления файлов в индекс. К примеру, следующая команда добавит файл под названием temp.txt присутствующий в локальном каталоге в индекс:

Команда git clone используется для клонирования репозитория. Если репозиторий находится на удаленном сервере, используется команда такого рода:

И наоборот, для клонирования локального репозитория используйте:

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

Команда git status отображает список измененных файлов, вместе с файлами, которые еще не были добавлены в индекс или ожидают коммита. Применение:

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

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

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

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

Эта команда позволит пользователю подключить локальный репозиторий к удаленному серверу:

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

Для удаления ветки:

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

Команда git merge используется для объединения ветки в активную ветвь. Применение:

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

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

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

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

Запуск команды git log отобразит список всех коммитов в ветке вместе с соответствующими сведениями. Пример результата:

Команда git reset используется для сброса индекса и рабочего каталога до последнего состояния коммита. Применение:

git rm используется для удаления файлов из индекса и рабочего каталога. Применение:

Возможно одна из самых малоизвестных команд git. Она помогает в сохранении изменений на временной основе, эти изменения не попадут в коммит сразу. Применение:

Для просмотра информации о любом git объекте используйте команду git show. Для примера:

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

Команда git ls-tree используется для просмотра дерева объекта вместе с названием, режимом каждого предмета и значением SHA-1. К примеру:

Используйте команду git cat-file, чтобы просмотреть тип объекта с помощью SHA-1 значения. Например:

git grep позволяет пользователю проводить поиск фраз и слов в содержимом деревьев. К примеру, для поиска www.hostinger.ru во всех файлах используйте эту команду:

gitk – это графический интерфейс локального репозитория. Вызвать его можно выполнив данную команду:

С помощью команды git instaweb можно запустить веб-сервер, связанный с локальным репозиторием. Браузер также автоматически будет перенаправляться на него. Например:

Для оптимизации репозитория используйте команду git gc. Она поможет удалить и оптимизировать ненужные файлы:

Команда git archive позволяет пользователю создать .zip или .tar файл содержащий компоненты одного из деревьев репозитория. Например:

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

Чтобы выполнить проверку целостности файловой системы git, используйте команду git fsck, при этом будут идентифицированы все поврежденные объекты:

Команда git rebase используется для применения коммитов в другой ветке. Например:

Заключение

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

Основные Git команды: шпаргалка

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

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

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

Системы контроля версий: немного теории

Если вкратце — любая система контроля версий позволяет сохранять все внесённые в файл проекта изменения. Это дает возможность осуществлять контроль за ошибками в коде и быстрое их устранение.

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

  • локальные;
  • централизованные;
  • распределенные.

Виды систем контроля версий


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

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

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

Git: описание и особенности системы

Система контроля версий Git обладает своими особенностями. Большинство систем хранит файлы, изменяя их в соответствии с инструкциями в проекте. То есть, к примеру, версия текущей разработки под номером 3 может содержать данные об изменениях в файле А и Б. А уже версия 4 будет иметь в себе А, Б и В. Таким образом, файлы меняются по необходимости.

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

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

Для сохранения целостности данных применяется метод хеширования каждого изменённого файла методом SHA-1. Это позволяет системе контроля версий точно знать, где, кто и когда изменил файл.

Git: установка

Для того чтобы начать работать с Git, нужно его установить. Система контроля версий доступна для использования в Windows, Mac OS, Linux.

Версию для Windows можно скачать по адресу: git-for-windows.github.io. После загрузки программу нужно установить. Инсталлятор простой, так что эта процедура не должна вызвать проблем.

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

Первые команды

После установки системы контроля версий на компьютер, ее необходимо настроить. Стоит отметить, что к этому моменту на сайте Github должен быть зарегистрирован свой аккаунт. Для того чтобы выполнить первоначальную настройку, нужно вызвать консольный клиент, так как придётся вводить команды. Сделать это можно, нажав правую кнопку мыши и выбрав пункт Git Bash. Должно открыться окно консольного клиента, которое пригласит ввести данные. В нем нужно выполнить последовательно Git Bash команды:

  • git config —global user.name »Имя»;
  • git config —global user.mail »Адрес электронной почты».

На этом же этапе необходимо настроить метод окончания строк с помощью двух команд:

  • git config —global core.autocrlf true;
  • git config —global core.safecrlf false.

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

Основные команды Git

  • Init: данная команда создаёт новый репозиторий.

Пример использования: init имя проекта.

  • Clone. Производит копирование существующего репозитория с удалённого источника.

Вот так используется команда git clone: clone git://github.com/путь к репозиторию.

  • Add. Наиболее часто используемая команда в системе контроля версий Git. Она выполняет простую задачу — добавляет указанные файлы в особую область, именуемую индексом или сценой. В неё можно перенести несколько файлов или папок, которые необходимо будет впоследствии добавить в репозиторий или, выражаясь на языке Git, «закоммитить».

Пример использования этой Git команды выглядит так: add некий_файл.txt.

  • Status. Позволяет просмотреть список файлов, которые присутствуют в индексе и рабочей папке. Служит для контроля и просмотра готовых к коммиту данных или их изменённых, но не внесённых версий в сцену.
  • Diff. Показывает разницу состояний. Например, с помощью этой Git команды можно определить, есть ли изменения между папкой с проектом и индексом.
  • Commit. Выполняет сохранение слепка всего того, что находилось в индексе непосредственно в базу данных. В результате работы Git команды на экране отобразится текстовый файл, в котором можно указать, какие именно изменения были произведены. А также будет выведена информация о том, сколько файлов подверглись коммиту, и его контрольная сумма. Главное — не забывать о том, что после изменения в базу попадут только те данные, которые были занесены в индекс командой git add.

Дополнительные команды Git

  • Reset. О функциях этой команды говорит ее название. Она просто выбрасывает из специальной промежуточной области — индекса, указанный файл, помещённый туда по случайности. Стоит осторожно обращаться с reset при использовании команды с ключом — — hard, так как это затронет и файлы в рабочей папке, что может привести к непредвиденным последствиям.
  • Rm. Наиболее точно эту команду можно описать как обратную git add, так как она удаляет файлы из индекса. Правда, при этом ещё и из рабочей папки.

Пример использования: git rm некий_файл.txt.

  • Mv. Служит для перемещения файла.
  • Clean. Предназначена для очистки папки проекта от ненужных файлов.

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

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

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

  • Branch. У этой команды имеется в наличии несколько ключей, используя которые можно гибко управлять ветками в проекте. Branch представляет собой некий многопрофильный инструмент для полноценного контроля за состоянием репозитория. Простой вызов git branch выдаст перечень всех имеющихся веток хранилища. Ключ -v добавленный к команде отобразит какие коммиты были зафиксированы за последнее время. А использование -d приведёт к удалению указанной ветки. Branch умеет не только удалять, но и создавать. Выполнение git branch имя_ветки приведёт к организации новой ветки в проекте. Стоит учесть, что при этом указатель текущего рабочего положения бывает иным. К примеру, создав имя_ветки, можно на самом деле находится в ветке master.
  • Чтобы переместиться в нужный пункт, существует команда Git checkout нужная_ветка, которая переставит указатель в необходимую ветку.
  • Checkout. Как уже говорилось выше, выполняет переключение.
  • Merge. Данная команда позволяет производить слияние нескольких веток воедино.
  • Log. Функция отображает все изменения от начала проекта и до последнего коммита. Использование разнообразных ключей совместно с вызовом команды позволяет расширить ее функционал. Например, вызов git log -p -2 позволит просмотреть подробную информацию об изменениях в каждом коммите. Второй ключ -2 говорит о том, что нужно показать лишь 2 последних изменения. Аргумент —stat, добавленный к вызову git log, выполнит практически то же самое, что и -р, но в более подробной и при этом компактной форме. Также с помощью git log можно выводить информацию об изменениях, создав собственный формат отображения, используя опции format ключа pretty. Для придания особого вида нужно использовать некое подобие регулярных выражений. Например, такая запись get log —pretty=format »%h, %an, %ar, %s» выведет краткий хэш коммита, затем его автора, дату и комментарий изменения. Это очень удобно использовать при просмотре большого количества коммитов.

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

  • Fetch. При вводе данной команды git консоль выполнит перенос всех изменений с удалённого хранилища в локальное.
  • Pull. Команда git pull представляет собой симбиоз двух перечисленных выше — git fetch и git merge. То есть она сначала получает сведения из удалённого репозитория, а затем выполняет слияние с использующейся в данный момент веткой.
  • Push. Именно от названия этой команды в среде пользователей появилось выражение «запушить», что означает соединение с удаленным репозиторием и передачу туда изменений из локального.

Команды удаленного управления

  • Remote. Представляет собой мощный инструмент для управления удалёнными репозиториями. С помощью remote их можно удалять, просматривать, перемещать или же создавать новые.
  • Archive. Название говорит само за себя. Команда позволяет создавать архив с нужными изменениями, например, для подготовки к передаче его по Сети.

Как использовать данную шпаргалку

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

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

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).

«Мягкий» (с ключом —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 через терминал — это обязательная часть практики каждого современного фронтенд-специалиста. Однако, для начинающих это может показаться сложным. Чтобы упростить процесс обучения, мы собрали для вас все самые необходимые команды, которые пригодятся в работе с Git на первое время.

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

Работа с любой программой всегда начинается с её настройки. Git можно настроить один раз и менять что-то только по мере необходимости.

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

git config —global user.name «User Name»

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

git config —global user.email mail@gmail.com

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

git config —global core.editor editor

С помощью команды git config —list можно посмотреть список всех установленных настроек.

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

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

Работа с изменениями

Любая работа с изменениями начинается с получения последней версии удалённого репозитория. Получить последнюю версию можно с помощью команды git pull . Будьте внимательны, вызов этой команды сотрёт все незафиксированные изменения.

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

Чтобы добавить отслеживание новых файлов, необходимо использовать команду git add для добавления нескольких файлов по имени.

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

Помимо добавления файлов, их также необходимо удалять. Для этого существует команда git rm , которая удаляет файлы по их имени.

После того как добавлены все новые и удалены старые файлы, можно делать фиксацию изменений. Фиксация изменений или коммит, очень важна, так как до выполнения этой команды ваши локальные изменения никуда не запишутся. Чтобы добавить коммит, необходимо ввести команду git commit -m «Комментарий к коммиту» .

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

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

По умолчанию, эта команда удаляет только из индекса. А команда git reset —hard безвозвратно удаляет незафиксированные текущие изменения из локального репозитория и из индекса.

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

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

Работая с Git, приходится постоянно создавать и перемещаться по веткам.

Команда git checkout -b branch-name создаст ветку с указанным именем и автоматически переключится на неё.

После создания ветку можно отправить на сервер с помощью команды git push origin branch-name .

Аналогично можно забрать себе на компьютер ветку с удалённого репозитория командой git checkout origin/branch-name -b branch-name .

Чтобы не хранить названия веток в памяти или не искать названия веток, существуют две специальные команды, которые позволяют посмотреть все существующие ветки локального репозитория git branch или все существующие ветки удалённого репозитория git branch -r .

Переключиться на любую локальную ветку можно с помощью команды git checkout branch-name .

Прочее

После работы в репозитории могут оставаться различные ненужные, неотслеживаемые файлы и прочий мусор. Чтобы удалить всё лишнее, воспользуйтесь командой git clean -f -d .

oleglomako / Git базовые команды

базовые команды
git clone адрес репозитория — клонировать репозиторий на локальный компютер
git commit -m ‘initial commit’ комит изменений в локальный репозиторий
git push -u origin master — только первый раз отправка изменений в удаленный репозиторий
git push — все последующие разы отправка изменений в удаленный репозиторий
окат изменений
git pull — скачивается актуальная версия удаленного репозитория и все изменения применяются к локальному репозиторию
checkout — перейти в другую ветку
discard — не отправлять в репозиторий те изменения которые нам не нравятся
revert — откатить существующие комиты
hard reset -откатить целую пачку комитов
работа с ветками
merge — сначала подтягиваем в свою ветку из master все изменения
merge — потом тестируем и делаем слияние переходим (checkout) в master и применяем (merge) все изменения из нашей ветки
git commit -a -m ‘commit all edited files’ закомитить все измененные файлы безиспользования команды git add
git clone — скачивание репозитория
git status — просмотр текущих изменений
git add — добавить файл в локальный репозиторий
git commit — коммит в локальный репозиторий
git push — коммит в удаленный репозиторий
В консольном git можно указать настройки сетевого подключения. Прокси, порты, аутентификацию.
git config —global http.proxy http://proxyuser:proxypwd@proxy.server.com:8080
(указываем ваши креденшлс, если есть, прокси-сервер и порт)
Работа с ветками
git branch -a посмотреть в какой ветке мы находимся и показать все ветки ключ -а all
git branch newbranch — создать новую ветку с именем newbranch
git checkout newbranch — перейти в новую ветку
git push origin newbranch — (сначала переключиться на мастер) отправить в удаленный репозиторий ветку newbranch
git branch -d newbranch — удалить ветку newbranch из локального репозитория
git push origin —delete newbranch — удалить ветку newbranch в удаленном репозитории
Работа с версиями программы
1. Разработку лучше вести не в ветке master,
а в другой ветке, например, develop, новые функции программы ветвить от develop,
тестить и фиксить в develop, и только когда код отлажен до какой-то стабильной версии программы,
сливать изменения в master.
2. При этом удобно добавить тэг с номером версии и изменениями что допилили в этой версии (release notes).
3. По тэгу легко найти нужную версию в логе,
и можно по этому коммиту (вообще можно по любому коммиту)
воссоздать в отдельной ветке состояние программы в этой версии.
api/get-temperature-value
feature/select2-ibrary-added
fix/incorrect-users-sorting-fixed
т.е. принцип: «чем является доработка» / «что именно доработано».

This comment has been minimized.

Copy link Quote reply

Drovosek01 commented Apr 26, 2020

А как же вывод коммитов: git log.

  • © 2020 GitHub , Inc.
  • Terms
  • Privacy
  • Security
  • Status
  • Help

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

oleglomako / Git базовые команды

базовые команды
git clone адрес репозитория — клонировать репозиторий на локальный компютер
git commit -m ‘initial commit’ комит изменений в локальный репозиторий
git push -u origin master — только первый раз отправка изменений в удаленный репозиторий
git push — все последующие разы отправка изменений в удаленный репозиторий
окат изменений
git pull — скачивается актуальная версия удаленного репозитория и все изменения применяются к локальному репозиторию
checkout — перейти в другую ветку
discard — не отправлять в репозиторий те изменения которые нам не нравятся
revert — откатить существующие комиты
hard reset -откатить целую пачку комитов
работа с ветками
merge — сначала подтягиваем в свою ветку из master все изменения
merge — потом тестируем и делаем слияние переходим (checkout) в master и применяем (merge) все изменения из нашей ветки
git commit -a -m ‘commit all edited files’ закомитить все измененные файлы безиспользования команды git add
git clone — скачивание репозитория
git status — просмотр текущих изменений
git add — добавить файл в локальный репозиторий
git commit — коммит в локальный репозиторий
git push — коммит в удаленный репозиторий
В консольном git можно указать настройки сетевого подключения. Прокси, порты, аутентификацию.
git config —global http.proxy http://proxyuser:proxypwd@proxy.server.com:8080
(указываем ваши креденшлс, если есть, прокси-сервер и порт)
Работа с ветками
git branch -a посмотреть в какой ветке мы находимся и показать все ветки ключ -а all
git branch newbranch — создать новую ветку с именем newbranch
git checkout newbranch — перейти в новую ветку
git push origin newbranch — (сначала переключиться на мастер) отправить в удаленный репозиторий ветку newbranch
git branch -d newbranch — удалить ветку newbranch из локального репозитория
git push origin —delete newbranch — удалить ветку newbranch в удаленном репозитории
Работа с версиями программы
1. Разработку лучше вести не в ветке master,
а в другой ветке, например, develop, новые функции программы ветвить от develop,
тестить и фиксить в develop, и только когда код отлажен до какой-то стабильной версии программы,
сливать изменения в master.
2. При этом удобно добавить тэг с номером версии и изменениями что допилили в этой версии (release notes).
3. По тэгу легко найти нужную версию в логе,
и можно по этому коммиту (вообще можно по любому коммиту)
воссоздать в отдельной ветке состояние программы в этой версии.
api/get-temperature-value
feature/select2-ibrary-added
fix/incorrect-users-sorting-fixed
т.е. принцип: «чем является доработка» / «что именно доработано».

This comment has been minimized.

Copy link Quote reply

Drovosek01 commented Apr 26, 2020

А как же вывод коммитов: git log.

  • © 2020 GitHub , Inc.
  • Terms
  • Privacy
  • Security
  • Status
  • Help

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Введение в GitHub: как начать пользоваться?

Всем привет! Несмотря на такой долгую паузу после последней статьи о VestaCP, буду пробовать переходить на более интенсивный режим работы. С этого дня темы новых статей будут немного сменены, теперь вы увидите больше статей, связанных с вёрсткой сайтов. Я не беру на себя функцию обучить вас вёрстке, а, скорее, предоставляю вам миниконспект основ, к которому будет легко вернуться и повторить. Надеюсь, вам понравится и вы сможете эффективно использовать предложенную информацию. Хватит предисловий, приступим к работе.

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

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

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

Наверное, все когда-нибудь сохраняли 2 версии файла с небольшими отличиями под разными именами? К примеру, научка-вер1.txt и научка-вер1-проверил_Пушкин.txt. Первый файл вы отправили своему научному руководителю, он его проверил, внёс свои изменения и отравил вам второй файл. Такое может повторять вплоть до бесконечности, плодя множество файлов, названия которых ставятся все более и более странными. А ваша папка с версиями с «научкой» становится похожа на что-то дикое и сложное в понимании, и найти промежуточную версию становится очень и очень сложно.

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

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

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

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

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

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

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

Виды современной системы контроля версий

Централизованная.

  1. Существует только один репозиторий.
  2. Простые номера версий файлов (1, 2, 3 и т.д.).
  3. У пользователей хранится только текущая версия проекта.
  4. Требуется подключение к интернету.
  5. Просто, но медленно.
  6. Сложности в одновременной работе над одним файлом.

Распределенная.

На один проект приходится много репозиториев.

  1. Каждый пользователь создает локальную копию всего репозитория на основе главного облачного.
  2. Номера версий сложные.
  3. Возможность работать офлайн.
  4. Работать быстро и удобно.
  5. Требуется синхронизация репозиториев, так как проект — один.

Теперь можно дать определение и слову Git.

Git — это инструмент для реализации работы распределённой системы контроля версий.

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

Как работает GitHub

Для работы с GitHub нам потребуется установить клиент контроля версий (в GitHub, это GitHub Desktop ) и создать репозиторий. Репозиторий можно создать, как через веб-сайт, так и через клиент.

Принципы работы с репозиторием GitHub

  1. С помощью клиента копируем весь репозиторий на свой компьютер (pull).
  2. Вносим различные правки, сохраняем, вносим правки и т.д. в различные файлы репозитория.
  3. Просим клиента внести изменённые файлы в репозиторий.
    Внесение измененных файлов в репозиторий называется фиксацией изменений или «коммитом» (commit).
  4. После коммита версия вашего локального репозитория изменилась.
  5. На данный момент изменения фиксированы только на локальном репозитории, чтобы они отобразились на сайте GitHub, требуется еще одна функция «синхронизация репозиториев» (push).
  6. Теперь ваш главный репозиторий, расположенный в GitHub, такой же, как на вашем компьютере.

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

Слияние, конфликт, разрешение конфликта

Для понимая нужен пример. Влад и Артем сделали копию репозитория (pull) с фалом версии 1 с GitHub, внесли разные изменения в этот файл, оба зафиксировали изменения (commit) → версии фала в локальных репозиториев изменились, у Влада версия 2, у Артем 2А. И затем Влад запушил (синхронизировал репозитории- push). Теперь на GitHub добавилась версия файла 2. Артем тоже решил запушить свои изменения, т. к. на GitHub есть версия которой нет у Артема (у него нет версии 2), система откажется принимать его репозиторий для сохранения версии 2.

Для того, чтобы внести свои изменения, Артему нужно опять скопировать репозиторий (pull) с GitHub с дополнительной версией этого файла. При копировании произойдет конфликт.

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

Способы решения конфликта:

  1. Автоматическое слияние. Сравнивая построчно код Влада и Артема, GitHub может решить совместить куски кода в файле, при этой получится новая версия файла. При таком подходе в репозитории будут находиться версии 1, 2, 2А, и 3, а Артем теперь может запушить все отсутствующие версии файла.
  2. Разрешение конфликта вручную. Git пометит, какой код конфликтует, и вам нужно будет решить, какой вариант оставить или вообще внести третий. Создается версия 3, и Артем может запушить отсутствующие версии файла.

Master / не master, Fork, Pull request

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

Пример модели работы с ветками:

В Master лежит последняя стабильная версия, где вы можете вносить незначительные изменения; development — ветка для непосредственной разработки; dev-adaptive — ветка разработки, связанная с планируемым расширением функционала.

Что такое Fork? К примеру, на GitHub вам понравился какой-то проект, но вы заметили в нем ошибку и знаете, как ее решить, но доступа к редактированию чужого проекта у вас нет. Для этого вам нужно создать fokr. Теперь у вас есть доступ для редактирования файлов проекта. Вы справились с багом, но ваши труду пропадут даром т. к. изменения не отобразится в master ветке проекта. Чтобы такого не произошло и создан Pull request.

Pull request — это обращение к владельцам проекта с предложением внести в главную ветку ваши изменения.

На этом небольшое введение походит к концу. Не мучайтесь с допотопной системой версий, переходите на GitHub. Спасибо за внимание.

Мастер Йода рекомендует:  PHP 5 - установка и конфигурация под наши нужды в режиме mod_php для Apache
Добавить комментарий