Подробное введение в работу с git

Коммиты

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

Команда откроет текстовый редактор для ввода сообщения коммита. Также эта команда принимает несколько распространённых аргументов:

  • позволяет написать сообщение вместе с командой, не открывая редактор. Например ;
  • переносит все отслеживаемые файлы в область подготовленных файлов и включает их в коммит (позволяет пропустить перед коммитом);
  • заменяет последний коммит новым изменённым коммитом, что бывает полезно, если вы неправильно набрали сообщение последнего коммита или забыли включить в него какие-то файлы.

Несколько советов, к которым стоит прислушаться:

  • Коммитьте часто: вы не сможете откатить изменения, если откатывать не к чему.
  • Одно изменение — один коммит: не помещайте все не связанные между собой изменения в один коммит, разделите их, чтобы было проще откатиться.
  • Формат сообщений: заголовок должен быть в повелительном наклонении, меньше 50 символов в длину и должен логически дополнять фразу (this commit will fix bugs — этот коммит исправит баги). Сообщение должно пояснять, почему был сделан коммит, а сам коммит показывает, что изменилось. Здесь подробно расписано, как писать сообщения для коммитов.
  • (Опционально) Не коммитьте незначительные изменения: в большом репозитории множество небольших коммитов могут засорить историю. Хорошим тоном считается делать такие коммиты при разработке, а при добавлении в большой репозиторий объединять их в один коммит.

Продвинутое использование: правим историю

Для большего контроля над историей коммитов локальной ветки можно использовать команду , которая откроет интерактивную консоль для перемещения набора последних n коммитов, перечисленных в порядке от старых к новым (то есть в том порядке, в котором они будут перемещены). Таким образом вы можете «редактировать историю», однако помните, что оригинальные коммиты нельзя изменить, только переместить.

Вы можете поменять порядок коммитов, изменив порядок, в котором они перечислены.

Измененяем сообщение коммита/разбиваем коммиты

Для указания коммита, который вы хотите изменить, используется команда . Затем, когда Git будет проводить перемещение, он остановится на этом коммите. После этого вы можете использовать , чтобы изменить сообщение или подготовить забытые файлы. Если вы хотите разделить коммит, после остановки введите (в результате HEAD будет перемещён на один коммит назад и все изменённые в этом коммите файлы перейдут в статус неподготовленных). Затем вы сможете зафиксировать файлы в отдельных коммитах обычным образом.

После завершения редактирования введите .

Перезапись нескольких коммитов

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

Объединение нескольких коммитов

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

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

Кроме слияния/перемещения всех коммитов в тематической ветке, вас может интересовать только определённый коммит. Допустим, у вас есть локальная ветка drafts, где вы работаете над несколькими потенциальными статьями, но хотите опубликовать только одну из них. Для этого можно использовать команду . Чтобы получить определённые коммиты, из которых мы хотим выбирать, можно использовать .

Обратите внимание, что таким образом создаётся новый коммит, который только повторяет diff выбранного коммита (то есть разницу между этим коммитом и предыдущим), но не его состояние

Как работать с Git

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

С Git можно работать как через командную строку, так и через графический интерфейс вроде GitHub Desktop. Хотя начинающих разработчиков командная строка может отпугнуть, её всё равно лучше изучить, ведь она предоставляет больше возможностей, чем многие инструменты с интерфейсом.

Вебинар «Простая и понятная производственная аналитика с дашбордом Winnum»

25 августа в 11:00 в 11:00, онлайн, беcплатно

tproger.ru

События и курсы на tproger.ru

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

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

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

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

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

Получает изменений из определенного репозитария:

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

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

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

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

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

Совмещение веток

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

Слияние

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

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

После открытия таких файлов вы увидите похожие маркеры разрешения конфликта:

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

Перемещение

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

Для перемещения используется команда , которая воспроизводит изменения тематической ветки на основной; HEAD тематической ветки указывает на последний воспроизведённый коммит.

Перемещение vs. слияние

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

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

Представим сценарий:

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

Поэтому вот совет:

Перемещайте изменения только на вашей приватной локальной ветке — не перемещайте коммиты, от которых зависит ещё кто-то.

Откат коммитов — revert и reset

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

Важно отметить, что это также означает, что вы больше не сможете вернуться обратно к этим изменениям, например, если вы всё-таки решите, что отмена коммита была лишней. Чище — не значит лучше!

