Как работает гитхаб кратко

Обновлено: 30.06.2024

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

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

Git — это набор консольных утилит, которые отслеживают и фиксируют изменения в файлах (чаще всего речь идет об исходном коде программ, но вы можете использовать его для любых файлов на ваш вкус). С его помощью вы можете откатиться на более старую версию вашего проекта, сравнивать, анализировать, сливать изменения и многое другое. Этот процесс называется контролем версий. Существуют различные системы для контроля версий. Вы, возможно, о них слышали: SVN, Mercurial, Perforce, CVS, Bitkeeper и другие.

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

Установить git на свою машину очень просто:

Linux — нужно просто открыть терминал и установить приложение при помощи пакетного менеджера вашего дистрибутива. Для Ubuntu команда будет выглядеть следующим образом:
Windows — мы рекомендуем git for windows, так как он содержит и клиент с графическим интерфейсом, и эмулятор bash.
OS X — проще всего воспользоваться homebrew. После его установки запустите в терминале:

Если вы новичок, клиент с графическим интерфейсом(например GitHub Desktop и Sourcetree) будет полезен, но, тем не менее, знать команды очень важно.

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

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

Как мы отметили ранее, git хранит свои файлы и историю прямо в папке проекта. Чтобы создать новый репозиторий, нам нужно открыть терминал, зайти в папку нашего проекта и выполнить команду init. Это включит приложение в этой конкретной папке и создаст скрытую директорию .git, где будет храниться история репозитория и настройки.
Создайте на рабочем столе папку под названием git_exercise. Для этого в окне терминала введите:

Командная строка должна вернуть что-то вроде:

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

status — это еще одна важнейшая команда, которая показывает информацию о текущем состоянии репозитория: актуальна ли информация на нём, нет ли чего-то нового, что поменялось, и так далее. Запуск git status на нашем свежесозданном репозитории должен выдать:

В git есть концепция области подготовленных файлов. Можно представить ее как холст, на который наносят изменения, которые нужны в коммите. Сперва он пустой, но затем мы добавляем на него файлы (или части файлов, или даже одиночные строчки) командой add и, наконец, коммитим все нужное в репозиторий (создаем слепок нужного нам состояния) командой commit.
В нашем случае у нас только один файл, так что добавим его:

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

Проверим статус снова, на этот раз мы должны получить другой ответ:

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

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

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

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

Сейчас самое время переслать наш локальный коммит на сервер. Этот процесс происходит каждый раз, когда мы хотим обновить данные в удаленном репозитории.
Команда, предназначенная для этого - push. Она принимает два параметра: имя удаленного репозитория (мы назвали наш origin) и ветку, в которую необходимо внести изменения (master — это ветка по умолчанию для всех репозиториев).

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

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

Сейчас другие пользователи GitHub могут просматривать ваш репозиторий. Они могут скачать из него данные и получить полностью работоспособную копию вашего проекта при помощи команды clone.

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

4. Запрос изменений с сервера

Если вы сделали изменения в вашем удаленном репозитории, другие пользователи могут скачать изменения при помощи команды pull.

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

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

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

1. Создание новой ветки

Основная ветка в каждом репозитории называется master. Чтобы создать еще одну ветку, используем команду branch

Это создаст новую ветку, пока что точную копию ветки master.

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

Сейчас, если мы запустим branch, мы увидим две доступные опции:

master — это активная ветка, она помечена звездочкой. Но мы хотим работать с нашей “новой потрясающей фичей”, так что нам понадобится переключиться на другую ветку. Для этого воспользуемся командой checkout, она принимает один параметр — имя ветки, на которую необходимо переключиться.

3. Слияние веток

Наша “потрясающая новая фича” будет еще одним текстовым файлом под названием feature.txt. Мы создадим его, добавим и закоммитим:

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

Теперь, если мы откроем наш проект в файловом менеджере, мы не увидим файла feature.txt, потому что мы переключились обратно на ветку master, в которой такого файла не существует. Чтобы он появился, нужно воспользоваться merge для объединения веток (применения изменений из ветки amazing_new_feature к основной версии проекта).

Теперь ветка master актуальна. Ветка amazing_new_feature больше не нужна, и ее можно удалить.

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

1. Отслеживание изменений, сделанных в коммитах

У каждого коммита есть свой уникальный идентификатор в виде строки цифр и букв. Чтобы просмотреть список всех коммитов и их идентификаторов, можно использовать команду log:
[spoiler title='Вывод git log']

[/spoiler]
Как вы можете заметить, идентификаторы довольно длинные, но для работы с ними не обязательно копировать их целиком — первых нескольких символов будет вполне достаточно. Чтобы посмотреть, что нового появилось в коммите, мы можем воспользоваться командой show [commit]
[spoiler title='Вывод git show']

