Гитхаб что это такое


GitHub — Википедия

Материал из Википедии — свободной энциклопедии

GitHub — крупнейший[8]веб-сервис для хостинга IT-проектов и их совместной разработки.

Веб-сервис основан на системе контроля версий Git и разработан на Ruby on Rails[9] и Erlang компанией GitHub, Inc (ранее Logical Awesome)[10]. Сервис бесплатен для проектов с открытым исходным кодом и (с 2019 года) небольших частных проектов, предоставляя им все возможности (включая SSL[11]), а для крупных корпоративных проектов предлагаются различные платные тарифные планы[12].

Слоган сервиса — «Social Coding» — на русский можно перевести как «Пишем код вместе». На футболках же печатают совсем другую фразу: «Fork you!» («Ответвись!»)[13]. С одной стороны, она созвучна с англоязычным ругательством и намекает на неформальную атмосферу. С другой, эти слова напоминают, что создавать новые форки с Git можно легко и безболезненно — традиционно, к созданию веток разработчики проектов с открытым исходным кодом относятся негативно[14] — а также созвучна названию одной из возможностей GitHub — очереди форков[15].

Талисманом GitHub выбран осьмикот (англ. octocat), который, вопреки распространённому заблуждению, не имеет отношения к короткометражке «Octocat Adventure», а просто был найден Томом Престон-Вернером на сервисе iStock (англ.)русск.[16].

4 июня 2018 года Microsoft купила GitHub за 7,5 млрд долларов[17][18][19].

Создатели сайта называют GitHub «социальной сетью для разработчиков».

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

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

Для проектов есть личные страницы, небольшие Вики и система отслеживания ошибок.

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

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

Раньше возможность создавать приватные репозитории была платной.

  • Есть возможность прямого добавления новых файлов в свой репозиторий через веб-интерфейс сервиса[20].
  • Код проектов можно не только скопировать через Git, но и скачать в виде обычных архивов с сайта.
  • Кроме Git, сервис поддерживает получение и редактирование кода через SVN[21][22] и Mercurial[23].
  • На сайте есть pastebin-сервис gist.github.com для быстрой публикации фрагментов кода.

Ранее Ruby-проекты могли быть автоматически опубликованы в RubyGems-репозитории сервиса, но в октябре 2009 GitHub отказался от этого сервиса[24].

Первый частный репозиторий был создан 12 января 2008. К концу 2011 года в проекте уже было зарегистрировано более миллиона пользователей[25] и более двух миллионов репозиториев[26]. По состоянию на март 2017 года на сайте существовало более 58 миллионов репозиториев.[27]

В конце 2008 года GitHub получил награду как «Лучший стартап-дебют»[28].

На Github располагается исходный код ядра Linux.[29]

Многие крупные IT-компании размещают свои официальные репозитории на этом сервисе:[30]

На GitHub размещают свои открытые проекты федеральные агентства США.[45]

ru.wikipedia.org

Как начать работать с GitHub: быстрый старт / Habr

Распределенные системы контроля версий (DVCS) постепенно замещают собой централизованные. Если вы еще не используете одну из них — самое время попробовать.

В статье я постараюсь показать, как можно быстро начать экспериментировать с git, используя сайт github.com.

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

Итак, сайт github.com позиционируется как веб-сервис хостинга проектов с использованием системы контроля версий git, а также как социальная сеть для разработчиков. Пользователи могут создавать неограниченное число репозиториев, для каждого из которых предоставляется wiki, система issue tracking-а, есть возможность проводить code review и многое другое. GitHub на данный момент является самым популярным сервисом такого рода, обогнав Sourceforge и Google Code.

Для open-souce проектов использование сайта бесплатно. При необходимости иметь приватные репозитории, есть возможность перейти на платный тарифный план:

Начнем с регистрации. Идем по ссылке github.com/signup/free и вводим свои данные.
После регистрации мы попадаем на Dashboard нашего аккаунта:

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

Но для начала установим git и настроим его для работы с сайтом.

Если вы работаете в Windows, качаем и устанавливаем msysgit. Это консольная версия git для Windows (далее расказ будет вестись на примере этой ОС).
Инструкция для MacOS X (eng)
Инструкция для Linux (eng)
Проблем возникнуть не должно, просто везде жмем Next. После установки выбираем в контекстном меню Проводника Git Bash:

или через Git Bash.lnk в папке с установленой программой:

Прописываем в консоли свои данные и настройки переносов строк:
git config --global user.name "ваше имя"
git config --global user.email "ваша почта"
git config --global core.autocrlf true
git config --global core.safecrlf true

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

Для тех, кто предпочитает gui — для Windows существует несколько таких инструментов для работы с git. Два основных — это SmartGit (кроссплатформенный) и TortoiseGit. Оба неплохие, и какой использовать — дело вкуса. Я опишу работу с TortoiseGit.
Для маков выбор giu тоже имеется.

  • официальный клиент от GitHub — на мой взгляд пока достаточно сыроват.
  • GitX — лично мне не приглянулся
  • GitBox — наиболее следует mac-way, очень рекомендую попробовать именно его

Качаем по ссылке code.google.com/p/tortoisegit/downloads/list. При установке везде жмем Next.

Теперь возвращаемся к github и создадим новый репозиторий. Находясь на Dashboard, жмем New Repository (https://github.com/repositories/new), вводим данные и жмем Create Repository.

GitHub позволяет работать с репозиториями тремя способами: SSH, HTTP и Git Read-Only, соответственно предоставляя ссылки трех видов для нашего репозитория:
1. [email protected]:habrauser/Hello-world.git
2. [email protected]/habrauser/Hello-world.git
3. git://github.com/habrauser/Hello-world.git

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

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

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

Для генерации ключей, можно воспользоваться инструментом ssh-keygen, который идет в комплекте с git (описание этого способа можно почитать тут). Мы же будем использовать PuTTY (а точнее небольшую программку puttygen, входящую в его состав). PuTTY — это такой клиент для удаленного доступа, в том числе и с использованием SSH.

Качаем последнюю версию с официального сайта (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html). Кстати, puttygen более старой версии (2007 год) идет в составе TortoiseGit.

После установки PuTTY, запускаем puttygen из папки с установленной программой:

Жмем Generate, двигаем некоторое время курсором мыши, для получения случайных данных, необходимых алгоритму

Вводим пароль, защищающий наш приватный ключ в поле Key passphrase, вводим подтверждение, жмем Save private key, сохраняем.

Далее копируем публичный ключ в формате OpenSSH из текстовой области «Public key for pasting...» и идем в настройки нашего аккаунта на github (Account Settings) в раздел SSH Public Keys:

жмем Add another public Key, вставляем наш публичный ключ:

нажимаем Add key. Все, теперь мы готовы работать с github по ssh. Попробуем забрать наш пустой рерозиторий на локальную машину с использованием TortioшseGit. В контекстном меню проводника выбираем Git Clone…

В поле Url вставляем SSH-адрес нашего репозитория, в поле Load Putty Key указываем путь к нашему приватному ключу, жмем OK.

Pageant запросит у наc пароль для приватного ключа (потом этого делать не потребуется)

Pageant — это агент SSH-аутентификации в составе PuTTY, он позволяет управлять закрытыми ключами.
В трее висит его значек:

Репозиторий успешно склонирован на локальную машину

Теперь попробуем изменить локальный репозиторий и отправить изменения на github. Добавим в локальный репозиторий файл README (файл с именем README обрабатывается github специальным образом — его содержимое будет отображаться в качестве описания репозитория на соответствующей странице)

Закоммитим изменения в локальный репозиторий

и синхронизируем его с репозиторием на github:

нажимаем Push

Теперь зайдя на страницу нашего репозитория мы увидим следующее:

Для каждого репозитория сайт предлагает wiki:

а также простую систему issue tracking-a:

кстати, для тех, кто использует в работе Eclipсe — есть соответствующий mylyn-коннектор для github:

и плагин EGit:

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

Резюмируя хочется сказать, что если вы начинающий разработчик, планирующий начать пользоваться системами контроля версий, или же более опытный и присматривающийся к распределенным VCS, но не знающий как начать, то есть смысл попробовать git, используя такой замечательный инструмент как github.com.

Полезные ссылки

Для работы с git:
code.google.com/p/msysgit git для windows
www.syntevo.com/smartgit/index.html SmartGit
code.google.com/p/tortoisegit TortoiseGit
http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY

Про git на русском:
habrahabr.ru/blogs/Git/106912 «Удачная модель ветвления для git» — перевод хорошей англоязычной статьи
githowto.com интерактивный курс по работе с git из консоли
habrahabr.ru/blogs/Git/106912 «Почему git» + обсуждение
habrahabr.ru/blogs/development/68341 «Git для переходящих с SVN» + обсуждение
habrahabr.ru/blogs/Git/75990 «Командная работа в git» + обсуждение
progit.org/book/ru русский перевод книги «Pro Git» (переведено не до конца)
habrahabr.ru/blogs/Git/123111 инструкция-шпаргалка для начинающих
los-t.livejournal.com/tag/git%20guts цикл постов «внутренности git»
lib.custis.ru/%D0%9B%D0%B8%D0%BD%D1%83%D1%81_%D0%A2%D0%BE%D1%80%D0%B2%D0%B0%D0%BB%D1%8C%D0%B4%D1%81_%D0%BE_GIT_%D0%BD%D0%B0_Google_Talks Линус Торвальдс о git
habrahabr.ru/blogs/Git/80909 книга «Волшебство git»

Про git на английском:
книги


видео
другое

habr.com

Git и командная разработка (для чайников) / Habr

Соавтор статьи: RicardoMilos

Введение


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

GIT


Наверняка вам знакома такая ситуация:

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

И тут вы осознаете, что не сохранили работающий вариант, а кнопка Z на вашей клавиатуре сломалась, поэтому вы даже не можете заспамить ctrl+z. В порыве ярости вы пробиваете монитор своей накачанной правой рукой. Вечером вы плачете, укутавшись в пледик, и думаете о тяжелой участи программистов.

Плачевная ситуация… И чтобы такого не происходило, нужно сохранять версии своего кода.

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

И тут мы можем провести аналогию с играми. Почти во всех ААА проектах есть система сохранений. Как наглядный пример можно привести игру Papers Please.

Примерно также и работают все системы контроля версий.

Version Control System (VCS) — система, записывающая изменения файла или набора файлов в течение большого периода времени, так чтобы была возможность позже вернуться к определенной версии.

Классификация СКВ:

  1. Локальные
  2. Централизованные
  3. Распределенные

С локальными СКВ мы уже разобрались (это те самые кучи одинаковых файлов)

Централизованные СКВ


  • центральный сервер
    все файлы под версионным контролем
  • ряд клиентов
    получают копии файлов

Примеры:

Распределенные СКВ


  1. Клиенты полностью копируют весь репозиторий
  2. Центральный сервер отвечает за предоставление основной копии
  3. Синхронизация может быть
    • С сервером
    • С любым клиентом


Примеры:

Зачем нужна СКВ


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

GIT


Git — распределённая система контроля версий
Автор: Линус Торвальдс
2005 — первая версия

Установка:
Linux: sudo apt install git
Windows/macOS: ссылка

Используют разработчики:

  • GNU/Linux
  • Android
  • Wine
  • Google
  • Chromium
  • jQuery
  • PHP
  • MediaWiki
  • Qt

Базовые понятия


Репозиторий (repository, repo) — место, где СКВ хранит свои метаданные и базу данных объектов проекта
Рабочий каталог (working directory) — извлечённая из репозитория копия определённой версии проекта
Область подготовленных файлов (staged area) — служебный файл, содержащий информацию о том, что должно войти в следующую ревизию проекта
Ревизия (revision) — объект, хранящий изменение состояния проекта (версия проекта)
Коммит (commit) — создание новой ревизии

Настройка конфигурации GIT


Настройка имени пользователя
git config --global user.name "Your Name" git config --global user.email [email protected] 

Настройки сохраняются в скрытый файл .gitconfig (в домашней директории пользователя)
[user] name = John Doe email = [email protected] 

Создание репозитория
mkdir first_git_repo cd first_git_repo git init 

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


  1. Зафиксированный
    файл уже есть в репозитории
  2. Измененный
    файл отличается по содержанию от своего зафиксированного состояния
  3. Подготовленный
    измененный файл, который станет зафиксированным после создания новой ревизии (этот файл попадет в эту ревизию)

Работа с кодом



  1. Изменение в коде проекте: создание / удаление / редактирование файлов
    В любой IDE
  2. Просмотр состояния
    git status
  3. Добавление измененных файлов в индекс
    (перевод в состояние Staged)
    git add имена_файлов_через_пробел
  4. Создание ревизии (из Staged в Repo)
    git commit -m "Комментарий"

Суммируем


Работа с СКВ


Что хранить?

[+] Все файлы исходного кода
[+] Все ресурсы, необходимые для компиляции
[+] настройки компиляции проекта
[-] настройки проекта в IDE
[-] файлы, компилируемые из исходников
[-] исполняемые файлы

Удаление из индекса

git rm имя_файла

Коммит может содержать изменения нескольких файлов

Когда делать коммит?

  • Когда завершил маленьшую задачку
  • Если задачка большая — делим на логические подчасти
  • Код должен быть в рабочем состоянии!

Просмотр истории
git log git log --graph

Номер ревизии = SHA-1 хэш изменений

Переключение на ревизию

git checkout sha1_hash git checkout первые_8_цифр_sha1

Ветки


Ветка (англ. branch) — это последовательность коммитов, в которой ведётся параллельная разработка какого-либо функционала

Основная ветка – master

Ветки в GIT

Показать все ветки, существующие в репозитарии

git branch

Создать ветку

git branch имя

Переключиться на ветку

git checkout имя
На этот момент не должно быть несохранённых изменений

Создать ветку и переключиться на неё

git checkout -b имя

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

Объединение веток (англ. merge) — процесс интеграции изменений (коммитов) одной ветки в другую:

b1 — ветка, в которую мы добавляем изменения
b2 — ветка из которой мы добавляем изменения

git checkout b1 git merge b2

Просмотр истории


Оконные утилиты:
Удаление веток

Удалить ветку

git branch –d имя_ветки

УДАЛИТЬ ветку

git branch –D имя_ветки

А точнее, удалить ветку, не дожидаясь перемещения коммитов в master

Буфер несохраненных изменений


Или «что делать, если нужно переключиться на другую ветку, а коммит делать рано?»

Записать изменения во временный буфер

git stash

Извлечь из буфера эти изменения

git stash pop

Полезные ссылки:

git-scm.com/book/ru/v2
githowto.com/ru
ru.wikipedia.org/wiki/Система_управления_версиями

Командная разработка


Итак, если ты добрался до этой строчки, то значит ты хотя бы чуть-чуть разобрался с git’ом (очень на это надеюсь). Но что же насчет командной разработки? Давай рассмотрим этот вопрос поподробнее.

Небольшая юмористическая задачка:

Дано:

  • N разработчиков
  • Рабочие места
  • Техническое задание (ТЗ)
  • Интернет

Вопрос:
  • Как выполнить проект не привлекая внимание санитаров?

Ответ:
  • Слаженная команда и упорный труд

Хм, а что же такое вообще команда? Что она из себя представляет?

Команда – это небольшое количество людей:

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

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

Так-с, теперь тебе понятно, что такое команда. Но следующий вопрос, который возникает в твоей голове (да, да, авторы данной статьи умеют читать мысли): «А кто за что отвечает в команде? У каждого «есть свое место»? Или все делают, что захотят?».

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

  1. Team Leader:

    Team Leader — это нечто среднее между проектным менеджером и квалифицированным девелопером.

    На проектах есть две lead роли: менеджерская — PM, и техническая — System Architect. Тимлид отчасти выполняет обе роли, но акцент его обязанностей направлен на менеджмент (акцент на техническую часть — это tech lead).

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

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

    Под техническую роль: участие в написании технической документации, выбор технологий для проекта, разработка архитектуры, R&D, code review, менторинг джуниоров, проведение технических собеседований, грамотное вовлечение новых членов команды в рабочий процесс, ответственность за техническую часть проекта.

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

    • рассмотрение новых задач и их распределение
    • стендап с командой
    • митинги
    • программирование
    • архитектурные вопросы
    • code review
  2. Project manager:

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

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

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

    «Главная постановка задачи для PM’а: „Нам нужно, чтобы это работало“, что подразумевает, что команда предоставит результат в разумные сроки с разумным уровнем качества».

  3. Тестировщик:

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

    Главные должностные обязанности тестировщика:

    • Контроль качества разрабатываемых продуктов.
    • Выявление и анализ ошибок и проблем, возникающих у пользователей при работе с программными продуктами.
    • Разработка автотестов и их регулярный прогон.
    • Разработка сценариев тестирования.
    • Документирование найденных дефектов.
  4. Разработчики:
    • Junior:
      Junior – разработчик начального уровня.

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

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

    • Middle:

      Middle – разработчик среднего уровня.

      Основное требование к мидл-разработчику — способность самостоятельно выполнять поставленные перед ним задачи. Очень похоже на то, что было написано в предыдущем пункте, правда? Однако есть важный нюанс — здесь отсутствует слово «технические». То есть на новом уровне нужно понимать требования бизнеса и уметь переводить их в технические решения.

      Таким образом:

      1. Мидл-разработчик понимает, что именно делает приложение. Это позволяет глубже понять задачу, а, значит, точнее ее оценить и качественнее реализовать. Если требования не полностью покрывают какой-то сценарий, хороший разработчик обратит на это внимание на этапе планирования. А не когда приложение начнет валиться при любом нестандартном действии пользователя.
      2. Мидл-разработчик знаком со стандартными шаблонами и решениями при построении приложения в своей области, понимает, зачем они нужны, и умеет их применять. Стандартизация решений имеет большое значение при коллективной разработке кода, т. к. позволяет новому человеку быстрее разобраться, что к чему, и минимизирует количество ошибок. Понимание структуры типового приложения делает задачу его построения с нуля достаточно тривиальной, позволяет рассуждать о принципах правильной реализации и отличать хороший код от плохого.
      3. Мидл-разработчик понимает, что работает не один. Он умеет взаимодействовать с другими членами команды: может обсудить сложный момент с дизайнером, уточнить у бизнес-аналитика неполные требования или согласовать какое-то важное техническое решение с архитектором проекта (если такой есть) и, конечно, владеет соответствующими инструментами коллективной разработки.
    • Senior:

      Senior – разработчик высокого уровня, повидавший много кода, набивший кучу шишек и сумевший сделать из этого правильные выводы. Основная задача синьора — принимать правильные технологические решения в проекте. «Правильные» — это такие, которые приносят максимальную пользу бизнесу и минимизируют затраты. Хороший синьор не только понимает, что разрабатывает команда, но думает, какие задачи должно решить готовое приложение. Разрабатывая площадку для аукциона, синьор всегда задается вопросом о пиковой нагрузке и старается предусмотреть попытки конкурентной записи в таблицы БД. Он заранее думает об узких местах системы, о возможности ее масштабирования, помнит об уязвимостях и проблемах, вызванных неправильным использованием инструментов.

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

  5. Дизайнер:

    Дизайнер – тот человек, который занимается дизайном. Логично, не правда ли?

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

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

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

    • Понимание проблемы:

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

    • Поиск решения:

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

    • Оформление:

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

    • Согласование:

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


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

Заключение


Чтож, если ты дочитал до этого момента – поздравляю, ты нереально крут! Нет, ну правда, у тебя мозг еще не вскипел от такого количества информации? Надеюсь, что нет.

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

Спасибо за внимание!

P.S.


Статья подготовлена учениками МШП (Московская школа программистов), по материалам лекций курса «Промышленное Программирование».

habr.com

Git — Википедия

Git
Тип распределённая система управления версиями[d][4]
Разработчик Software Freedom Conservancy[1]
Написана на Си[5], командная оболочка UNIX, Perl, Tcl, Python и C++
Операционная система кроссплатформенность
Языки интерфейса английский
Первый выпуск 7 апреля 2005[2]
Последняя версия
Читаемые форматы файлов git packfile[d][6], git packfile index, version 1[d][6] и git packfile index, version 2[d][6]
Создаваемые форматы файлов git packfile[d][6], git packfile index, version 1[d][6] и git packfile index, version 2[d][6]
Лицензия GNU GPL 2[7]
Сайт git-scm.com​ (англ.)
 Медиафайлы на Викискладе
Не следует путать с GitHub — веб-сайтом для размещения git-репозиториев и совместной разработки проектов.

Git (произносится «гит»[8]) — распределённая система управления версиями. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux, первая версия выпущена 7 апреля 2005 года. На сегодняшний день его поддерживает Джунио Хамано.

Среди проектов, использующих Git — ядро Linux, Swift, Android, Drupal, Cairo, GNU Core Utilities, Mesa, Wine, Chromium, Compiz Fusion, FlightGear, jQuery, PHP, NASM, MediaWiki, DokuWiki, Qt, ряд дистрибутивов Linux.

Программа является свободной и выпущена под лицензией GNU GPL версии 2. По умолчанию используется TCP порт 9418.

Разработка ядра Linux велась на проприетарной системе BitKeeper[9], которую автор, — Ларри Маквой, сам разработчик Linux, — предоставил проекту по бесплатной лицензии. Разработчики, высококлассные программисты, написали несколько утилит, и для одной Эндрю Триджелл произвёл реверс-инжиниринг формата передачи данных BitKeeper. В ответ Маквой обвинил разработчиков в нарушении соглашения и отозвал лицензию, и Торвальдс взялся за новую систему: ни одна из открытых систем не позволяла тысячам программистов кооперировать свои усилия (тот же конфликт привёл к написанию Mercurial). Идеология была проста: взять подход CVS и перевернуть с ног на голову[10], и заодно добавить надёжности.

Начальная разработка велась меньше, чем неделю: 3 апреля 2005 года разработка началась, и уже 7 апреля код Git управлялся неготовой системой. 16 июня Linux был переведён на Git, а 25 июля Торвальдс отказался от обязанностей ведущего разработчика.

Торвальдс так саркастически отозвался о выбранном им названии git (что на английском сленге означает «мерзавец»):

I'm an egotistical bastard, so I name all my projects after myself. First Linux, now git. Я эгоистичный ублюдок, и поэтому называю все свои проекты в честь себя. Сначала Linux, теперь git.

История версий[править | править код]

Версия Первоначальная дата выпуска Последняя версия Дата выпуска
Старая версия, не поддерживается: 0.99 2005-07-11 0.99.9n 2005-12-15
Старая версия, не поддерживается: 1.0 2005-12-21 1.0.13 2006-01-27
Старая версия, не поддерживается: 1.1 2006-01-08 1.1.6 2006-01-30
Старая версия, не поддерживается: 1.2 2006-02-12 1.2.6 2006-04-08
Старая версия, не поддерживается: 1.3 2006-04-18 1.3.3 2006-05-16
Старая версия, не поддерживается: 1.4 2006-06-10 1.4.4.5 2008-07-16
Старая версия, не поддерживается: 1.5 2007-02-14 1.5.6.6 2008-12-17
Старая версия, не поддерживается: 1.6 2008-08-17 1.6.6.3 2010-12-15
Старая версия, не поддерживается: 1.7 2010-02-13 1.7.12.4 2012-10-17
Старая версия, не поддерживается: 1.8 2012-10-21 1.8.5.6 2014-12-17
Старая версия, не поддерживается: 1.9 2014-02-14 1.9.5 2014-12-17
Старая версия, не поддерживается: 2.0 2014-05-28 2.0.5 2014-12-17
Старая версия, не поддерживается: 2.1 2014-08-16 2.1.4 2014-12-17
Старая версия, не поддерживается: 2.2 2014-11-26 2.2.3 2015-09-04
Старая версия, не поддерживается: 2.3 2015-02-05 2.3.10 2015-09-29
Старая версия, не поддерживается: 2.4 2015-04-30 2.4.12 2017-05-05
Старая версия, не поддерживается: 2.5 2015-07-27 2.5.6 2017-05-05
Старая версия, не поддерживается: 2.6 2015-09-28 2.6.7 2017-05-05
Старая версия, не поддерживается: 2.7 2015-10-04 2.7.6 2017-08-10
Старая версия, не поддерживается: 2.8 2016-03-28 2.8.6 2017-08-10
Старая версия, не поддерживается: 2.9 2016-06-13 2.9.5 2017-08-10
Старая версия, не поддерживается: 2.10 2016-09-02 2.10.5 2017-09-26
Старая версия, не поддерживается: 2.11 2016-11-29 2.11.4 2017-09-26
Старая версия, не поддерживается: 2.12 2017-02-24 2.12.5 2017-09-26
Старая версия, не поддерживается: 2.13 2017-05-10 2.13.7 2018-05-29
Старая версия, не поддерживается: 2.14 2017-08-04 2.14.4 2018-05-29
Старая версия, не поддерживается: 2.15 2017-10-30 2.15.2 2018-05-29
Старая версия, не поддерживается: 2.16 2018-01-17 2.16.4 2018-05-29
Старая версия, не поддерживается: 2.17 2018-04-03 2.17.1 2018-05-29
Старая версия, не поддерживается: 2.18 2018-06-21 2.18.1 2018-09-27
Старая версия, не поддерживается: 2.19 2018-09-10 2.19.2 2018-11-21
Старая версия, не поддерживается: 2.20 2018-12-09 2.20.2 2019-12-07
Старая версия, не поддерживается: 2.21 2019-02-24 2.21.1 2019-12-07
Старая поддерживаемая версия: 2.22 2019-06-07 2.22.2 2019-12-07
Старая поддерживаемая версия: 2.23 2019-08-16 2.23.1 2019-12-07
Старая поддерживаемая версия: 2.24 2019-11-04 2.24.1 2019-12-07
Текущая версия: 2.25 2020-01-13 2.25.0 2020-01-13

Легенда:

Старая версия, не поддерживается

Старая поддерживаемая версия

Текущая версия

Тестовая версия

Будущая версия

Система спроектирована как набор программ, специально разработанных с учётом их использования в сценариях. Это позволяет удобно создавать специализированные системы контроля версий на базе Git или пользовательские интерфейсы. Например, Cogito является именно таким примером оболочки к репозиториям Git, а StGit использует Git для управления коллекцией исправлений (патчей).

Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки. Как и Darcs, BitKeeper, Mercurial, Bazaar и Monotone[en], Git предоставляет каждому разработчику локальную копию всей истории разработки, изменения копируются из одного репозитория в другой.

Удалённый доступ к репозиториям Git обеспечивается git-демоном, SSH- или HTTP-сервером. TCP-сервис git-daemon входит в дистрибутив Git и является наряду с SSH наиболее распространённым и надёжным методом доступа. Метод доступа по HTTP, несмотря на ряд ограничений, очень популярен в контролируемых сетях, потому что позволяет использовать существующие конфигурации сетевых фильтров.

Ядро Git представляет собой набор утилит командной строки с параметрами. Все настройки хранятся в текстовых файлах конфигурации. Такая реализация делает Git легко портируемым на любую платформу и даёт возможность легко интегрировать Git в другие системы (в частности, создавать графические git-клиенты с любым желаемым интерфейсом).

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

По умолчанию репозиторий хранится в подкаталоге с названием «.git» в корневом каталоге рабочей копии дерева файлов, хранящегося в репозитории. Любое файловое дерево в системе можно превратить в репозиторий git, отдав команду создания репозитория из корневого каталога этого дерева (или указав корневой каталог в параметрах программы). Репозиторий может быть импортирован с другого узла, доступного по сети. При импорте нового репозитория автоматически создаётся рабочая копия, соответствующая последнему зафиксированному состоянию импортируемого репозитория (то есть не копируются изменения в рабочей копии исходного узла, для которых на том узле не была выполнена команда commit).

Нижний уровень git является так называемой контентно-адресуемой файловой системой. Инструмент командной строки git содержит ряд команд по непосредственной манипуляции этим репозиторием на низком уровне. Эти команды не нужны при нормальной работе с git как с системой контроля версий, но нужны для реализации сложных операций (ремонт повреждённого репозитория и так далее), а также дают возможность создать на базе репозитория git своё приложение.

Для каждого объекта в репозитории вычисляется SHA-1-хеш, и именно он становится именем файла, содержащего данный объект в каталоге .git/objects. Для оптимизации работы с файловыми системами, не использующими деревья для каталогов, первый байт хеша становится именем подкаталога, а остальные — именем файла в нём, что снижает количество файлов в одном каталоге (ограничивающий фактор производительности на таких устаревших файловых системах).

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

Кроме того, в репозитории существует каталог refs, который позволяет задать читаемые человеком имена для каких-то объектов Git. В командах Git оба вида ссылок — читаемые человеком из refs, и нижележащие SHA-1 — полностью взаимозаменяемы.

В классическом обычном сценарии в репозитории git есть три типа объектов — файл, дерево и «коммит» (англ. commit — фиксация). Файл есть какая-то версия какого-то пользовательского файла, дерево — совокупность файлов из разных подкаталогов, «коммит» — дерево и некая дополнительная информация (например, родительские коммиты, а также комментарий).

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

Репозиторий Git бывает локальный и удалённый. Локальный репозиторий — это подкаталог .git, создаётся (в пустом виде) командой git init и (в непустом виде с немедленным копированием содержимого родительского удалённого репозитория и простановкой ссылки на родителя) командой git clone.

Практически все обычные операции с системой контроля версий, такие, как коммит и слияние, производятся только с локальным репозиторием. Удалённый репозиторий можно только синхронизировать с локальным как «вверх» (push), так и «вниз» (pull).

Наличие полностью всего репозитория проекта локально у каждого разработчика даёт Git ряд преимуществ перед SVN. Так, например, все операции, кроме push и pull, можно осуществлять без наличия интернет-соединения.

Очень мощной возможностью git являются ветви, реализованные куда более полно, чем в SVN: по сути, ветвь git есть не более чем именованная ссылка, указывающая на некий коммит в репозитории (используется подкаталог refs). Коммит без создания новой ветви всего лишь передвигает эту ссылку на себя, а коммит с созданием ветви — оставляет старую ссылку на месте, но создаёт новую на новый коммит, и объявляет её текущей. Заменить локальные девелоперские файлы на набор файлов из иной ветви, тем самым перейдя к работе с ней — так же тривиально.

Также поддерживаются субрепозитории с синхронизацией текущих ветвей в них.

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

Команда pull — обратна команде push. В случае, если одна и та же ветвь имеет независимую историю в локальной и в удалённой копии, pull немедленно переходит к слиянию.

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

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

Кроме слияния, Git поддерживает ещё операцию перемещения (англ. rebase). Эта операция есть получение набора всех изменений в ветви А, с последующим их «накатом» на ветвь B. В результате ветвь B продвигается до состояния AB. В отличие от слияния, в истории ветви AB не останется никаких промежуточных коммитов ветви A (только история ветви B и запись о самом rebase, это упрощает интеграцию крупных и очень крупных проектов).

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

Имя ветви по умолчанию: master. Имя удалённого репозитория по умолчанию, создаваемое git clone во время типичной операции «взять имеющийся проект с сервера себе на машину»: origin.

Таким образом, в локальном репозитории всегда есть ветвь master, которая есть последний локальный коммит, и ветвь origin/master, которая есть последнее состояние удалённого репозитория на момент завершения исполнения последней команды pull или push.

Команда fetch (частичный pull) — берёт с удалённого сервера все изменения в origin/master, и переписывает их в локальный репозиторий, продвигая метку origin/master.

Если после этого master и origin/master разошлись в стороны, то необходимо сделать слияние, установив master на результат слияния (команда pull есть fetch+merge). Далее возможно сделать push, отправив результат слияния на сервер и установив на него origin/master.

В Windows-версии (официальная Windows-версия называется mSysGit) используется пакет mSys — порт POSIX-совместимой командной строки под Windows из проекта MinGW. Под mSys перенесены все необходимые для Git библиотеки и инструменты, а также сам Git. При работе с удалёнными репозиториями по протоколу SSL используется хранилище сертификатов из mSys, а не из Windows.

Существует немало графических оболочек для Git для Windows, например, TortoiseGit. Все они реализованы через вызовы mSysGit и требуют его установки на машину. Не исключение и SourceTree, решение компании Atlassian, но mSysGit оно содержит внутри себя, что имеет свои плюсы и минусы (так установка в глубокий подкаталог затрудняет добавление в mSys нужных SSL-сертификатов).

Поскольку в Windows используется отличный от большинства Unix-подобных систем символ конца строки, для работы коллективов, использующих разные операционные системы, предусматриваются параметры (как для клиентов, так и уровня репозитория), обеспечивающие унифицированное представление конца строки.

Сетевые возможности и серверные решения[править | править код]

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

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

  • git-протокол (схема URI — git:) — открытый протокол[13], требующий наличия на сервере запущенного git-демона[14] (поставляется вместе с Git), протокол не имеет средств аутентификации пользователей;
  • SSH (ssh:) — использует аутентификацию пользователей с помощью пар ключей, а также встроенный в Unix-систему «основной» SSH-сервер (sshd), со стороны сервера требуется создание учётных записей с git в качестве оболочки;
  • HTTP и HTTPS (http:, https:) — использует инструмент curl (для Windows — поставляется вместе с git), и его возможности HTTP-аутентификации, как и его поддержку SSL и сертификатов.

В последнем случае требуется работа на серверной стороне веб-приложения, исполняющего роль прослойки между командами Git на сервере и HTTP-сервером (среди таковых WebGitNet, разработанный на ASP.NET MVC 4). Кроме поддержки серверной стороны команд push и pull, такие веб-приложения могут также давать доступ только на чтение к репозиторию через веб-браузер.

Разработано множество графических интерфейсов для системы, среди них — GitKraken (кроссплатформенный условно бесплатный клиент Git), SmartGit (кроссплатформенный интерфейс на Java), gitk (простая и быстрая программа, написана на Tcl/Tk, распространяемая с самим Git), Giggle (вариант на Gtk+), TortoiseGit (интерфейс, реализованный как расширение для проводника Windows), SourceTree (бесплатный Git-клиент для Windows и Mac), Github-клиент и ряд других.

Кроме того, разработано множество веб-фронтендов, в числе которых GitWebAdmin, GitLab, Gitblit, Gerrit, Gitweb, Kallithea, Gitea.

Ряд сервисов предоставляют хостинг для git-репозиториев, среди наиболее известных — GitHub, Codebase, SourceForge, Gitorious, Bitbucket, GitLab.

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

В стандартной поставке Git поддерживается взаимодействие с CVS (импорт и экспорт, эмуляция CVS-сервера) и Subversion (частичная поддержка импорта и экспорта). Стандартный инструмент импорта и экспорта внутри экосистемы — архивы серий версионированных файлов в форматах .tar.gz и .tar.bz2.

  • Чакон С., Штрауб Б. Git для профессионального программиста. — Питер, 2017. — 496 с. — ISBN 978-5-496-01763-3.

ru.wikipedia.org

Git на практике / Habr

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

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

Для начала давайте разберемся с тем что такое ветка и коммит.

Коммит


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

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

Git это распределенная система управления версиями. Это значит, что у каждого участника проекта есть своя копия репозитория, которая находиться в папке “.git”, которая расположена в корне проекта. Именно в этой папке хранятся все коммиты и другие объекты Git. Когда вы работаете с Git, он в свою очередь работает с этой папкой.

Завести новый репозиторий очень просто, это делается командой

git init

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

git clone <url удаленного репозитория>

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

Существует несколько основных областей в которых находиться код.

  • Рабочая директория – это файлы в корне проекта, тот код с которым вы работаете.
  • Локальный репозиторий — она же директория “.git”. В ней хранятся коммиты и другие объекты.
  • Удаленный репозиторий – тот самый репозиторий который считается общим, в который вы можете передать свои коммиты из локального репозитория, что бы остальные программисты могли их увидеть. Удаленных репозиториев может быть несколько, но обычно он бывает один.
  • Есть еще одна область, с пониманием которой обычно бывают проблемы. Это так называемая область подготовленных изменений (staging area). Дело в том, что перед тем как включить какие-то изменения в коммит, нужно вначале отметить что именно вы хотите включить в этот коммит. В своей рабочей директории вы можете изменить несколько файлов, но в один конкретный коммит включать не все эти изменения.

В целом работа с гитом выглядит так: вы меняете файлы в своей рабочей директории, затем добавляете эти изменения в staging area используя команду

git add <имя/файла>

При этом можно использовать маски со звездочкой.
Потом вы делаете коммит в свой локальный репозиторий

git commit –m “Комментарий к коммиту”

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

git push

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

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

git pull

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

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

Просмотреть коммиты можно при помощи команды

git log

Формат ответа этой команды по дефолту не очень удобен. Вот такая команда выведет ответ в более читаемом виде

git log --pretty=format:"%H [%cd]: %an - %s" --graph --date=format:%c

Что бы закончить просмотр нужно нажать на клавишу q
Посмотреть, что находиться в рабочей директории и staging area можно командой

git status

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

git checkout <hash коммита>

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

Ветка


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

Сделать новую ветку и переключиться на нее можно выполнив команды

git pull
git checkout –b <имя новой ветки>

Просто сделать ветку, не переключаясь на нее можно командой

git branch <имя ветки>

переключиться на ветку

git checkout <имя ветки>

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

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

Существует другая ситуация при объединении веток, в которой merge может произойти без merge commit. Дело в том, что если в одной из веток не произошло никаких изменений, то необходимость в merge commit с двумя предками отпадает. В таком случае, при слиянии веток, Git просто сделает пометку о том, что дальше будут идти коммиты той ветки с которой эта ветка была объединена. Такая схема merge называется слияние-перемотка (fast-forward merge), визуально это можно представить вот так.

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

git checkout <имя ветки>

Потом получить последние изменения сделанные в этой ветке выполнив

git pull

Затем выполнить команду

git merge <имя ветки>

Так выглядит работа с ветками в общих чертах.

Обратите внимание на то, что перед тем как заводить новую ветку нужно выполнить git pull. Делается это по нескольким причинам.

  • Другой программист мог изменить код, в том числе внести такие изменения, которые повлияют на решение задачи, для которой вы заводите новую ветку. Эти изменения могут вам пригодиться при решении своей задачи.
  • Из-за этих изменений вы можете получить конфликт при мерже.
  • Больше шанс что у вас получится merge commit. Это не так плохо, как два предыдущих пункта. Но если можно избежать лишнего коммита, то почему бы этого не сделать?

Популярные схемы работы с ветками в Git

Теперь можно описать популярные схемы работы с ветками в гите.

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

Классическая схема работы с ветками


Обычно перед тем как взяться за решение какой-то задачи, программист заводит новую ветку от последнего рабочего коммита мастер ветки и решает задачу в этой новой ветке. В ходе решения он делает ряд коммитов, после этого тестирует код непосредственно в ветке задачи. А после того как задача решена, делают merge обратно в мастер ветку. Такую схему работы часто используют с юнит тестами и автоматизированным деплоем. Если юнит тесты будут покрывать весь код, то можно настроить деплой так, что вначале будут прогоняться все тесты в ветке задачи. А после этого, если они прошли успешно, будет происходить merge и деплой. При такой схеме можно добиться полной автоматизации при тестировании и деплои.

Именная ветка


Неопытные программисты заводят себе именную ветку и работают всегда в ней. Они решают по одной задачи за раз, и когда заканчивают решение одной из задач, делают новый Pull запрос через Web интерфейсе (об этом чуть ниже). Недостаток этого подхода в том, что так можно решать только одну задачу и нельзя быстро переключиться на решение другой задачи. Еще один недостаток в том, что ветки так со временем будут все сильнее расходиться и код в ветке программиста рано или поздно устареет относительно мастер ветки и его придется обновить. Для этого можно либо смержить мастер ветку в ветку программиста, либо завести новую ветку для этого программиста от последнего рабочего состояния в мастер ветке. Правда к тому времени, как это произойдет программист уже может освоить гит в достаточной мере что бы перейти на “классическую” схему работы. Таким образом эта схема имеет место быть для неопытных пользователей Git.

Схема с dev веткой


Другая схема очень похожа на классическую, только в ней помимо мастер ветки есть еще девелоперская ветка, которая деплоится на тестовый сервер. Такую ветку обычно называют dev. Схема работы при этом такая. Программист перед выполнением новой задачи заводит для нее ветку от последнего рабочего состояния в мастер ветке. Когда он заканчивает работу над задачей, то мержит ветку задачи в dev ветку самостоятельно. После этого, совместными усилиями задача тестируется на тестовом сервере вместе с остальными задачами. Если есть ошибки, то задачу дорабатывают в той же ветке и повторно мержат с dev веткой. Когда тестирование задачи заканчивается, то ВЕТКУ ЗАДАЧИ мержат с мастер веткой. Важно заметить, что в этой схеме работы с мастер веткой нужно мержить ветку задачи, а не dev ветку. Ведь в dev ветке будут содержаться изменения, сделанные не только в этой задаче, но и в других и не все эти изменения могут оказаться рабочими. Мастер ветка и dev ветка со временем будут расходиться, поэтому при такой схеме работы периодически заводят новую dev ветку от последнего рабочего состояния мастер ветки. Недостатком этого подхода является избыточность, по сравнению с классической схемой. Такую схему работы с ветками часто используют если в проекте нет автоматизированных тестов и все тестирование происходит вручную на сервере разработки.

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

Pull запросы


С этим понятием имеется путаница. Дело в том, что в Git есть две совершенно разные вещи, которые можно назвать Pull запросом. Одна из них, это консольная команда git pull. Другая это кнопка в web интерфейсе репозитория. На github.com она выглядит вот так

Про эту кнопку и пойдет речь дальше.

Если программист достаточно опытный и ответственный, то он обычно сам сливает свой код в мастер ветку. В противном случае программист делает так называемый Pull запрос. Pull запрос это по сути дела запрос на разрешение сделать merge. Pull запрос можно сделать из web интерфейса Git, или при помощи команды git request-pull. После того как Pull запрос создан, остальные участники могут увидеть это, просмотреть тот код который программист предлагает внести в проект, и либо одобрить этот код либо нет. Merge через pull запросы имеет свои плюсы и минусы. Минус в том, что для тесной команды опытных программистов такой подход будет лишним. Это будет только тормозить работу и вносить в нее оттенки бюрократии.

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

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

Конфликты


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

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

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

git tag -a v1.0

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

git push –tags

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

git checkout <имя тега>

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

Если вы будете придерживаться этих правил и “классической” схемы работы с ветками, то вам будет проще интегрировать ваш Git с другими системами. Например, с системой непрерывной интеграции или с репозиторием пакетов, таким как packagist.org. Обычно сторонние решения и всякие расширения рассчитаны именно на такую схему работы с гитом, и если вы сразу начнете делать все правильно, то это может стать большим плюсом для вас в дальнейшем.

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

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

habr.com

Первый коммит в Github / Sandbox / Habr

Руководство по созданию первого коммита в свой репозиторий на Github


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

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

Основы


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

Git — это инструмент, позволяющий реализовать распределённую систему контроля версий.

GitHub — это сервис для проектов, использующих Git.

Создать коммит (commit) значит зафиксировать изменения любых файлов, входящих в репозиторий.

Репозиторий — каталог файловой системы, в котором могут находится: файлы журналов конфигураций и операций, выполняемых над репозиторием, а также сами контролируемые файлы.

Репозиторий бывает:

  • локальный (расположен непосредственно в памяти компьютера разработчика, в нем происходит разработка и фиксация изменений, после чего можно отправить на удалённый репозиторий)
  • удалённый (находится на сервере, может быть приватным – доступным ограниченному числу лиц, и публичным – open source)

В GitHub входит:
  • система контроля доступа
  • багтрекинг (отслеживание истории действий над файлами и, при необходимости, переход на более ранние версии)
  • возможность управлять задачами и справками для проектов

К проекту, загруженному на GitHub, можно получить доступ с помощью интерфейса командной строки и Git-команд, сайта https://github.com/, или с помощью приложения Github — desktop для Windows или macOS.

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

Установка Git


Для Linux:

1. Откройте терминал и перейдите в желаемую директорию для установки.
2. Введите: sudo apt-get install git
Для macOS:

1. Воспользуемся homebrew
2. Вводим в терминале: brew install git
Для Windows, (для macOS и Linux — альтернатива):

1. Перейдите по ссылке: http://git-scm.com/downloads
2. Выберите нужный пакет и следуйте дальнейшим инструкциям.

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

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


1. Открываем Bash

Пусть наш проект имеет путь в файловой системе Users/Public/Project. Перед созданием локального репозитория желательно удалить все ненужные, временные файлы в папке проекта.

2. Настроим имя пользователя и адрес электронной почты:

git config --global user.name "Name" git config --global user.email [email protected]

(где Name – логин пользователя, [email protected] — почта)

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

tree – команда для просмотра древовидной структуры файловой системы, в которой мы находимся.

find – удаление файлов со специфичным суффиксом.

3. Переходим в папку с проектом Users/Public/Project:

cd Users/Public/Project/

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

Командная строка должна вернуть что-то вроде:
Initialized empty Git repository in Users/Public/Project/

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


1. Теперь создадим любой файл в нашей директории, например, first.txt

2. Добавим его в систему управления версиями:

git add first.txt

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

или:
git add --all

4. Проверить текущее состояние:
git status

Можно отменить добавление файла командой:
git rm –-cached first.txt

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


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

1. Введем команду:

git commit -m "comment"

Ключ –m означает создание пользователем описания этого коммита.

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

git clean -df

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


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

1. Регистрируемся на сайте: github.com под именем nikname (может быть любым другим).

2. Нажимаем кнопочку "+" и вводим название репозитория.

3. Выбираем тип Public (Private доступен только в платной версии).

4. Нажимаем Create.
В результате создан репозиторий в Github (на экране видим инструкцию, по соедининению локального репозитория со вновь созданным).

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

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

Результат можно увидеть с помощью команды:
git remote -v

Если все правильно сделано, то увидим:
origin [email protected]om:nikname/project.git (fetch) origin [email protected]:nikname/project.git (push)

Для отмены регистрации удаленного репозитария, введите:
git remote rm origin

Этой командой вносятся все изменения, которые были сделаны в локальном репозитории на Github:
git push -u github master

-u ключ установления связи между удаленным репозиторием github и веткой master. Все дальнейшие изменения переносятся на удаленный репозиторий следующей командой: git push
Полезные ресурсы

  • Более подробно про Git можно прочитать в книге Скотта Чакона и Бена Штрауба — Pro Git
  • За помощью с работой в Github переходим на сайт.

habr.com

Github: что это такое и как его использовать. Github

Github — это очень известная платформа для хранения, распространения и управления исходным кодом открытых проектов. Github использует множество разработчиков по всему миру, среди которых есть и крупные компании, такие как Microsoft, RedHat и другие.

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

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

GitHub Issues

GitHub Issues – одна из наиболее популярных в мире систем отслеживания багов.

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

Если вы найдете проблему в проекте, управляемом кем-то другим, она будет открытой до тех пор, пока вы не закроете ее (например, если выясните, в чем заключается проблема) или пока владелец репозитория не закроет ее.

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

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

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

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

Когда завершите ввод, нажмите кнопку «Sign Up Free.

Никакая настройка github не нужна, достаточно лишь несколько кликов мышкой.

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

Аккаунт готов, и вы будете перенаправлены на страницу, где сможете создать свой первый проект. Но перед тем как вы сможете это сделать, нужно подтвердить свой Email адрес. Для этого откройте ваш почтовый ящик и перейдите по ссылке в письме от Github. Сейчас у нас нет ни одного репозитория, и мы можем либо создать новый репозиторий, либо ответвиться (fork) от уже существующего чужого репозитория и вести собственную ветку разработки. Затем, при желании, свои изменения можно предложить автору исходного репозитория (Pull request).

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

На открывшейся странице, это главная страница для авторизованных пользователей, нажмите кнопку «Start a project»:

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

Вы можете сразу же инициализировать репозиторий, создав файл Readme, для этого нужно отметить галочку «Initialize this repository with a README» внизу страницы. Также можно выбрать лицензию:

Когда все будет готово, выберите «Create project», будет создан новый проект с файлом README, в котором находится описание и файлом лицензии.

Добавление веток

Ветки Github позволяют работать с несколькими версиями проекта одновременно. По умолчанию при создании репозитория создается ветка master, это основная рабочая ветка. Можно создать дополнительные ветки, например, для того, чтобы тестировать программное обеспечение перед тем, как оно будет опубликовано в ветке master. Таким образом, можно одновременно разрабатывать продукт и предоставлять пользователям стабильную версию. Также можно создавать отдельные ветки для версии программы для разных систем.

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

Сайт сам предложит вам создать новую ветку, выберите «Create branch». Сразу же после создания вы будете работать с только что созданной веткой.

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

Любые изменения файлов на Github делаются с помощью коммитов. Коммит выполняется путем внесения самих исправлений и описания этих исправлений. Это необходимо для того, чтобы вы знали что и когда вы меняли, а также позволяет легко отслеживать работу команды. Слово коммит можно перевести как «фиксировать». То есть мы можем внести изменения в несколько файлов, а затем их зафиксировать. Давайте для примера изменим файл README. Для этого найдите в в правой стороне панели кнопку с кисточкой и нажмите на нее:

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

После того как вы сделаете все что вам нужно, необходимо заполнить поле «Commit» внизу страницы. Кратко опишите что было изменено, а затем нажмите кнопку «Commit changes»:

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

Новый Github Desktop

Github выпустил обновленную версию Github Desktop — программы под Windows 7+ и OS X, которая дублирует функциональность сайта github.com, но при этом работает локально на компьютере разработчика.


Github Desktop упрощает многие действия в рабочем процессе и заменяет Github for Mac и Github for Windows на новый унифицированный интерфейс.

Ветви Github Desktop

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

Совместная работа

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

Прямо из программы отправляются и пул-реквесты.

Слияние и развертывание

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

Просмотр истории

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

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

Github командная строка

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

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

Управление проектами (Project management)

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

Одна из них – Projects. Это новый раздел, который очень редко используется. Это система «Канбан», которая помогает организовать баги и работу, которую необходимо выполнить.

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

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

Представив релизы, GitHub расширил функциональность тегов GIT.

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

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

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

Сравнение коммитов на GitHub

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

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

Webhooks и Services на GitHub

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

Webhooks

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

Когда происходит событие, GitHub отправляет запрос POST на URL, который мы говорим ему использовать.

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

Мы отправляем команду push к GitHub, он сообщает серверу об этом, и сервер извлекает данные.

Services

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

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

Можно настроить непрерывную интеграцию с помощью CircleCI.

Можно создать интеграцию Codeclimate, которая анализирует код и предоставляет отчет «Техническая задолженность» и покрытие тестирования.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

gitjournal.tech

зачем и когда их использовать / Habr

Часто у разработчиков возникает выбор между Merge (слияние) и Rebase (перемещение). В Гугле вы увидите разное мнение, многие советуют не использовать Rebase, так как это может вызвать серьезные проблемы. В статье я объясню, что такое слияние и перемещение, почему вы должны (или не должны) использовать их и как это сделать.

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

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

Git Merge

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

Плюсы:
  • простота;
  • сохраняет полную историю и хронологический порядок;
  • поддерживает контекст ветки.

Минусы:
  • история коммитов может быть заполнена (загрязнена) множеством коммитов;
  • отладка с использованием git bisect может стать сложнее.

Как это сделать

Слейте ветку master в ветку feature, используя команды checkout и merge.

$ git checkout feature $ git merge master (or) $ git merge master feature

Это создаст новый «Merge commit» в ветке feature, который содержит историю обеих веток.
Git Rebase

Rebase — еще один способ перенести изменения из одной ветки в другую. Rebase сжимает все изменения в один «патч». Затем он интегрирует патч в целевую ветку.

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

Плюсы:

  • Упрощает потенциально сложную историю
  • Упрощение манипуляций с единственным коммитом
  • Избежание слияния коммитов в занятых репозиториях и ветках
  • Очищает промежуточные коммиты, делая их одним коммитом, что полезно для DevOps команд

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

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

Как это сделать

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

$ git checkout feature $ git rebase master

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

Это позволяет изменять коммиты при их перемещении в новую ветку. Это лучше, чем автоматическое перемещение, поскольку обеспечивает полный контроль над историей коммитов. Как правило, используется для очистки истории до слияния ветки feature в master.
$ git checkout feature $ git rebase -i master

Это откроет редактор, перечислив все коммиты, которые будут перемещены.
pick 22d6d7c Commit message#1 pick 44e8a9b Commit message#2 pick 79f1d2h Commit message#3

Это точно определяет, как будет выглядеть ветка после выполнения перемещения. Упорядочивая объекты, вы можете сделать историю такой, как захотите. Вы можете использовать команды fixup, squash, edit, и так далее.



Какой из них использовать?

Так что же лучше? Что рекомендуют эксперты?

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

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

Что рекомендую я?

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

Преимущества Rebase:

  • Вы разрабатываете локально: если вы не делились своей работой с кем-либо еще. На данный момент вы должны предпочесть перемещение слиянию, чтобы сохранить свою историю в порядке. Если у вас есть личная вилка репозитория, которая не используется совместно с другими разработчиками, вы можете делать rebase даже после того, как переместились в свою ветку.
  • Ваш код готов к ревью: вы создали пулл реквест. Другие анализируют вашу работу и потенциально стягивают ее к своей вилке для локального ревью. На данный момент вы не должны перемещать свою работу. Вы должны создать коммит «переделать» и обновить ветку. Это помогает отслеживать запросы на пулл реквест и предотвращает случайную поломку истории.
  • Ревью сделано и готово к интеграции в целевую ветку. Поздравляем! Вы собираетесь удалить свою ветку feature. Учитывая, что с этого момента другие разработчики не будут fetch-merging эти изменения, это ваш шанс изменить вашу историю. На этом этапе вы можете переписать историю и сбросить оригинальные коммиты, и эти надоедливые «переделки» и «слияние» сливаются в небольшой набор целенаправленных коммитов. Создание явного слияния для этих коммитов является необязательным, но имеет значение. Он записывает, когда функция достигла master.

Теперь вы знаете хоть и незначительную, но разницу между Merge и Rebase. Уверен, вы примете правильное решение и будете использовать то, что подходит именно вам.

Не забывайте:

code = coffee + developer

habr.com

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

Короче говоря, это платформа для разработчиков программного обеспечения, основанная на GIT.

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

Почему GitHub?

Теперь вы знаете, что такое GitHub и наверняка задаетесь вопросам – зачем мне его использовать и как?

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

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

Со временем основные кодовые базы были перенесены из других систем контроля версий в GIT из-за его удобства. GitHub исторически находится в выгодном положении и прилагает много усилий для удовлетворения потребностей сообщества открытого исходного кода.

Сегодня, когда вы будете искать какую-либо библиотеку, вы в 99% случаев найдете ее на GitHub.

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

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

GitHub Issues

GitHub Issues – одна из наиболее популярных в мире систем отслеживания багов.

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

Если вы найдете проблему в проекте, управляемом кем-то другим, она будет открытой до тех пор, пока вы не закроете ее (например, если выясните, в чем заключается проблема) или пока владелец репозитория не закроет ее.

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

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

Социальное кодирование

Несколько лет назад в логотип GitHub входил слоган «социального кодирования».

Что это значит? Важен ли сейчас этот слоган? Конечно.

Подписки (Follow)

На GitHub можно подписаться на разработчика или репозиторий, зайдя в профиль пользователя и нажав «Подписаться» или нажав кнопку «Следить» в репозитории.

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

Звезды (Stars)

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

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

Крупные проекты могут иметь десятки тысяч звезд.

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

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

Ответвления (Fork)

Последний важный сетевой индикатор проекта — это количество ответвлений.

Это ключ к тому, как работает GitHub. Ответвление — это основа запроса на включение (PR), который является предложением об изменении. Человек может добавить ответвление к вашему репозиторию, внести некоторые изменения, а затем создать запрос на включение, чтобы попросить вас объединить эти изменения в исходник.

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

Чем популярнее, тем лучше

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

Запросы на включение (Pull requests)

В предыдущем разделе я объяснил, что такое запрос на включение (PR). Повторим: человек может добавить расширение к вашему репозиторию, внести некоторые изменения, а затем создать запрос на включение, чтобы попросить вас объединить эти изменения.

Проект может иметь сотни PR. Как правило, чем популярнее проект, тем больше PR. Например, в проекте React:

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

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

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

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

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

Управление проектами (Project management)

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

Одна из них – Projects. Это новый раздел, который очень редко используется. Это система «Канбан», которая помогает организовать баги и работу, которую необходимо выполнить.

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

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

Представив релизы, GitHub расширил функциональность тегов GIT.

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

Релиз GitHub построен на основе тегов GIT и представляет собой полную версию вашего кода, а также zip-файлы, заметки о выпуске и двоичные ресурсы, которые могут представить полностью рабочую версию конечного продукта кода.

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

Сравнение коммитов

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

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

GitHub позволяет вам делать это с compare view: просто добавьте /compare в конец имени репозитория.

Например: https://github.com/facebook/react/compare

На рисунке ниже я сравниваю последнюю версию React v15.x с последней версией v16.0.0-rc, доступной на момент написания этой статьи, чтобы увидеть, что изменилось.

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

Webhooks и Services

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

Webhooks

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

Когда происходит событие, GitHub отправляет запрос POST на URL, который мы говорим ему использовать.

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

Мы отправляем команду push к GitHub, GitHub сообщает серверу об этом, и сервер извлекает данные из GitHub.

Services

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

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

Можно настроить непрерывную интеграцию с помощью CircleCI.

Можно создать интеграцию Codeclimate, которая анализирует код и предоставляет отчет «Техническая задолженность» и покрытие тестирования.

Заключение

GitHub — это замечательный инструмент и сервис, которым можно воспользоваться. Это настоящий драгоценный камень в современном наборе инструментов для разработчиков. Данное руководство поможет вам начать работу. Реальный опыт управления проектами с открытым или закрытым исходным кодом GitHub (как пользоваться им, показано во многих статьях) — это то, что нельзя упустить.

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

Новая версия github:gist / Habr

Команда Github продолжает радовать своими обновлениями, и на этот раз они приглашают нас попробовать полностью обновленный github:gist.

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

Gist успел стать незаменимым инструментом в арсенале Open Source сообщества. Например, таким простым образом распространяется перформанс-патч для руби, упомянутый недавно на хабре.

Что нового?

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

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

Discover Gists

Стало проще бродить, по гистам, изучать их и искать необходимые. Приятно, что из выдачи вывалились дубликаты, а сама поисковая система переняла удобство своего большого брата, которое, впрочем и у самого гитхаба все еще переживает различные трансформации. Но, как справедливо было замечено, на дворе 21 век, а к пагинатору еще не прикрутили подгрузку результатов аяксом.
Редактор Ace

Теперь Gist использует Ace. Выбор так же навеян недавними изменениями у большого брата. Ace — это очень приятный, встраиваемый в браузер Open Source редактор кода. Его используют такие компании как Firefox, Codecademy и Cloud9 IDE. Реализована поддержка drag'n'drop.

Я бы не отказался использовать его на хабре, кстати.

История гиста

Процесс просмотра истории отдельно взятого гиста стал простым и понятным. Есть нормальный diff, полная история изменений, список форков (хотя он и был раньше, но все же подвергся редизайну).
Форки

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

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

Добро пожаловать в новый Gist!

habr.com


Смотрите также