Installation

The executable has no dependencies, but since it was designed to wrap
, it’s recommended to have at least git 1.7.3 or newer.

platform manager command to run
macOS, Linux
Windows
Windows
Fedora Linux
Arch Linux
FreeBSD
Debian
Ubuntu We do not recommend installing the snap anymore.
openSUSE
Void Linux xbps
Gentoo
any

Packages other than Homebrew are community-maintained (thank you!) and they
are not guaranteed to match the latest hub release. Check after installing a community package.

Standalone

can be easily installed as an executable. Download the latest
binary for your system and put it anywhere in your executable path.

GitHub Actions

hub is ready to be used in your GitHub Actions workflows:

steps:
- uses: actions/checkout@v2

- name: List open pull requests
  run: hub pr list
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Note that the default will only work for API operations
scoped to the repository that runs this workflow. If you need to interact with other
repositories, generate a Personal Access Token with at least the scope
and add it to your repository secrets.

Source

Prerequisites for building from source are:

Clone this repository and run :

git clone \
  --config transfer.fsckobjects=false \
  --config receive.fsckobjects=false \
  --config fetch.fsckobjects=false \
  https://github.com/github/hub.git

cd hub
make install prefix=/usr/local

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

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

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

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

Что только что сейчас произошло? Мистическим образом у нас оказалось два репозитория в одной папке, а значит и возможность вести параллельную историю файлов! Почему ? Да для единообразия. Давайте заведём себе алиас, чтобы упростить работу со вторым репозиторием:

Пробуем:

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

Игнорировать у гита заложено в генах, а вот всё остальное, как мы видим, отображается как есть. Наибольшая проблема — у них будет один на двоих, так что практически всё, что может потребоваться во втором репозитории, придётся добавлять через , а всё что не требуется — не забываем игнорировать через . По умолчанию можно добавить следующие строчки:

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

Вариант 2. Я вообще ничего не знаю

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

Ну что ж, приступим к делу!

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

Репозиторий — это место, в котором вы систематизируете свой проект. Здесь вы храните файлы, папки, видео, изображения, блокноты Jupyter Notebook, наборы данных и т.д. Перед началом работы с Git необходимо инициализировать репозиторий для проекта и правильно его подготовить. Это можно сделать на сайте GitHub.

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

Перейдите на сайт GitHub. Нажмите на значок + в верхнем правом углу, а затем выберите New repository.
Придумайте имя репозитория и добавьте короткое описание.
Решите, будет ли этот репозиторий размещаться в открытом доступе или останется закрытым для просмотра.
Нажмите Initialize this repository with a README для добавления README-файла

Настоятельно рекомендую снабжать все ваши проекты файлом-описанием, ведь README — это первая вещь, на которую люди обращают внимание при просмотре репозитория. К тому же, здесь можно разместить нужную информацию для понимания или запуска проекта.

Подробное введение в работу с git

Новый репозиторий
Подробное введение в работу с git

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

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

Вносить изменения в проект можно двумя способами. Вы можете изменять файлы/блокноты на компьютере либо делать это на сайте GitHub.

Допустим, вам захотелось подкорректировать README-файл на сайте GitHub.

  • Для начала перейдите в ваш репозиторий.
  • Для выбора файла кликните по его названию (например, кликните по README.md для перехода к файлу-описанию).
  • В верхнем правом углу вы увидите иконку с карандашом. Нажмите на нее для внесения изменений.
  • Напишите короткое сообщение, передающее суть изменений (и подробное описание, если сочтете это нужным).
  • Нажмите кнопку Commit changes.

Подробное введение в работу с git

Изменение файла на GitHub
Подробное введение в работу с git

Подготовка коммита с изменениями

Вы успешно внесли изменения в README-файл своего нового репозитория! Обратите внимание на небольшую кнопку на картинке выше. Она позволяет создавать новую ветку этого коммита и добавлять Pull request

Запомните ее, скоро к ней вернемся.

Как вы видите — ничего сложного!

Лично я предпочитаю работать с файлами на локальном компьютере, а не на сайте GitHub. Поэтому давайте научимся и этому.

Удалённые серверы

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

Команда выводит список удалённых репозиториев, которые мы отслеживаем, и имена, которые мы им присвоили.

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

Наиболее употребляемые команды:

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

Следующие команды работают с удалёнными ветками:

  • — получает данные из ветки заданного репозитория, но не сливает изменения;
  • — сливает данные из ветки заданного репозитория;
  • — отправляет изменения в ветку заданного репозитория. Если локальная ветка уже отслеживает удалённую, то можно использовать просто или .

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

Основные термины VCS

Коммиты (commit)

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

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

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

Перво-наперво, Юлия должна выполнить апдейт (update) своего локального репозитория – синхронизироваться с сервером и получить последнюю на данный момент версию ПО. Для этого выполняется соответствующая команда.

Затем Юля занимается разработкой модуля для фильтрации изображении.

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

  1. Выполняется команда коммит (commit). Коммит – это сохранение изменений в проекте. Он обязательно должен сопровождаться текстовым комментарием разработчика о том, какая работа была проделана, и что изменено, либо написано. Коммит поможет другим разработчикам легче разобраться в чужом коде. Кроме того, по коммитам выполняется откат к предыдущей версии проекта, если вдруг что-то было сделано неправильно, либо с фатальными ошибками. Коммит фиксируется в локальном репозитории.
  2. Затем нужно синхронизировать локальный коммит с облаком и запушить (push) все изменения на сервер. Выполняется команда push.

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

Конфликты

Конфликты возникают во время операции push, когда оказывается, что два разработчика работали над одним и тем же кодом. Что и понятно.

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

Ветки (branch)

Рассмотрим создание веток опять же на примере проекта “графический редактор”.

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

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

В данной ситуации делается следующее: выделяется ветка (бранч, branch). Создание branch – это создание копии текущего репозитория. Дальнейшая разработка в рамках новой ветки никак не будет затрагивать начальную основную ветку проекта (которая называется master).

Разработка в рамках новой ветки идентична разработке основной ветки. Коммиты, push – это всё на месте.

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

На этом всё! До встречи на vscode.ru!

Из следующих статей на тему работы с GitHub Вы узнаете:

  • Про регистрацию на GitHub
  • Как пользоваться GitHub

Представляем аналитику посещаемости Гитхаба

Перевод

Выходные окончились, и к нам возвращается прежний настрой на внедрение новых функций Гитхаба. Исходя из желания зрелищно начать 2014 год, сегодня мы с удовольствием запускаем аналитику посещаемости!
Теперь вы сможете видеть подробные проанализированные сведения о посещениях тех репозиториев, которыми владеете или в которых можете напрямую помещать код (push). Просто зайдите на страницу графиков конкретного репозитория — и увидите новую ссылку, ведущую на страницу «Traffic».
Зайдя на страницу посещений, вы увидите множество полезных сведений о своих репозиториях, в том числе о том, откуда приходят читатели, что они просматривают.
Глядеть на эти цифры о собственных наших репозиториях было забавно, иногда удивительно, всегда интересно. Надеемся, что и вам это понравится не меньше, чем нам!

Анализ инцидента 21 октября на GitHub

Перевод

Роковые 43 секунды, которые вызвали суточную деградацию сервиса
На прошлой неделе в GitHub произошёл инцидент, который привёл к деградации сервиса на 24 часа и 11 минут. Инцидент затронул не всю платформу, а только несколько внутренних систем, что привело к отображению устаревшей и непоследовательной информации. В конечном счете данные пользователей не были потеряны, но ручная сверка нескольких секунд записи в БД выполняется до сих пор. На протяжении почти всего сбоя GitHub также не мог обрабатывать вебхуки, создавать и публиковать сайты GitHub Pages.
Все мы в GitHub хотели бы искренне извиниться за проблемы, которые возникли у всех вас. Мы знаем о вашем доверии GitHub и гордимся созданием устойчивых систем, которые поддерживают высокую доступность нашей платформы. С этим инцидентом мы вас подвели и глубоко сожалеем. Хотя мы не можем отменить проблемы из-за деградации платформы GitHub в течение длительного времени, но можем объяснить причины произошедшего, рассказать об усвоенных уроках и о мерах, которые позволят компании лучше защититься от подобных сбоев в будущем.

Aliasing

Some hub features feel best when it’s aliased as . This is not dangerous; your
normal git commands will all work. hub merely adds some sugar.