[/spoiler]
Чтобы увидеть разницу между двумя коммитами, используется команда diff (с указанием промежутка между коммитами):
[spoiler title='Вывод git diff']

[/spoiler]
Мы сравнили первый коммит с последним, чтобы увидеть все изменения, которые были когда-либо сделаны. Обычно проще использовать git difftool, так как эта команда запускает графический клиент, в котором наглядно сопоставляет все изменения.

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

Гит позволяет вернуть выбранный файл к состоянию на момент определенного коммита. Это делается уже знакомой нам командой checkout, которую мы ранее использовали для переключения между ветками. Но она также может быть использована для переключения между коммитами (это довольно распространенная ситуация для Гита - использование одной команды для различных, на первый взгляд, слабо связанных задач).
В следующем примере мы возьмем файл hello.txt и откатим все изменения, совершенные над ним к первому коммиту. Чтобы сделать это, мы подставим в команду идентификатор нужного коммита, а также путь до файла:

3. Исправление коммита

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

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

4. Разрешение конфликтов при слиянии

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

Тим предпочитает forEach:

Система не смогла разрешить конфликт автоматически, значит, это придется сделать разработчикам. Приложение отметило строки, содержащие конфликт:
[spoiler title='Вывод']

[/spoiler]
Над разделителем ======= мы видим последний (HEAD) коммит, а под ним - конфликтующий. Таким образом, мы можем увидеть, чем они отличаются и решать, какая версия лучше. Или вовсе написать новую. В этой ситуации мы так и поступим, перепишем все, удалив разделители, и дадим git понять, что закончили.

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

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

5. Настройка .gitignore

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

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

Вот хорошие примеры файлов, которые нужно игнорировать:

Логи
Артефакты систем сборки
Папки node_modules в проектах node.js
Папки, созданные IDE, например, Netbeans или IntelliJ
Разнообразные заметки разработчика.

Файл .gitignore, исключающий все перечисленное выше, будет выглядеть так:

Символ слэша в конце некоторых линий означает директорию (и тот факт, что мы рекурсивно игнорируем все ее содержимое). Звездочка, как обычно, означает шаблон.

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

Создание аккаунта в Github

Пароль вводится на выбор пользователя, но с учетом правил. Так, рекомендуется комбинация размером в 15 символов или 8, но с использованием хотя бы одной цифры и строчной буквы. Имя пользователя, как и email, проверяется на занятость, и придется выбирать тот, с которым платформа позволит продолжать регистрацию.

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

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

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

Изменение файлов и коммиты

Создание запросов слияния (Pull Request) в Github

Отчеты об ошибках

Заключение

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

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

Кроме того, для начинающих разработчиков GitHub — это не только хостинг, но и способ собрать портфолио. Он позволяет продемонстрировать свои навыки и знания в виде реализованных проектов — во вкладке Repositories.

Из чего состоит проект в GitHub

Ветка main (или master). Это, как правило, основная ветка, в которой лежит самая актуальная, рабочая версия проекта.

Указатель HEAD позволяет гибко откатиться до нужной версии. HEAD на скриншоте ниже выглядит так: a8160621b3c61a07b6bbc75b41e5530ee997124b.

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

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

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

Ветки позволяют просматривать изменения. А чтобы сделать их слияние, понадобится функция pull request (pr).

После этого мы можем сделать pull request в любую ветку, то есть заявку на слияние веток. GitHub сам подсветит изменённые строки, что очень удобно для ревью кода. Красным подсвечиваются удалённые строки, зелёным — добавленные.

Ревью кода

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

После того как ревью проведено, все спорные моменты решены, ошибки поправлены и есть подтверждения от других разработчиков (approve), происходит слияние веток (merge). Все коммиты из ветки branch-1 попадают в main, а в истории коммитов появляется отметка о слиянии.

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

Из чего состоит проект в GitHub

Ветка main (или master). Это, как правило, основная ветка, в которой лежит самая актуальная, рабочая версия проекта.

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

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

Ветки позволяют просматривать изменения. А чтобы сделать их слияние, понадобится функция pull request (pr).

Ревью кода

Краткое введение в Git (3 сценария использования)

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

Git - это свободно распространяемая программа и существует для множества операционных систем. Следующий раздел документа посвящен установке и настройке программы в ОС Windows.

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

и выбираем дистрибутив для своеё операционной системы или идем по ссылке в нижнем правом углу страницы.

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

Git - программа, распространяющаяся по лицензии GPL, допускающая свободное копирование и распространение:

