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

Введение в 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. Спасибо за внимание.

pupi-boy.ru

Как научить людей использовать Git / Habr

По работе приходится участвовать в разных проектах, поэтому я хорошо знаю, как работают все мои коллеги. Помню, что компания начала использовать Git буквально за пару недель до моего прихода. На мониторах разработчиков кругом висели наклейки с напоминанием: сначала add, потом коммит, затем пуш.
Они не знали, зачем. Программистам просто сказали строго следовать инструкции, иначе беда. Но проблемы возникали так часто, что я решила провести семинар по Git.


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

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

Кроме того, очень важно научить человека терминам. Иначе он не поймёт сообщения от Git. Рисунки — хороший способ.

На рисунке четыре области распределены следующим образом:

• Среда разработки:
  
  • Рабочий каталог
  • Промежуточная область (staging) или индекс
  • Локальный репозиторий
• Сервер:
  
  • Удалённый репозиторий

Здесь можно объяснить преимущества распределённой системы управления версиями.

При клонировании данные из удалённого репозитория перемещаются в две области:

• Рабочий каталог
• Локальный репозиторий

В рабочем каталоге два типа файлов:

• Отслеживаемые: файлы, о которых знает Git.
• Неотслеживаемые: которые ещё не были добавлены, поэтому Git не знает о них.

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

Когда там накопился ряд изменений с общей целью, самое время создать в локальном репозитории коммит с сообщением об этой цели.

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

удалённый репозиторий.

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

Далее вы можете объяснить:

• как показать изменения файла в рабочем каталоге: git diff
• как показать изменения файла в промежуточной области: git diff --staged
• как изменить файл в рабочем каталоге после добавления в промежуточную область
• и т. д.

Получение (fetching)

При выполнении git fetch данные из удалённого репозитория перемещаются только в локальный репозиторий.

Вытягивание (pulling)

При выполнении git pull данные из удалённого репозитория перемещаются в две области:

• В локальный репозиторий: fetch
• В рабочий каталог: merge

Если важна история коммитов, рассмотрите возможность использования git pull --rebase. Тогда вместо команд fetch + merge выполняются команды fetch + rebase. Ваши локальные коммиты будут воспроизведены, так что вы не увидите в истории коммитов известную форму бриллианта.

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

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

Я работала с другими системами управления версиями (Visual SourceSafe, TFS и Subversion): по моему скромному опыту, недостаток знаний вредит и со старым инструментом, и с новым. Сосредоточьтесь не только на выборе инструмента, но и на его освоении.


Мой друг Марк Виллаграса напомнил, что очень полезно решить задачки Git и делиться с коллегами решением.

Ресурсы из комментариев на Hacker News:

Прочитав комментарии на Reddit, я подумала, что более точным названием этой статьи было бы «Идея, как научить людей использовать Git», потому что это только идея, которая появилась в моей голове, когда я сама несколько лет назад изучала Git по книге Pro Git. Статья не является полным руководством, лишь отправная точка. Уверена, что все эти ресурсы будут очень полезны. Спасибо!

И спасибо Стюарту Максвеллу, который поделился ссылкой на Hacker News, и u/cryptoz, который запостил её на Reddit!

habr.com

Начало работы с GitHub для чайников

Если Вы решили сделать первые шаги на пути использования VCS (Version Control System), то Вы уже должны понимать насколько это полезная вещь. Преимуществ использования подобных систем масса, но статья не об этом. В этой статье я расскажу как начать работать (под windows 7) с одной из самых популярных систем контроля версий — Github.

Очень часто в свободной речи мы говорим не гитхаб, а просто гит имея ввиду ресурс https://github.com, однако, это не совсем одинаковые вещи. Сам по себе ресурс гитхаб, это веб оболочка системы по контролю и управлению нашими проектами. Это своего рода социальная сеть для разработчиков и не только по php, но и по другим языкам программирования. Что же касается непосредственно гита, то это программа, которую мы будем ставить на наш компьютер/ноутбук.

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

1. msysgit. Скачать последнюю версию можно отсюда -> Git
2. TortoiseGit (32bit и 64bit)

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

Обратите внимание!Сначала нам надо поставить msysgit, а после — TortoiseGit

Процесс установки msysgit интуитивно понятный, поэтому останавливаться на нем мы не будем. Единственное — все настройки, что нам предлагаются в процессе установки можно не менять и оставить их по-умолчанию.

Далее ставим TortoiseGit. Тут тоже все просто. Главное, во время установки, когда Вы увидите такое окно:

Укажите тот пункт, который Вы видите на скрине выше.

После установки этих пакетов, считайте, что первый этап пройден. Второй этап — получение доступа к нашему репозиторию на Github.

Для начала нам надо пройти регистрацию на сайте https://github.com. Регистрация на этом сайте простая и мало чем отличается от подобных операций на других сайтах.

Обратите внимание! Во время регистрации указывайте реальный email, которым Вы пользуетесь