displays instructions for the current shell. With the flag, it
outputs a script suitable for .

You should place this command in your or other startup script:

eval "$(hub alias -s)"

PowerShell

If you’re using PowerShell, you can set an alias for by placing the
following in your PowerShell profile (usually
):

Set-Alias git hub

A simple way to do this is to run the following from the PowerShell prompt:

Add-Content $PROFILE "`nSet-Alias git hub"

Note: You’ll need to restart your PowerShell console in order for the changes to be picked up.

If your PowerShell profile doesn’t exist, you can create it by running the following:

New-Item -Type file -Force $PROFILE

hub repository contains tab-completion scripts for bash, zsh and fish.
These scripts complement existing completion scripts that ship with git.

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

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

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

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

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

  • пробел ␣ — отсутствие оттенка — никакой активности в заданный день,
  • звёздочка * — светлый оттенок — средняя активность в заданный день,
  • решётка # — тёмный оттенок — большая активность в заданный день.

Например, напишем слово „ПРИВЕТ“ (используем звёздочку в качестве антиалиасинга для „плавных“ переходов):

Лучше оставлять по паре недель (пробелов) слева и справа — чтобы меньше мешала текущая активность.

Теперь самое сложное — разобрать этот массив, соотнеся каждый символ в нём с каким-то определённым днём. У меня получилось так:

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

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

Программирование логики готово. Вынесем все нужные настройки в один файл , чтобы отделить данные от логики:

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

Придумываем нужный нам график активности. Пишем желаемую картинку в настройках. Запускаем то, что получилось:

Ой, пятница от радости выпрыгнула за ограничение в 52 символа. Поправим:

Скрипт с коммитами создан, запустим его:

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

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

Готово.

Что такое Hub?

Если Git — это сердце GitHub, то Hub — это его душа. Концентратор в GitHub — это то, что превращает командную строку, такую ​​как Git, в крупнейшую социальную сеть для разработчиков.

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

Репозиторий

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

Ветка

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

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

Запрос на извлечение

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

Следуйте приведённым ниже инструкциям, чтобы создать запрос на извлечение в GitHub:

  1. Перейдите в хранилище и найдите ветку меню
  2. В меню выберите ветку, которая содержит ваш коммит
  3. Нажмите кнопку Новый запрос на извлечение рядом с меню ветки
  4. Вставьте заголовок и описание для вашего запроса.
  5. Нажмите кнопку Создать запрос на извлечение

Форкинг репозитория

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

Это отличная функция, которая ускоряет разработку проекта. Поскольку это совершенно новый проект, центральное хранилище не будет затронуто. Если «главный» репозиторий обновлён, вы также можете применить это обновление к вашему текущему форку.

Следуйте приведённым ниже инструкциям, чтобы создать репозиторий в GitHub:

  1. Найдите репозиторий, который вы хотите разветвлять
  2. Нажмите кнопку Форк

GitHub не ограничен только для разработчиков

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

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

Готовы начать?

Эффективное использование Github

Github — важная часть жизни современного разработчика: он стал стандартом для размещения opensource-проектов. В «2ГИС» мы используем гитхаб для разработки проектов web-отдела и хостинга проектов с открытым кодом.
Хотя большинство из нас пользуются сервисом практически каждый день, не все знают, что у него есть много фишек, помогающих облегчить работу или рутинные операции. Например, получение публичного ключа из URL; отслеживание того, с каких сайтов пользователи приходят в репозиторий; правильный шаринг ссылок на файлы, которые живут в репозиториях гитхаба; горячие клавиши и тому подобное. Цель этой статьи — рассказать о неочевидных вещах и вообще о том, что сделает вашу работу с гитхабом продуктивнее и веселее (я не буду рассматривать здесь работу с API гитхаба, так как эта тема заслуживает отдельной статьи).

История коммитов в Git

Git хранит данные в виде набора легковесных «снимков», известных как коммиты. Они хранят состояние файловой системы в определённый момент времени, а также указатель на предыдущий(-ие) коммит(-ы). Каждый коммит содержит уникальную контрольную сумму — идентификатор, который Git использует, чтобы ссылаться на коммит. Чтобы отслеживать историю, Git хранит указатель HEAD, который указывает на первый коммит (мы следуем по цепочке коммитов в обратном порядке, чтобы попасть к предыдущим коммитам).

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