В окне опций соглагшаемся с предложением по-умолчанию:

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

Инсталлятор установит специальную unix-подобную оболочку для ввода команд, под названием Git Bash:

На этом этапе установки вновь соглашаемся с инсталлятором:

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

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

Теперь в проводнике Windows на диске C: создадим папку с будущим репозиторием (хранилищем) проектов. На самом деле эту папку можно размещать в любом месте файловой системы, но мы упрощаем себе задачу. Внимание! Не рекомендуется хранить репозитории в папках с пробелами или кириллическими символами в названии.

Если войти в проводнике в соданную папку (C:\Labs), вызвать контекстное меню и выбрать пункт Git Bash Here, то откроется окно оболочки с приглашением.

В окно теперь можно вводить команды для работы с Git.

Настройка пользователя и почты

Во время одного из этапов первоначальных действий с Git придётся настроить имя пользователя и адрес почты:

Первый сценарий. Разработка собственного проекта

В каталоге c:\labs мы создадим свой учебный проект Hello, World! и пройдем через все этапы работы в Git.

Создадим папку Hello в каталоге c:\labs и перейдем туда в оболочке:

Создадим новый (пустой) репозиторий:

Создание нового репозитория предполагает появление в каталоге Hello скрытой папки с именем .git , в которой будут храниться все служебные файлы хранилища. В оболочке появляется надпись master, которая означает появление главной (и пока единственной) ветки репозитория.

Далее, создадим файл-исходник hello.c с текстом программы на языке C для нашего проекта:

Файл можно создать в любом подходящем текстовом редакторе (notepad), но лучше использовать специальные редакторы для программистов (notepad++).

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

Добавим этот файл (а точнее: изменения в этом файле) к git:

Команда проверки статуса покажет имя добавленного файла зеленым цветом.

Теперь зафиксируем изменения:

У нас появился первый коммит - элемент истории разработки. В дальнейшем на него можно ссылаться по семи первым символам хеш-кода (49a55a4).

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

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

Рассмотрим теперь более подробно рабочий процесс.

Когда мы меняем (или создаем) файлы, то они размещаются в рабочем каталоге (working directory). Команда git add добавляет сделанные изменения в область подготовки (staging area). При вызове
git commit происходит фиксация изменений в репозитории. В истории разработки появляется точка, на которую можно ссылаться, к которой можно совершать откат и т.п.

Первый сценарий. Работа с сервером

Активирование аккаунта происходит после подтверждающего письма по электронной почте.

Далее, мы выбираем вкладку Repositories и нажимаем зеленую кнопку New:

После этого необходимо заполнить ряд полей.

Нужно ввести имя создаваемого репозитория (лучше, если оно будет совпадать с локальным именем). Тип репозитория надо оставить public для свободно распространяемых проектов и private для закрытых от внешнего мира.

Нажатие зеленой кнопки Create переносит к финальному шагу:

На последнем шаге нам предлагают связать локальный и удаленный репозитории командой git remote. Мы должны набрать в командной оболочке

и передать первый раз изменения на сервер:

Слово origin в данном случае означает псевдоним серверного репозитория, а master имя ветки. По сути мы связали локальную и удаленную ветки master и отправили изменения на сервер.

Как в дальнейшем отправлять обновления на сервер?

Как только на локальной машине накапливается достаточно изменений (новых коммитов), осуществляется их передача на удаленный сервер командой

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

Сценарий второй. Подключение еще одного локального компьютера для разработки

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

Любой пользователь Github может выполнить клонирование существующего public репозитория к себе на локальный компьютер.

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

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

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

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

Клонирование репозитория осуществляется командой

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

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

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

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

Таким образом, сценарий №2 позволяет скачивать с сервера программное обеспечение (в том числе чужое) и периодически обновлять его.

Третий сценарий. "Социальное" программирование

Сценарий №3 является наиболее сложным из рассматриваемых, но и наиболее популярным и интересным. В лабораторных работах мы будем использовать именно его.

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

Последовательность действий при данном сценарии:

Владелец гостевого аккаунта (пользователь) выполняет операцию под названием Fork

В результате серверный репозиторий копируется в аккаунт пользователя.

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

В код на локальном компьютере вносятся изменения, которые потом отправляются в серверный репозиторий пользователя командой git push .

Для того, чтобы владелец серверного репозитория мог вытянуть и применить изменения в своем проекте, прользователь направляет ему Pull request (пул-запрос).

Владелец оригинального репозитория проверяет направленный ему код и применяет его к своему репозиторию (или отклоняет).

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

Это достигается использованием механизма веток.

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

Читайте также: