Как пользоваться github с нуля – Как начать работать с GitHub: быстрый старт / Habr

Как начать работать с 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

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

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

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

Содержание статьи:

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

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

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

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

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

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

Аккаунт готов, и вы будете перенаправлены на страницу, где сможете создать свой первый проект. Но перед тем как вы сможете это сделать, нужно подтвердить свой Email адрес. Для этого откройте ваш почтовый ящик и перейдите по ссылке в письме от Github.

 

 

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

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

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

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

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

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

Дальше все самое интересное как работать с github.

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

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

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

 

 

 

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

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

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

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

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

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

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

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

GitHub для начинающих может показаться очень сложным именно из-за таких возможностей, но это очень удобно если разобраться. Запрос слияния или Pull Request — это возможность, благодаря которой любой разработчик может попросить другого, например, создателя репозитория просмотреть его код и добавить его в основной проект или ветку. Инструмент работы с запросами слияния использует инструмент сравнения diff, поэтому вы можете увидеть все изменения, они будут подчеркнуты другим цветом. Pull Request можно создать сразу же после создания коммита. Давайте отправим Pull Request из нашей testing ветки в основную. Сначала откройте вкладку «Pull Request».

 

 

Здесь нажмите кнопку «Create Pull Request»:

Дальше вам нужно будет выбрать ветку, которую нужно слить с основной, в нашем случае «testing».

 

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

Дальше нажмите зеленую кнопку «Create Pull Request» и введите описание, как и для коммита:

6. Просмотр и одобрение запросов на слияние

Теперь, на той же вкладке Pull Requests мы видим только что созданный запрос на слияние и нам остается только принять его нажав «Merge Pull Request»:

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

Дальше можно подтвердить Pull Request:

 

 

 

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

 

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

Удобно еще то, что возможно использование GitHub не только для разработки и управления кодом, но и для обратной связи с пользователями. На вкладке «Issue» пользователи могут оставлять сообщения о проблемах, с которыми они столкнулись при использовании вашего продукта. Откройте вкладку «Issues», и нажмите на кнопку «New issue»:

Дальше вам осталось ввести заголовок, текст и нажать «Create new issue».

8. Релизы

Последнее что мы сегодня рассмотрим — это релизы. Когда продукт достиг определенной стадии можно выпустить релиз, чтобы пользователи и вы могли быть уверенны что там все стабильно и никто ничего не сломал неверным Pull Request в Master. Сначала нужно перейти на главную страницу проекта, затем на вкладку «Releases»:

Дальше нажмите кнопку «Create New Release»:

На этой странице нужно указать версию в поле «Tag Version», затем имя релиза и небольшое описание. Если у вас есть скомпилированные архивы с бинарниками то их тоже нужно прикрепить сюда. Затем нажмите «Create Release»:

После создания релиза будет создана такая страничка:

Ссылки на исходный код в tar.gz и zip будут созданы автоматически, все остальные файлы вам придется добавлять вручную.

Выводы

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

losst.ru

Как пользоваться Git для начинающих

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

Это мощная система, которая позволяет оптимизировать работу над вашими проектами. Здесь нет каких-либо требований к языку или структуре файлов, поэтому у разработчиков полная свобода действий. В этой статье мы рассмотрим как пользоваться git для начинающих пользователей. Рассмотрим все очень подробно, начиная от настройки, и до ветвей проектов.

Содержание статьи:

Команда git

Уже по традиции, перед тем, как перейти к примерам и работе с командой давайте рассмотрим ее основные опции и параметры. Синтаксис git очень прост:

$ git опции команда аргументы

Сначала рассмотрим опции, они влияют на работу всей утилиты:

• -C — использовать указанную папку репозитория вместо текущей папки;
• -c параметр=значение — использовать указанное значение параметра конфигурации;
• -p — прокручивать весь вывод с помощью less;

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

• add — добавить файл или папку в репозиторий git;
• am — применить все патчи из email;
• archive — создать архив файлов;
• bisect — использовать бинарный поиск для поиска нужного коммита;
• branch — управление ветками проекта;
• bundle — перемещение объектов и ссылок в архиве;
• checkout — переключение между ветками;
• cherry-pick — внести изменения в уже существующие коммиты;
• clean — удалить все неотслеживаемые файлы и папки проекта;
• clone — создать копию удаленного репозитория в папку;
• commit — сохранить изменения в репозиторий;
• diff — посмотреть изменения между коммитами;
• fetch — скачать удаленный репозиторий;
• init — создать репозиторий;
• merge — объединить две ветви;
• pull — интегрировать удаленный репозиторий с локальным;
• push — отправить изменения в удаленный репозиторий;
• tag — управление тегами;
• worktree — управление деревями разработки.

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

Как работает git?

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

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

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

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

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

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

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

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

mkdir -p ~/git/testing ; cd ~/git/testing

Эта команда создаст нужную структуру папок и переводит текущий каталог в только что созданный. Теперь создадим первый файл нашего проекта:

touch file

 

Проект готов, но система контроля версий git еще не знает об этом.

Настройка проекта в git

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

git init

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

git add .

Если все прошло хорошо, то команда ничего не выведет.

Фиксация изменений

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

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

git commit -m "Initial Commit" -a

Команде необходимо передать два параметра, первый — это -m, ваш комментарий, второй -a, означает, что нужно применить действие ко всем измененным файлам. Для первого раза используется этот параметр, но обычно вам нужно указать измененные файлы или каталоги. Например, можно делать так:

git commit -m "Changed file" file

 

Отправка изменений

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

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

 git remote add origin https://github.com/Seriyyy95/testing.git

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

git remote -v

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

git push origin master

Команда push указывает, что нужно отправить данные в удаленный репозиторий, origin — наш настроенный репозиторий, а master — ветвь.

Управление ветвями

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

git branch -a

 

 

Опция -a указывает что нужно вывести все ветви, даже не синхронизированные. Звездочка указывает на активную ветвь. Теперь создадим ветвь для разработки с помощью команды checkout:

git checkout -b develop

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

git checkout master
$ git checkout develop

Теперь создадим еще один файл:

touch develop

И добавим его в нашу новую ветвь develop:

git add develop

 

 

Сделаем коммит для внесенных изменений:

git commit -m "develop file" develop

Дальше проверим существует ли этот файл в основной ветке master или только в дополнительной. Смотрим текущую ветку:

git branch
$ ls

Затем переключаемся на ветку master и снова смотрим:

git checkout master
$ git branch
$ ls

Здесь файла нет, так и должно быть. В git есть такая полезная вещь, как слияние. С помощью нее вы можете объединить две ветви. Например, переместить код из рабочей ветки в стабильную. Для этого достаточно выполнить команду merge:

git merge develop --no-ff

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

Выводы

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

losst.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Master / не master, Fork, Pull request

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

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

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

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

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

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

pupi-boy.ru

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

Соавтор статьи: 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 / Habr

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

habr.com

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