После этого, нам нужен будет тот имеил, который мы указали при регистрации. Если Вы вдруг забыли какой именно указали при регистрации, то его можно посмотреть в разделе Edit Profile -> Emails (https://github.com/settings/emails) и в главном окне Вы его увидите:

Тут закончили, теперь нам надо сгенерировать SSH key. Это такая цифровая подпись для Вашего компьютера. Чтобы получить этот ключ, нам понадобится тот самый git. После его установки у Вас на рабочем столе должен был появиться ярлык Git Bush. Двойное нажатие на него запустит консоль.

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

Теперь в командной строке необходимо выполнить команду:

ssh-keygen -t rsa -C «E-Mail из Вашего профиля»

ssh-keygen -t rsa -C «E-Mail из Вашего профиля»

После этого, здесь же, появится надпись «Enter file in which to save the key». Пока мы оставим все как есть и просто нажмем Enter. Теперь нас просят ввести пароль, пока мы пропустим и этот шаг нажав Enter, но в последствии этот пароль можно будет ввести самостоятельно. После этого у нас сгенерируются два файла — один из них будет нашим SSH ключом.

Обратите внимание! У Вас может быть не установлен модуль ssh-keygen и вышеописанная команда попросту не сработает, а как следствие — ключ генериться не будет. В таком случае либо качайте программы вроде putty. Более подробно в статье на хабре -> http://habrahabr.ru/. Либо используйте соединение по протоколу HTTPS.

Если Вы все делали как описано в этой инструкции и ничего в процессе не меняли, то файлы будут находиться здесь: C:/users/{UserName}/.ssh/

В этой папке нам нужен будет файл ida_rsa.pub, который надо открыть при помощи обычного блокнота и скопировать содержимое в буфер обмена (попросту говоря, в открытом файле нажать Ctrl+A, затем Ctrl+C).

Следующим шагом настройки, будет занесение этого ключа в Ваш профиль на гитхабе. Для этого идите в настройки Вашего профиля: Settings -> SSH Keys и нажмите кнопку Add SSH key, как показано на скрине ниже.

Перед Вами открылась форма с двумя полями:

1. Title
2. Key

Тайтл оставляйте пустым, а вот в поле Key вставьте скопированный ранее текст из файла ida_rsa.pub.

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

Теперь создайте отдельную папку на локальном хосте в которой будет храниться Ваш проект и вызовите на ней контекстное меню. Затем выберите пункт TortoiseGit -> Settings как показано на скрине:

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

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

Скопируйте этот адрес в буфер обмена. Теперь вызовите контекстное меню на папке, которую Вы создали под свой проект и выберите команду «Git Clone…»:

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

Обратите внимание на поле Directory — иногда может быть дописана еще одна папка. Проследите чтобы там путь был к вашей папке с проектом, а не какой-нибудь другой. Теперь нажимайте ОК. Начинается клонирование:

На этом этапе можно считать нашу работу оконченной, так как теперь Вам остается только лишь править код, коммитить и пушить ваши правки. Об этом чуть подробней я расскажу в следующей статье.

Продолжение статьи о работе с Git. Учимся добавлять файлы, коммитить и пушить > Начало работы с GitHub для чайников. Часть 2

www.la2q.com

Git и Github. Простые рецепты / Habr

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

Система Git появилась, как средство управления исходными текстами в операционной системе Linux и завоевала множество поклонников в среде Open Source.

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

После того, как вы начали работу над проектом и написали какой-то работающий прототип, у вас появится желание сохранить результаты работы. Это так же может быть полезно в случае, если вы захотите продолжить работу на другом компьютере. Самое простое решение — это сохранить все на флешке. Этот вариант неплохо работает, но если есть подключение к интернету (а сейчас у кого его нет), то удобно воспользоваться системами Git/Github.

В этой статье будут описаны базовые сценарии использования систем Git/Github при работе над проектом в среде Linux с помощью командной строки. Все примеры проверялись на системе с Linux Ubuntu 14.04 и Git 1.9.1. Если вы пользуетесь другим дистрибутивом, то возможны отличия.

Создание локального репозитория

Предположим, что ваш проект находится в папке /home/user/project. Перед тем, как сохранять исходники, можно посмотреть, нет ли временных файлов в папке с проектом и по возможности их удалить.

Для просмотра папки удобно воспользоваться командой tree, которая покажет не только содержимое каждой папки, но и древовидную структуру директорий.

Часто временные файлы содержат специфические суффиксы, по которым их легко обнаружить и в последствии удалить. Для поиска таких файлов можно воспользоваться командой find. В качестве примера посмотрим, как найти все файлы, которые генерируются компилятором Python и имеют расширение .pyc

Переходим в папку с проектом /home/user/project:

cd /home/user/project

И показываем список файлов с расширением .pyc:

find . -name *.pyc

Эта команда выведет список всех файлов с расширением .pyc в текущей директории и в ее поддиректориях. Для удаления найденных файлов, достаточно добавить ключ -delete к этой команде:

find . -name *.pyc -delete

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

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

git init

После выполнения этой команды появится новая папка с именем .git. В ней будет несколько файлов и поддиректориев. На данный момент система управления версиями еще не видит наших файлов.

Добавление файлов в локальный репозиторий

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

git add readme

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

9f2422325cef705b7682418d05a538d891bad5c8

Добавленные файлы хранятся в папке .git/objects/xx/yyyyyyyy, при этом первые 2 цифры хеша ипользуются для указания директории, а остальное хеш значение является именем файла. Наш добавленный файл будет находится здесь:

.git/objects/9f/2422325cef705b7682418d05a538d891bad5c8

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

ls .git/objects

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

git cat-file -p 9f2422325cef705b7682418d05a538d891bad5c8

Для того, чтобы добавить все файлы из текущей директории введите:

git add .

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

git add --all

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

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

После добавления файлов, все изменения находятся в так называемой staging (или cached) area. Это некоторое временнное хранилище, которое используется для накопления изменений и из которого создаются собственно версии проектов (commit).

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

git status

После выполнения команды мы увидим, что в stage area находится наш файл:

new file:   readme

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

new file:   readme

modified:   readme

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

git add readme

Можно отменить добавления файла readme в staging area с помощью команды:

git rm --cached readme

После выполнения команды, файл readme отметится, как неизмененный системой.

Создание версии проекта

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

git commit -m "comment"

Каждая новая версия сопровождается комментарием.

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

.git/objects/9f/2422325cef705b7682418d05a538d891bad5c8
.git/objects/65/7ab4c07bd3914c7d66e4cb48fe57f5c3aa7026
.git/objects/da/c6721c3b75fcb3c9d87b18ba4cef2e15e0a3d3

Посмотрим, что внутри:

git cat-file -t 657ab4c07bd3914c7d66e4cb48fe57f5c3aa7026

Ключ -t показывает тип объекта. В результате мы видим:

commit

Для второго объекта:

git cat-file -t dac6721c3b75fcb3c9d87b18ba4cef2e15e0a3d3

Результат:

tree

Для самого первого файла:

git cat-file -t 9f2422325cef705b7682418d05a538d891bad5c8

Мы видим:

blob

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

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

git commit -m "comment" --amend

Или так:

git commit --amend --no-edit

Ключ —no-edit нужен, чтобы не вводить заново комментарий.

Можно просмотреть изменения, которые вы внесли последним коммитом:

git show

Или так:

git show --name-only

Ключ —name-only нужен, чтобы показывать только имена измененный файлов. Без него по каждому измененнному файлу будет выдан список всех изменений.

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

git commit -a -m "comment"

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

git log

Или так:

git log --oneline

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

2b82e80 update
657ab4c first

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

git show 657ab4c 

Для отмены последнего коммита (кроме самого первого) можно воспользоваться следующей командой:

git reset HEAD~1

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

git clean -df

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

До текущего момента мы работали с локальным репозиторием, который сохранялся в папке на компьютере. Если мы хотим иметь возможность сохранения проекта в интернете, создадим репозиторий на Github. Для начала нужно зарегистрироваться на сайте github.com под именем myuser (в вашем случае это может быть любое другое имя).

После регистрации нажимаем кнопочку «+» и вводим название репозитория. Выбираем тип Public (репозиторий всегда Public для бесплатной версии) и нажимаем Create.

В результате мы создали репозиторий на сайте Github. На экране мы увидим инструкцию, как соединить наш локальный репозиторий со вновь созданным. Часть команд нам уже знакома.

Добавляем удаленный репозиторий (по протоколу SSH) под именем origin (вместо origin можно использовать любое другое имя).

git remote add origin [email protected]:myuser/project.git

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

git remote -v

Если все было правильно сделано, то увидим:

origin [email protected]:myuser/project.git (fetch)
origin [email protected]:myuser/project.git (push)

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

git remote rm origin

Это может понадобиться, если вы захотите поменять SSH доступ на HTTPS. После этого можно добавить его опять, например под именем github и протоколом HTTPS.

git remote add github https://github.com/myuser/project.git

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

git push -u github master

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

git push

Перенос репозитория на другой компьютер

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

git clone https://github.com/myuser/project.git

Результатом выполнения этой команды будет создание папки project в текущем каталоге. Эта папка также будет содержать локальный репозиторий (то есть папку .git).

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

git clone https://github.com/myuser/project.git <myfolder>

Работа с одним репозиторием с разных компьютеров

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

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

git pull

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

git fetch --all
git reset --hard github/master

Вместо github подставьте название вашего удаленного репозитория, которое вы зарегистрировали командой git push -u.

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

git push

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

git push -f

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

git stash

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

git stash pop

Заключение

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

habr.com

GitHub как пользоваться, 12 возможностей

Хоть убейте, не могу придумать никакого вступления, так что…

Маленький словарик Поскольку термины Git и другие программистские словечки чаще всего употребляются без перевода, то я решил их не переводить. Приведу их тут, для порядка, краткий перевод терминов из этой статьи с «расшифровкой». Fork – «развилка». По сути вы копируете себе проект, чтобы на его основе что-то доработать Pull request — запрос на изменение. Отправка внесенных вами изменений в репозиторий на проверку (то есть в основной проект этот код будет внесен только после подтверждения владельцем репозитория или коллегами по работе) Pull – «втянуть» (в IDE на вашем компьютере, например) проект с GitHub Push – «вытолкнуть» проект c локальной машины на GitHub

#1 Редактирование кода на GitHub.com

Начну с того, что, как мне кажется, и так всем известно (хотя лично я и не подозревал об этом еще неделю назад). При просмотре любого текстового файла на сайте GitHub, в любом репозитории, справа сверху можно видеть маленький карандашик. Если щёлкнуть по нему, можно будет отредактировать этот файл. По завершении, нажмите Propose file change («Предложить изменение файла») и GitHub создаст разветвление репозитория (fork) и запрос на внесение изменений (Pull Request). Поразительно, не правда ли? Он сам создает fork! Нет нужды делать форк и загружать к себе код, вносить локально изменения и отправлять обратно на GitHub c Pull Request’ом. Очень удобно, если нужно внести минимальные правки. не совсем настоящий Pull Request

#2 Вставка изображений

Описания проблем не ограничиваются только текстовыми комментариями. Знаете ли вы, что можно вставлять изображения прямо из буфера обмена? При вставке вы увидите, его загрузку (несомненно, в «облако») и превращение в разметку для отображения изображения. Изящно!

#3 Форматирование кода

Если вам нужно написать блок кода, начните с трёх обратных одинарных кавычек — и GitHub попытается угадать, на каком языке программирования вы пишете. Но если вы размещаете фрагмент кода на таких языках программирования, как Vue, Typescript или JSX, то можете явным образом указать язык, чтобы подсветка синтаксиса была правильной. Обратите внимание на «`jsx в первой строке: …обеспечивающий правильное отображение фрагмента кода: (это распространяется и на Gist, кстати. Если указать для гиста расширение .jsf, будет подсвечиваться синтаксис JSF). Вот список всех поддерживаемых синтаксисов.

#4 Закрытие проблем при помощи «магических слов» в Pull Request’ах

Допустим, вы создаете Pull Request, исправляющий проблему #234. Вы можете вставить текст «исправляет проблему #234» в описание вашего запроса (или в любом месте любого комментария к запросу на изменение). После этого слияние Pull Request’а «автомагически» закроет проблему. Круто, не так ли? Вот больше информации об этом в документации.

#5 Ссылка на комментарии

Требовалось ли вам когда-нибудь создать ссылку на конкретный комментарий, а вы не знали, как это сделать? Эти дни давно прошли, поскольку я раскрою вам секрет: для создания ссылки на комментарий нужно просто щелкнуть на дате/времени рядом с названием. Смотрите, у gaearon’а теперь есть фотка!

#6 Ссылка на код

Итак, вы хотите создать ссылку на конкретную строку кода. В таком случае, попробуйте следующее: щелкните на номере строки рядом с нужным кодом в открытом файле. Ух ты, видите? URL поменялся, в нём теперь виден номер строки! Если удерживать нажатой клавишу SHIFT и нажать на номер другой строки, то – вуаля! – URL поменяется еще раз, и будет подсвечен диапазон строк. Этот URL теперь будет указывать на данный файл и данный диапазон строк. Но погодите, он указывает на текущую ветку. А что, если файл поменяется? Наверное, вам нужна, в этом случае, постоянная ссылка на файл в его текущем состоянии. Я очень ленивый, так что сделал один снимок экрана для всего вышеописанного: Кстати, насчет URL’ов…

#7 Использование URL GitHub в качестве командной строки

Перемещение по GitHub с помощью UI организовано очень удобно. Но иногда, чтобы попасть в определенное место, быстрее окажется просто набрать его в URL. Например, если мне нужно перейти в ветку, над которой я работаю и посмотреть отличия её от ветки master, я могу просто ввести /compare/имя_ветки после имени репозитория. После этого я попаду на страницу различий для данной ветки: Но это отличия от ветки master, если же я работал до этого с веткой интеграции, то могу ввести в URL /compare/integration-branch…my-branch Для любителей горячих клавиш: CTRL+L или CMD+L переводит курсор в строку URL (по крайней мере в браузерах Chrome и Firefox). Это, в сочетании с автодополнением браузера, значительно упрощает перемещение между ветками. Совет от профи: воспользуйтесь стрелками для перемещения по предложениям автодополнения Chrome и нажимайте SHIFT+DELETE для удаления элементов из истории (например, после слияния ветки). (Не знаю, будет ли легче читать эти горячие сочетания клавиш, если буду ставить в них пробел, вот так SHIFT + DELETE. Но формально «+» не является их частью, так что мне этот вариант не нравится. Именно из-за таких вещей я и не сплю по ночам, Ронда.)

#8 Создание списков для проблем

Хотите ли вы, чтобы в вашем описании проблемы присутствовал чекбокс? И хотите ли вы, чтобы при просмотре проблемы из списка отображалась элегантная полоска вроде «2 из 5»? Никаких проблем! Создавать интерактивные кнопки-флажки можно с помощью следующего синтаксиса:

• [ ] Screen width (integer)
• [x] Service worker support
• [x] Fetch support
• [ ] CSS flexbox support
• [ ] Custom elements

Синтаксис: пробел, дефис, пробел, открывающаяся квадратная скобка, пробел (или x), закрывающаяся квадратная скобка, пробел и какие-нибудь слова. После этого вы сможете действительно ставить/убирать галочки с этих кнопок! Мне это, почему-то, кажется каким-то техническим волшебством. Вы можете ставить галочки! И при этом исходный текст меняется! Страшно подумать, что они придумают дальше. А, и если эта проблема есть на панели проекта, то там тоже будет отображаться ход выполнения: Если вам непонятно, что я имею в виду под «панелью проекта» – читайте ниже. Всего на пару сантиметров ниже на этой странице.

#9 Панели проектов в GitHub

Для больших проектов я всегда использовал Jira. А для своих личных проектов я всегда использовал Trello. Оба этих инструмента мне очень нравятся. Когда несколько недель назад я узнал, что GitHub предлагает свой собственный вариант, прямо на закладке Projects репозитория, я подумал, что иметь смысл продублировать набор задач, с которыми я уже работаю в Trello. Ничего веселого тут нет А теперь то же самое в проекте GitHub: Постепенно ваши глаза привыкнут к неконтрастному изображению Ради ускорения я добавил все вышеуказанное в виде заметок (notes), то есть они не являются «настоящими» проблемами (issues) GitHub. Но мощь управления задачами в GitHub состоит в интеграции с остальным репозиторием – так что, вероятно, лучше добавить существующие проблемы из репозитория на панель. Нажмите Add Cards в верхнем правом углу и найдите то, что хотели бы добавить. Здесь пригодится специальный синтаксис поиска: например, наберите is:pr is:open и вы сможете перетащить любой открытый Pull Request на панель, или label:bug, если нужно исправить какие-то ошибки. А ещё можно преобразовать существующие заметки в проблемы. И, наконец, из формы существующей проблемы, добавить её в проект в правой панели. Она попадёт в список triage данной панели проекта, так что вы сможете выбрать, в какой столбец её поместить Когда описание «таска» находится в том же репозитории, что и реализующий этот таск код, это очень (ооооочень) удобно. Это значит, что через много лет вы сможете выполнить команду git blame для какой-либо строки кода и выяснить всю подоплёку задачи, которая к этой строке привела, без того, чтобы отслеживать это всё в Jira/Trello/еще где-нибудь.

Недостатки

Последние три недели я экспериментировал с выполнением всех задач в GitHub вместо Jira (на маленьком проекте, примерно в стиле Канбан) и мне это понравилось. Но я не могу себе представить это для scrum-проекта, где необходимо оценивать и подсчитывать должным образом скорость разработки и тому подобное. Хорошая новость: у проектов GitHub настолько мало «особенностей», что переход на другую систему не займет, в случае чего, много времени. Так что попробуйте, посмотрим, насколько вам понравится. Не знаю, насколько это важно, но я слышал про ZenHub и открыл его впервые 10 минут назад. Фактически это расширение GitHub, в котором можно оценивать проблемы и создавать «epics» и зависимости. Там есть графики скорости разработки и выгорания; похоже, что это просто потрясающая вещь. Дальнейшее чтение: документация GitHub по Projects.

#10 Gwiki

Для неструктурированного набора страниц – подобного Википедии – GitHub Wiki (которую я буду далее называть просто Gwiki) просто великолепна. Для структурированного же набора страниц – например, как ваша документация – уже не настолько. Отсутствует возможность указать, что «вот эта страница – дочерняя по отношению к вот той», нет таких удобных вещей, как кнопки «Следующий раздел» и «Предыдущий раздел». Гензель и Гретель тут бы точно заблудились, потому что «хлебных крошек» (специальных отладочных операторов – прим. перев.) тут тоже нет. (Примечание автора: Вы читали эту историю? Она просто бесчеловечна. Двое юных отморозков убивают несчастную голодную старушку, сжигая её заживо в её собственной печи. И конечно же, оставляя непонятно кому полный беспорядок. Мне кажется, именно поэтому молодежь в наши дни адски чувствительна – в наши дни сказки, читаемые детям перед сном, недостаточно жестоки!) Продолжаем – чтобы попробовать Gwiki на деле, я ввел несколько страниц из NodeJS в качестве страниц вики, после чего создал пользовательскую боковую панель, чтобы смоделировать реальную структуру сайта. Эта боковая панель находится там постоянно, хотя текущая страница и не подсвечивается. Ссылки придется поддерживать вручную, но в целом все работает отлично. Если хотите, можете взглянуть: Это вряд ли может соперничать с чем-то вроде GitBook (который используется в документации Redux) или сделанным на заказ веб-сайтом. Но это уже добрых 80% от него и все прямо в вашем репозитории. Я просто фанат этого. Предлагаю: если вы уже переросли этап использования одного файла README.md и вам нужно несколько различных страниц для руководств пользователя или более подробной документации, имеет смысл остановиться на Gwiki. Если же отсутствие структуры/навигации вам мешает, переходите на что-либо ещё.

#11 GitHub Pages

Возможно, вы уже знали, что GitHub Pages можно использовать для размещения статического сайта. А если не знали, то знаете теперь. Однако этот раздел посвящен более узкому вопросу: использованию Jekyll для создания сайта. В простейшем варианте, GitHub Pages + Jekyll могут визуализировать файл README.md с использованием приятной глазу темы. Например, взгляните на мою страницу readme из about-github: Если нажать на закладку settings («настройки») для этого сайта на GitHub, включить GitHub Pages и выбрать тему Jekyll… То мы получим страницу в стиле темы Jekyll: После этого можно создать целый статический сайт на основе, главным образом, легко редактируемых файлов разметки, по существу, превращая GitHub в CMS. Хотя фактически я этого не использовал, именно так создаются сайты на фреймворке Bootstrap с использованием React, так что ничего ужасного в этом нет. Отмечу, что на локальной машине должен быть запущен Ruby (пользователи Windows тут обменяются понимающими взглядами и пойдут другим путём, пользователи macOS скажут: «В чем проблема, вы куда? Ruby – универсальная платформа! Там же есть система управления пакетами GEMS!») (Стоит отметить также, что «Агрессивный или угрожающий контент или поведение» в GitHub Pages недопустимы, так что вы не сможете разместить там свою версию истории про Гензеля и Гретель).

Мое мнение

Чем детальнее я изучал связку GitHub Pages + Jekyll (для этой статьи), тем больше мне казалось, что вся эта идея странно попахивает. Идея «сделать свой собственный веб-сайт с приложением минимальных усилий» замечательна. Но для работы над ним все равно требуется текущий вариант на локальной машине. И для чего-то столь «простого» тут слишком много команд командной строки. Я бегло просмотрел семь страниц из раздела Getting Started и почувствовал, что единственное, что тут простого – это я сам. И это я еще даже не разобрался с простым синтаксисом для главной страницы или азами простого «Механизма шаблонизации на основе языка Liquid». Уж лучше я напишу веб-сайт самостоятельно! Если честно, я немного удивлен, что Facebook использует это для документации React, в то время как они могли бы, вероятно, формировать страницы их системы помощи при помощи React и выполнять предварительную визуализацию в виде статических HTML-файлов каждый день. Все, что им нужно – всего лишь найти способ получать существующие файлы разметки так, как если бы они поступали из CMS. А что, если…

#12 Использование GitHub в качестве CMS

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

class Markdown extends React.Component {
    constructor(props) {
      super(props);

      
      this.baseUrl = 'https://raw.githubusercontent.com/davidgilbertson/about-github/master/text-snippets';

      this.state = {
        markdown: '',
      };
    }

    componentDidMount() {
      fetch(`${this.baseUrl}/${this.props.url}`)
        .then(response => response.text())
        .then((markdown) => {
          this.setState({markdown});
        });
    }

    render() {
      return (
        <div dangerouslySetInnerHTML={{__html: marked(this.state.markdown)}} />
      );
    }
}

(я использую тут пакет npm marked для синтаксического разбора разметки в HTML) URL указывает на мой репозиторий примеров, в каталоге /text-snippets которого лежат файлы разметки. (Можно также использовать API GitHub для получения контента, но я сомневаюсь, что это вам пригодится) Использовать подобный компонент можно следующим образом:

const Page = () => (
  <div className="page">
    <div className="about-us">
      <Markdown url="about-us.md" />
    </div>

    <div className="disclaimer">
      <p>A very important disclaimer:</p>

      <Markdown url="disclaimers/home-page-disclaimer.md" />
    </div>
  </div>
);

Так что теперь GitHub играет роль, в некотором роде, вашего CMS, для тех кусков текста, которые вы хотели бы разместить. Вышеприведенный пример извлекает разметку только после того, как компонент будет загружен в браузере. Если вам нужен статический сайт, то придется визуализировать его на сервере. Хорошая новость! Ничто не мешает вам извлечь все файлы разметки на сервере (при использовании любой устраивающей вас стратегии кэширования). Если вы решите пойти этим путем, то вам имеет смысл воспользоваться API GitHub, чтобы получить список всех файлов разметки в каталоге. Бонус – утилиты GitHub! Я уже довольно давно использую расширение Octotree для браузера Chrome и рекомендую его вам. Не без оговорок, но все же рекомендую. Оно отображает слева панель с древовидным представлением просматриваемого репозитория. А из этого видео я узнал про octobox, который также пока что представляется мне весьма неплохой утилитой. Это папка для входящих для ваших проблем GitHub. Это всё, что вам нужно о нём знать. Говоря о цветах, я сделал все вышеприведенные снимки экрана в светлой теме, чтобы вас не пугать. Но если во всём остальном я предпочитаю темные цвета, то зачем терпеть мертвенно-бледный GitHub? Здесь я использовал сочетание расширения Stylish для браузера Chrome (умеющее применять темы к любому веб-сайту) и стиля GitHub Dark. И на закуску, темная тема инструментов разработчика GitHub (встроенная, только нужно включить) и тема Atom One Dark для Chrome.

Bitbucket

Строго говоря, он здесь не совсем уместен, но я просто не могу не упомянуть Bitbucket. Два года назад я начинал проект и провел полдня за выбором оптимального git-хостинга. Так вот, Bitbucket выиграл с существенным отрывом. Их поток рецензирования кода ушел далеко вперед от конкурентов (это было задолго до того, как в GitHub появилось хотя бы понятие рецензента). С тех пор GitHub тоже обзавелся рецензиями. К сожалению, последний год мне не доводилось использовать Bitbucket – возможно, они опять ушли вперед в чём-нибудь. Так что я рекомендую тем, кто отвечает за выбор git-хостинга, обратить внимание и на Bitbucket.

Заключение

Вот и всё! Надеюсь, что сумел рассказать вам хотя бы три ранее незнакомых вам вещи. И ещё надеюсь, что вы хорошо провели время за чтением моей статьи. Перевод статьи: 12 cool things you can do with GitHub

javarush.ru

Как пользоваться GitHub — Программирование на C, C# и Java

Чтобы начать пользоваться GitHub – сначала необходимо зарегистрироваться на github.com. Затем Вы можете перейти к использованию сервиса. Работа с VCS возможна двумя способами: через web-интерфейс и с помощью программы на Windows или Mac. Рассмотрим оба варианта взаимодействия с GitHub.

Также рекомендуем ознакомиться со статьёй “GitHub – что это?“, в которой рассказывается о терминологии, принятой при работе с VCS, и о GitHub вообще.

Как пользоваться GitHub через web-интерфейс сайта

После того, как Вы войдёте в свою учётную запись, можно создать новый репозиторий с помощью кнопки “New repository”.

Затем нужно ввести имя нового репозитория (Repository name), его описание (Description) [необязательно], выбрать тип: публичное или приватное (платно), указать – следует ли сразу добавить в репозиторий README-файл, а также можно выбрать параметры для файла .gitignore и приложить текст лицензионного соглашения.

После того, как все данные будут заполнены, нажмите кнопку “Create repository” для создания репозитория.

Файл .gitignore описывает файлы и папки, которые Git не будет загружать в хранилище репозитория. Многие среды разработки программного обеспечения создают свои системные файлы, которые нужны только самой IDE и не содержат никакого кода (плюс зачастую ещё и много весят). С помощью .gitignore можно запретить загрузку файлов такого типа в репозиторий.

Затем Вы попадёте на страницу созданного репозитория:

На ней представлен список файлов, находящихся в репозитории, элементы управления и файл Readme.

Чтобы загрузить новые файлы и выполнить коммит – нажмите кнопку “Upload files”.

Переключение между ветками проекта и создание новых – происходит с помощью кнопки “Branch”.

Создание новой ветки проекта

Новый пулл запросов создаётся кнопкой “New pull request”.

Добавление других программистов к проекту происходит в настройках (Settings) на вкладке Collaborators (коллеги). Для добавления соавтора необходимо ввести в текстовое поле его логин на GitHub или электронную почту, указанную при регистрации, и затем нажать кнопку “Add collaborator” (добавить коллегу).

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

При необходимости Вы (или другие разработчики) можете клонировать репозиторий на свой компьютер с помощью Git-клиента и ссылки или скачать его в виде zip-архива. Данные опции доступны при нажатии кнопки “Clone or download” (клонировать или скачать).

Клонирование (с помощью ссылки) или загрузка Git-репозитория

Если Вам нужно удалить репозиторий на GitHub, то для этого перейдите в настройки (Settings) и в самом низу страницы (в Danger Zone), будет кнопка “Delete this repository” (удалить данный репозиторий).

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

Внимание! Будьте осторожны, после удаления – никакие данные невозможно восстановить!

Как пользоваться GitHub с помощью клиента для компьютера GitHub Desktop

Перво-наперво нужно загрузить и установить на свой компьютер Git-клиент. Их существует множество, но мы поработаем с официальным клиентом для GitHub. Он доступен для загрузки по следующей ссылке. Есть клиенты для Windows и Mac.

Интерфейс Git-клиента

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

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

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

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

Изменения, внесённые в файлы подсвечиваются в Git-клиенте. Чтобы сделать коммит в локальное хранилище введём название коммита и описание [необязательно], затем нажмём кнопку “Commit to”.

Чтобы загрузить изменения в облако (выполнить команду Push), необходимо нажать кнопку “Sync”.

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

Спасибо за прочтение статьи!

Как пользоваться GitHub

4.56 (91.25%) 16 votes

Поделиться в соц. сетях:

vscode.ru

15 советов по работе с Github / Mail.ru Group corporate blog / Habr

Я 10 лет разрабатываю ПО, участвовал в нескольких open source-проектах и в многочисленных не-open source-проектах, работал в больших и малых командах, и везде мы использовали Github в качестве репозитория версионирования.

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

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

• Хорошая документация: readme, сайты с документацией и журналы изменений.
• Подробно расписанные соглашения и стандарты кодинга.
• Правильное версионирование с помощью семантического версионирования.
• Автоматизированные тесты: используем их не слишком много, сосредоточимся на функциональных нерегрессионных тестах.
• Конечно же, счастье разработчика!

Предлагаю строить прагматичный рабочий процесс с применением open source-инструментов, помогающих выполнять и автоматизировать многие задачи.

Если вы работает в open source-проекте, то наверняка хотите публиковать свой Github-проект. Git и Github полностью изменили способ разработки OSS, де-факто превратившись, соответственно, в стандартный язык версионирования и площадку для сотрудничества.

Официально предлагаемый Github’ом рабочий процесс называется github flow. Он прекрасно описан на сайте. Этого процесса, с небольшими вариациями, придерживается большинство open source-проектов.

Github Flow очень гибок в том смысле, что он не диктует вам, как нужно релизить и документировать изменения, какую стратегию слияния использовать, когда принимать pull request’ы, какие инструменты применять, каким стандартам коммитов следовать или что нужно рецензировать перед принятием pull request’а. Всё это отдано на ваше усмотрение, и правильно сделано, поскольку не существует универсальных решений, подходящих всем командам.

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

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

Приоритезируйте задачи и отслеживайте прогресс с помощью Github Projects

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

Подробнее

Классифицируйте задачи с помощью тегов

Github имеет превосходные возможности по фильтрации. Если вы работаете над open source-проектом, то наверняка заинтересованы в привлечении других участников, а также в том, чтобы им было удобно. Если помечать свои задачи тегами, разработчикам легче будет ориентироваться в списке, это сэкономит им время и облегчит работу над проектом.

Используйте Github-шаблоны для pull request’ов и задач

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

Подробнее

Основные советы по отчётам о багах:

Прежде чем отправлять информацию о проблеме:

• Удостоверьтесь, что пользуетесь последней версией.
• Поищите упоминание об этом баге, возможно, отчёт о нём уже был раньше.

Отчёты о багах должны содержать:

• Краткое описание.
• Как вы столкнулись с багом? Инструкция по воспроизведению.
• Какого поведения вы ожидали от приложения?
• Как приложение повело себя на самом деле?
• Ссылки на все связанные с ситуацией тикеты или информационные источники.
• По мере возможности, прикрепите визуальное подтверждение бага. Скриншоты, видео и/или анимационные гифы.

Общие рекомендации по pull request’ам:

• Проверьте, что по вашей проблеме ещё нет других pull request’ов.
• Проверьте в баг-трекере, не было ли проблем, связанных с вашим багом.
• Нетривиальные изменения лучше предварительно обсудить.
• Сообщите нам, над какой задачей работаете.
• Разрабатывайте в конкретной тематической ветке, а не в мастере.
• Напишите описание полезного pull request’а.
• Соблюдайте рекомендации по коммитам в проекте.
• Напишите хорошее описание своего pull request’а.
• Укажите в описании ссылку на Github-задачу.

Пользуйтесь командной строкой

Консоль — ваш друг. По моему опыту, освоение работы с Github через командную строку — лучшая трата времени, когда работаешь с open source-технологиями. Да, существует много хороших графических интерфейсов, но все они менее гибки в использовании. Кроме того, есть инструменты только под командную строку, которые сильно упрощают жизнь и повышают эффективность разработки:

• hub — обёртка для Git, облегчающая работу с GitHub. Не важно, новичок вы или опытный open source-разработчик, hub облегчит извлечение репозиториев, навигацию по страницам проекта, работу с форками и даже отправку pull request’ов. И всё это из командной строки. hub.github.com
• tj/git-extras — набор Git-утилит, таких как сводка по репозиторию, repl, журнал изменений, статистика коммитов по авторам, и многое другое. github.com/tj/git-extras

Соблюдайте строгие стандарты коммит-сообщений и категоризируйте коммиты

Всегда определяйте и соблюдайте ясные стандарты написания коммит-сообщений. Вот некоторые рекомендации:

• Коммитьте каждый фикс как отдельное изменение.
• Пишите полезные коммит-сообщения.
• Пишите короткое коммит-сообщение в первой строке (50–100 символов). Если посмотрите результат выполнения gitk или git log –oneline, то поймёте, почему.
• Ссылайтесь на Git-задачу в теле коммит-сообщения.

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

Определяйте стандарты оформления кода и конфигурируйте прекоммит-хуки

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

Я рекомендую использовать Prettier и StandardJS, но это дело вкуса, существует множество других решений; к тому же, вы можете сделать что-то своё. Главное, следуйте выбранным стандартам оформления кода, это пойдёт на пользу.

typicode/husky — прекрасный инструмент для конфигурирования прекоммит-хуков.

Используйте автоматизированные тесты и проверки pull request’ов

Очень желательно автоматизировать функциональные тесты и проверки безопасности и стиля оформления кода в каждом pull request’е. Вряд ли вы захотите всё это делать вручную. Можно быстро сконфигурировать сервер непрерывной интеграции, вроде TravisCI, чтобы автоматически прогонять тематическую ветку через тесты после отправки каждого pull request’а. Также можно сконфигурировать Github, чтобы он не позволял разработчику присоединять pull request’ы, если те не прошли тесты. При сбое тестов Github покажет автору сообщение, чтобы он исправил свои pull request’ы.

Подробнее.

Защищайте свою мастер-ветку и требуйте проводить ревизию кода

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

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

Сквошьте свои pull request’ы

Много споров о том, что правильно: объединять, сквошить (squash) или перебазировать. Я считаю, что лучше всего сквошить, потому что:

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

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

Семантическое версионирование, Github-теги, релизы и автоматизированные журналы изменений
Версионирование играет огромную роль, особенно в open source-проектах, многие из которых будут зависеть от вашего ПО. Семантическое версионирование всем облегчит жизнь, потому что люди, лишь посмотрев на номер версии, будут знать, когда именно были внесены критические изменения, или содержит ли версия новые фичи или исправления багов.

Учитывая шаблон MAJOR.MINOR.PATCH, увеличивайте:

• Старшую (MAJOR) версию, если вносите несовместимые с предыдущими версиями изменения в API.
• Младшую (MINOR) версию, если добавляете обратно совместимую функциональность.
• Патч-версию (PATCH), если вносите обратно совместимые исправления ошибок.

В качестве расширений шаблона MAJOR.MINOR.PATCH можно использовать дополнительные метки для пререлизов и сборок.

Помимо изменения версии package.json, рекомендую для каждой версии генерировать git-тег.

Подробнее.

Спецификация Conventional Commits подразумевает при написании коммит-сообщений соблюдение простого стандартизированного соглашения. Оно увязано с соглашением SemVer, которое просит разработчиков описывать в коммит-сообщениях все фичи, исправления и критические изменения. Соблюдая соглашение, мы создаём стандартный язык, упрощающий отладку в различных проектах.

Подробнее.

Автоматизировать этот процесс поможет TravisCI.

Также обратите внимание на эти пакеты: dominique-mueller/automatic-release, semantic-release/semantic-release.

Автоматизируйте развёртывание с помощью тег-хуков

Не обязательно использовать ветки релизов, как это предлагается в рамках Git Flow. Можно брать артефакты развёртывания из Git-тегов. Здесь описано, как с помощью TravisCI развернуть Git-теги в heroku. Это очень просто, нужно лишь для атрибута тегов задать значение true. Такое поведение можно реализовать с помощью любого другого CI-сервера.

Для среды разработки можно настроить хук, который развёртывает последний мастер-коммит. А для сред комплектов (feature environments) можно использовать и не такие долгоживующие ветки; при желании, для каждого PR-запроса вы можете предоставлять временную тестовую среду, но такой подход сложнее, да и не является обязательным.

Настройте потоковый Github-канал для чата

Очень удобный способ отслеживания активности в ваших Github-репозиториях из места, идеально подходящего для взаимодействия с командой: простой поток уведомлений в одном или нескольких чатах. К слову, в чатах вы можете делать и многое другое, в 2013-м на Github появился термин ChatOps, подробнее о нём рассказывается здесь.

Автоматизируйте обновление зависимостей

Нам приходится регулярно тратить много времени на актуализацию зависимостей. Это идеальная задача для автоматизации. Существует много инструментов, помогающих поддерживать зависимости «свежими», автоматически создавая в проекте pull request’ы с последними версиями. Эти запросы будут прогнаны через автоматизированные нерегрессионные тесты, и если пройдут успешно, то можно надеяться, что код после объединения будет работать нормально. Будьте осторожны с изменениями уровня старших версий, дважды всё проверяйте.

Пара полезных инструментов: greenkeeper.io и david-dm.org.

С помощью расширений улучшайте работу с интерфейсом Github’а

Open source-разработчики создали много полезных расширений, улучшающих работу с интерфейсом Github’а. Например:

• GitHub Avatars [chrome] — отображает аватары в новостной ленте.
• GitHub Awesome Autocomplete [chrome] [firefox] — добавляет функцию мгновенного поиска в поисковый блок GitHub.
• GitHub Categoric [chrome] — категоризирует ваши смешанные GitHub-уведомления.
• GitHub Hovercard [chrome] [firefox] — удобный GitHub-плагин hovercard для пользователей/репозитория/задач.
• GitHub Isometric Contributions [chrome] [safari] — отображает вклад в проект разных людей в виде изометрического pixel art-графика.
• GitHub Linker [chrome] — линкует зависимости в пакете или bower-файле с их GitHub-страницами.
• GitHub Octotree [chrome] [safari] [firefox] [opera] — отображает GitHub-код в виде дерева.
• GitHub Selfies [chrome] — добавляет селфи в pull request’ы и комментарии.
• GitHub Stars Tagger [chrome] — прямо в GitHub добавляет теги в ваши отмеченные звёздами (starred) репозитории.
• Github NPM Hub [chrome] — позволяет исследовать npm-зависимости в GitHub-репозиториях.
• Github vscode-icons [chrome] — показывает vscode-иконки в браузере репозитория.

Другие расширения: GitHub Browser Extensions.

На Kikobeats/awesome-Github есть ещё инструменты для улучшения вашего рабочего процесса.

Постоянная учёба и самосовершенствование

Github и методики разработки open source ПО постоянно развиваются, поэтому держите руку на пульсе новейших тенденций и инструментов, отслеживая Github-новости и соблюдая стандарты вашего сообщества. Прекрасный источник информации — Youtube-канал GitHub Training & Guides.

habr.com