Про Git, Github и Gitflow простыми словами


Оглавление (нажмите, чтобы открыть):

.3 Введение — Основы Git

Основы Git

Так что же такое Git в двух словах? Эту часть важно усвоить, поскольку если вы поймёте, что такое Git, и каковы принципы его работы, вам будет гораздо проще пользоваться им эффективно. Изучая Git, постарайтесь освободиться от всего, что вы знали о других СКВ, таких как Subversion или Perforce. В Git’е совсем не такие понятия об информации и работе с ней как в других системах, хотя пользовательский интерфейс очень похож. Знание этих различий защитит вас от путаницы при использовании Git’а.

Слепки вместо патчей

Главное отличие Git’а от любых других СКВ (например, Subversion и ей подобных) — это то, как Git смотрит на свои данные. В принципе, большинство других систем хранит информацию как список изменений (патчей) для файлов. Эти системы (CVS, Subversion, Perforce, Bazaar и другие) относятся к хранимым данным как к набору файлов и изменений, сделанных для каждого из этих файлов во времени, как показано на рисунке 1-4.

Рисунок 1-4. Другие системы хранят данные как изменения к базовой версии для каждого файла.

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

Рисунок 1-5. Git хранит данные как слепки состояний проекта во времени.

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

Почти все операции — локальные

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

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

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

Git следит за целостностью данных

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

Механизм, используемый Git’ом для вычисления контрольных сумм, называется SHA-1 хешем. Это строка из 40 шестнадцатеричных символов (0-9 и a-f), вычисляемая в Git’е на основе содержимого файла или структуры каталога. SHA-1 хеш выглядит примерно так:

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

Чаще всего данные в Git только добавляются

Практически все действия, которые вы совершаете в Git’е, только добавляют данные в базу. Очень сложно заставить систему удалить данные или сделать что-то неотменяемое. Можно, как и в любой другой СКВ, потерять данные, которые вы ещё не сохранили, но как только они зафиксированы, их очень сложно потерять, особенно если вы регулярно отправляете изменения в другой репозиторий.

Поэтому пользоваться Git’ом — удовольствие, потому что можно экспериментировать, не боясь что-то серьёзно поломать. Чтобы узнать подробнее о том, как Git хранит свои данные и как восстановить то, что кажется уже потерянным, читайте главу 9.

Три состояния

Теперь внимание. Это самое важное, что нужно помнить про Git, если вы хотите, чтобы дальше изучение шло гладко. В Git’е файлы могут находиться в одном из трёх состояний: зафиксированном, изменённом и подготовленном. «Зафиксированный» значит, что файл уже сохранён в вашей локальной базе. К изменённым относятся файлы, которые поменялись, но ещё не были зафиксированы. Подготовленные файлы — это изменённые файлы, отмеченные для включения в следующий коммит.

Таким образом, в проектах, использующих Git, есть три части: каталог Git’а (Git directory), рабочий каталог (working directory) и область подготовленных файлов (staging area).

Рисунок 1-6. Рабочий каталог, область подготовленных файлов, каталог Git’а.

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

Рабочий каталог — это извлечённая из базы копия определённой версии проекта. Эти файлы достаются из сжатой базы данных в каталоге Git’а и помещаются на диск для того, чтобы вы их просматривали и редактировали.

Область подготовленных файлов — это обычный файл, обычно хранящийся в каталоге Git’а, который содержит информацию о том, что должно войти в следующий коммит. Иногда его называют индексом (index), но в последнее время становится стандартом называть его областью подготовленных файлов (staging area).

Стандартный рабочий процесс с использованием Git’а выглядит примерно так:

  1. Вы вносите изменения в файлы в своём рабочем каталоге.
  2. Подготавливаете файлы, добавляя их слепки в область подготовленных файлов.
  3. Делаете коммит, который берёт подготовленные файлы из индекса и помещает их в каталог Git’а на постоянное хранение.

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

# 6 Git — Оптимизируем работу с помощью gitflow

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

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

Так как он у меня уже установлен, то я его устанавливать не буду. Про установку на других операционках можно почитать в оффициальной репе. В разделе Installation instruction написано как устанавливать его на все операционки.

Теперь нам нужно инициализировать gitflow в нашем репозитории.

Для этого напишем

И нам задают тут вопросы как мы хотим назвать мастер, девелоп, хотфикс и релиз ветки. Можно смело нажимать enter в ответ на все вопросы. Вопросы закончились и теперь у нас инициализирован gitflow.

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

Как мы видим сразу произошло очень много. У нас создалась новая ветка feature/implement-registration. Нам не нужно указывать приставку feature, так как она добавляется автоматически. И оно нам перекинуло на созданую ветку. И когда мы закончим работать с этой веткой нам нужно написать git flow feature finish.

Теперь cделаем какие-то изменения. Создадим файл register.js и добавим туда какую-нибудь функцию.

Теперь закоммитим наши изменения.

И пишем, что хотим закончить фичу

Эта команда автоматически мерджит фичу в develop, удаляет старую ветку и переключается на develop. И все это в одну команду.

Если мы посмотрим git log, то мы увидим, что наш коммит добавился.

Теперь давайте создадим релиз, как мы делали в прошлом уроке.

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

Если мы напишем git branch, то увидим, что у нас висит ветка release/1.0. Давайте ее просто удалим

Теперь если мы попробуем стартануть релиз, должно быть все нормально. Как мы видим, нас перебросило на ветку release/1.1. И оно нам говорит, сделайте необходимые изменения к релизу и когда закончите нажмите finish.

И так как нам не нужно делать никаких изменений пишем

Здесь у нас открывается редактор, который говорит «введите сообщение что вы здесь сделали». Потому что это мердж в мастер и девелоп одновременно. Я просто закрываю файл так как месседж уже написан. И вот у нас открылся еще раз редактор. И оно говорит: «Напишите пожалуйста месседж для тега». Давайте напишем просто 1.1. А я расскажу, что такое теги чуть позже.

Что сделала команда finish в этот раз? Она смерджила релиз в мастер и develop, поставил тег 1.1 и удалила ветку. То есть все, что мы делали в несколько команд в прошлом уроке она сделала в одну.

Если мы хотим сделать хотфикс для продакшена то мы пишем

Делаем наш хотфикс. Например удаляем пробелы в файле register.js. Делаем коммит и пишем finish

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

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

Если мы сейчас напишем git tag, то увидим, что у нас добавился тег 1.2.

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

Это создаст нам новую ветку с тега. И возьмет последним коммитом, тот, который был последним, когда мы написали эту команду. Теперь абсолютно всегда этот тег 1.2 будет существовать и мы всегда можем создать новую ветку с этого тега.

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

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

Кратко о git-flow

Git-flow — наиболее популярная методология разработки проектов с использованием git.

Зачем нам вообще нужны какие-то методологии для работы с git?

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

Git-flow даёт нам готовый стандарт проверенный временем и уже известный многим разработчикам.

В то же время, нужно понимать, что методология git-flow не является единственно верной и на 100% универсальной. В Вашем проекте может существовать собственный подход к работе с git. Однако, если вы работаете или собираетесь работать с git в команде, то стоит знать о том, что такое git-flow и в чём его особенности.

И так, что же нам стоит знать о git-flow?

Суть ветвления в git-flow

Всего в git-flow существует 5 типов веток, каждый из которых несёт определённую функциональную нагрузку.

Ветка develop

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

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

Ветки feature-*

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

Каждая ветка feature отделяется от develop и мержится обратно в него. После завершения работы над фичей и финального мержа в develop, ветка удаляется. При мерже ветки в develop не должен использоваться fast-forward (флаг —no-ff).

Имя ветки должно соответствовать имени разрабатываемой фичи, например «feature-gamecenter-integration». В некоторых проектах префикс «feature-» опускается (тогда любая ветка без префикса — это ветка feature).

Ветка master

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

В ветку master мержатся только изменения из веток release и hotfix. На каждый такой мерж создаётся тег с именем версии. Полный запрет использования fast-forward при мерже в ветку (флаг —no-ff).

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

Ветки release-*

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

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

Имя ветки должно соответствовать выпускаемой версии, например «release-1.4».

Ветки hotfix-*

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

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

Именем ветки обычно является новая версия с учётом версии фикса, например «hotfix-1.4.1» (первый хотфикс версии 1.4).

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

Инстументы с поддержкой git-flow

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

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

Так же, git-flow поддерживается из коробки некоторыми популярными графическими оболочками такими как SourceTree и SmartGit.

Как в случае консольного расширения, так и в случае графических клиентов, мы работаем с более понятными командами вроде «Start Feature» и «Finish Feature», что позволяет проще смотреть на процесс разработки.

Git-flow и непрерывная интеграция

При разработке с использованием git-flow, одновременно существует две стабильные ветки, которые можно использовать для сборки билдов или выкладки кода на сервер: это ветки master и develop.

Сборки из ветки master можно собирать сразу по поступлении новых изменений. Любые новые правки в этой ветке — это стабильный production-код, который можно выкладывать на сервер (в случае разработки веб-ресурса) либо собирать в релизный бинарник.

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

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

На версиях собранных из ветки develop следует прогонять unit-тесты.

Когда не стоит применять git-flow

Во первых, git-flow достаточно сложная методология, расчитанная на большие проекты. Если проект относительно небольшой и над ним работает команда всего из 3-4 человек, то применение git-flow может только усложнить процесс разработки.

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

В обоих случаях, можно либо взять git-flow, отказавшись от некоторых типов веток (master, release, hotfix), либо выбрать другую методологию.

Знакомство с Git и GitHub: руководство для начинающих

Ищите, с чего бы начать изучение Git и GitHub? Хотите поработать с другими? Усердно трудитесь над проектом? Или вдруг заметили, что заслужить уважение среди технарей можно своим присутствием на GitHub?

Тогда эта статья специально для вас!

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

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

Если вы сможете все это сделать, то можно считать, что вы успешно справились с задачей. А еще вы сможете поучаствовать в своем первом open-source проекте Стене на GitHub.

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

Что такое Git и GitHub?

Git — это система управления версиями, которая пришлась по душе практически всем — от разработчиков до дизайнеров. GitHub можно считать соцсетью для хранения кода. Это настоящая Мекка для технарей. Здесь вы можете попрактиковаться в разработке и придумать что-то свое, найти множество open-source проектов, передовых технологий, различных функций и дизайнов.

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

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

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

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

Пример: git add . Здесь вы можете написать нечто подобное: git add hello_world.py . Это означает, что вы хотите добавить в репозиторий файл под названием hello_world.py .

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

Затем к ним добавим еще вот эти:

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

Не лишней будет и вот такая команда:

О ней мы также поговорим ниже.

(Если вы работаете на Mac, то у вас уже установлен терминал. Нажмите на иконку с лупой в верхнем правом углу экрана и напечатайте слово terminal ).

Шаг 1: Регистрация и установка

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

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

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

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

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

Теперь вы готовы к работе с Git на локальном компьютере.

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

Репозиторий состоит из трех «деревьев». Первое «дерево» — это рабочая директория, в которой хранятся актуальные файлы. Второе — это index или область подготовленных файлов. А еще есть head — указатель на ваш последний коммит.

Вариант 1. Я уже знаком с терминалом

Вот как начать работу с Git из терминала.

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

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

Мастер Йода рекомендует:  Создаём музыкальную игру с библиотекой Oboe от Google

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

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

или добавьте сразу все файлы через:

Создать коммит с этими изменениями можно через команду:

Если изменения вас устраивают, напишите:

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

При внесении изменений следует обновить и сами файлы:


Создайте коммит, добавьте нужное сообщение и отправьте этот коммит в репозиторий.

Вот и все! Теперь вы можете инициализировать репозиторий, создавать коммиты с файлами и сообщениями, а также отправлять коммиты в ветку master .

Если с этим все понятно, то переходите к части 2: «Учимся работать с другими», в которой рассматривается градация веток и совместная работа над проектами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подайте мне вот этот проект!

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

Для клонирования репозитория на компьютер перейдите в репозиторий на GitHub и нажмите большую зеленую кнопку под названием Clone or download (разумеется, вы можете просто скачать репозиторий и избежать всех заморочек с терминалом. Но я в вас верю, поэтому не будем сдаваться!). Проследите, чтобы появилась надпись Clone with HTTPS. Теперь нажмите на иконку буфера обмена для копирования-вставки (либо выделите ссылку и скопируйте ее).

Откройте терминал и перейдите в директорию для копирования репозитория. Например, для перехода на Рабочий стол напечатайте вот это:

Затем клонируйте туда репозиторий по следующей команде:

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

Если вы не очень хорошо ориентируетесь в терминале, то переход по директориям можно осуществлять через команду cd . Например, откройте терминал и напечатайте ls для отображения перечня доступных директорий. Вполне возможно, что в этом списке вы сразу увидите директорию Desktop . Либо напечатайте cd Desktop . Далее выполните команду git clone и склонируйте репозиторий на Рабочий стол.

Бывает и так, что вместо перечня расположений, вы видите различные имена пользователей. Тогда до того, как перейти в Desktop , вам потребуется выбрать нужного пользователя через команду cd (замените на нужное вам имя). Затем снова напечатайте ls , чтобы увидеть весь список. И вот теперь, увидев в списке Desktop , смело печатайте cd Desktop . Сейчас уже можно выполнять git clone !

Если вдруг в терминале вы захотите «откатиться» на шаг назад, то напишите cd ..

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

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

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

Добавляем файлы в проект

Вот, чем мы займемся:

Но ничего сложного здесь нет!

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

Проверьте статус проекта.

Откройте терминал и перейдите в папку репозитория. Для проверки обновлений выполните:

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

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

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

Коммиты изменений добавляются в head (указатель), а не в удаленный репозиторий. Не забудьте заменить текст в скобках и убрать <> . После внесения изменений создается снимок состояния репозитория, для чего используется команда commit . А через –m добавляется сообщение об этом снимке.

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

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

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

Актуальность версии можно проверить в любое время через команду git status .

Итог: у вас есть свой GitHub репозиторий, вы научились добавлять и изменять в нем файлы.

Git Flow vs Github Flow

Export

Office Formats

Other Formats

Select the pages to export:

Git Flow vs Github Flow

GIT FLOW

Децентрализованный, но централизованный

Предлагаемая модель ветвления опирается на конфигурацию проекта, содержащую один центральный «истинный» репозиторий. Замечу, что этот репозиторий только считается центральным (так как Git является DVCS, у него нет такой вещи, как главный репозиторий, на техническом уровне). Мы будем называть этот репозиторий термином origin, т.к. это имя и так знакомо всем пользователям Git.

Каждый разработчик забирает и публикует изменения (pull & push) в origin. Но, помимо централизованных отношений push-pull, каждый разработчик также может забирать изменения от остальных коллег внутри своей микро-команды. Например, этот способ может быть удобен в ситуации, когда двое или более разработчиков работают вместе над большой новой фичей, но не могут издать незавершённую работу в origin раньше времени. На картинке выше изображены подгруппы Алисы и Боба, Алисы и Дэвида, Клэр и Дэвида.

Технически это реализуется несложно: Алиса создаёт удалённую ветку Git под названием bob, которая указывает на репозиторий Боба, а Боб делает то же самое с её репозиторием.

Главные ветви

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

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

Мы считаем ветку origin/master главной. То есть, исходный код в ней должен находиться в состоянии production-ready в любой произвольный момент времени.

Ветвь origin/develop мы считаем главной ветвью для разработки. Хранящийся в ней код в любой момент времени должен содержать самые последние изданные изменения, необходимые для следующего релиза. Эту ветку также можно назвать «интеграционной». Она служит источником для сборки автоматических ночных билдов.

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

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

Вспомогательные ветви

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

Мы используем следующие типы ветвей:

  • Ветви функциональностей (Feature branches)
  • Ветви релизов (Release branches)
  • Ветви исправлений (Hotfix branches)

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

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

Ветви функциональностей (feature branches)

Могут порождаться от: develop
Должны вливаться в: develop
Соглашение о наименовании: всё, за исключением master, develop, release-* или hotfix-*

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

Ветви функциональностей (feature branches) обычно существуют в репозиториях разработчиков, но не в главном репозитории (origin).

Создание ветви функциональности (feature branch)

При начале работы над новой функциональностью делается ответвление от ветви разработки (develop).

Добавление завершённой функциональности в develop

Завершённая функциональность (фича) вливается обратно в ветвь разработки (develop) и попадает в следующий релиз.

Флаг —no-ff вынуждает Git всегда создавать новый объект коммита при слиянии, даже если слияние может быть осуществлено алгоритмом fast-forward. Это позволяет не терять информацию о том, что ветка существовала, и группирует вместе все внесённые изменения. Сравните:

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

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

К сожалению, я ещё не нашёл, как можно настроить Git так, чтобы —no-ff было поведением по-умолчанию при слияниях. Но этот способ должен быть реализован.

Ветви релизов (release branches)

Могут порождаться от: develop
Должны вливаться в: develop и master
Соглашение о наименовании: release-*

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

Новую ветку релиза (release branch) надо порождать в тот момент, когда состояние ветви разработки полностью или почти полностью соответствует требованиям, соответствующим новому релизу. По крайней мере, вся необходимая функциональность, предназначенная к этому релизу, уже влита в ветвь разработки (develop). Функциональность, предназначенная к следующим релизам, может быть и не влита. Даже лучше, если ветки для этих функциональностей подождут, пока текущая ветвь релиза не отпочкуется от ветви разработки (develop).

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

Создание ветви релиза (release branch)

Ветвь релиза создаётся из ветви разработки (develop). Пускай, например, текущий изданный релиз имеет версию 1.1.5, а на подходе новый большой релиз, полный изменений. Ветвь разработки (develop) готова к «следующему релизу», и мы решаем, что этот релиз будет иметь версию 1.2 (а не 1.1.6 или 2.0). В таком случае мы создаём новую ветвь и даём ей имя, соответствующее новой версии проекта:

Мы создали новую ветку, переключились в неё, а затем выставили номер версии (bump version number). В нашем примере bump-version.sh — это вымышленный скрипт, который изменяет некоторые файлы в рабочей копии, записывая в них новую версию. (Разумеется, эти изменения можно внести и вручную; я просто обращаю Ваше внимание на то, что некоторые файлы изменяются.) Затем мы делаем коммит с указанием новой версии проекта.

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

Закрытие ветви релиза

Когда мы решаем, что ветвь релиза (release branch) окончательно готова для выпуска, нужно проделать несколько действий. В первую очередь ветвь релиза вливается в главную ветвь (напоминаю, каждый коммит в master — это по определению новый релиз). Далее, этот коммит в master должен быть помечен тегом, чтобы в дальнейшем можно было легко обратиться к любой существовавшей версии продукта. И наконец, изменения, сделанные в ветви релиза (release branch), должны быть добавлены обратно в разработку (ветвь develop), чтобы будущие релизы также содержали внесённые исправления багов.
Первые два шага в Git:

Теперь релиз издан и помечен тегом.

Замечание: при желании, Вы также можете использовать флаги -s или -u , чтобы криптографически подписать тег.

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

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

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

Ветви исправлений (hotfix branches)

Могут порождаться от: master
Должны вливаться в: develop и master
Соглашение о наименовании: hotfix-*

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

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

Создание ветви исправлений (hotfix branch)

Ветви исправлений (hotfix branches) создаются из главной (master) ветви. Пускай, например, текущий производственный релиз имеет версию 1.2, и в нём (внезапно!) обнаруживается серьёзный баг. А изменения в ветви разработки (develop) ещё недостаточно стабильны, чтобы их издавать в новый релиз. Но мы можем создать новую ветвь исправлений и начать работать над решением проблемы:

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

Закрытие ветви исправлений

Когда баг исправлен, изменения надо влить обратно в главную ветвь (master), а также в ветвь разработки (develop), чтобы гарантировать, что это исправление окажется и в следующем релизе. Это очень похоже на то, как закрывается ветвь релиза (release branch).

Прежде всего надо обновить главную ветвь (master) и пометить новую версию тегом.

Замечание: при желании, Вы также можете использовать флаги -s или -u , чтобы криптографически подписать тэг.

Следующим шагом переносим исправление в ветвь разработки (develop).

У этого правила есть одно исключение: если в данный момент существует ветвь релиза (release branch), то ветвь исправления (hotfix branch) должна вливаться в неё, а не в ветвь разработки (develop). В этом случае исправления войдут в ветвь разработки вместе со всей ветвью релиза, когда та будет закрыта. (Хотя, если работа в develop требует немедленного исправления бага и не может ждать, пока будет завершено издание текущего релиза, Вы всё же можете влить исправления (bugfix) в ветвь разработки (develop), и это будет вполне безопасно).

И наконец, удаляем временную ветвь:

Заключение Git Flow

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

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

Проблемы git-flow

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

Однако и у git-flow есть проблемы. Я видел чаще всего в комментариях мнения людей, выражавших неприязнь к тому, что ветви фич отходят от develop вместо master, или к манере обращения с хотфиксами, но эти проблемы сравнительно невелики.

Одной из более крупных проблем git-flow стала его сложность — бóльшая, чем на самом деле требуется большинству разработчиков и рабочих групп. Его сложность ужé привела к появлению скрипта-помощника для поддержания рабочего процесса. Само по себе это круто, но проблема в том, что помощник работает не из GUI Git, а из командной строки, и получается, что те самые люди, которым необходимо действительно хорошо выучить сложный рабочий процесс, потому что им вручную придётся пройти все шаги его — для этих-то людей система и недостаточно удобна для того, чтобы использовать её из командной строки. Вот что становится крупною проблемою.

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

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

Рабочий процесс Гитхаба

Итак, почему в Гитхабе не используют git-flow? Главная проблема в том, что у них принято беспрестанное внедрение изменений. Рабочий процесс git-flow создавался в основном в помощь «выпускам» нового кода. А у гитхаба нет «выпусков», потому что код поступает на продакшен (основной рабочий сервер) ежедневно — иногда по нескольку раз в день. Для этого они могут подавать команды боту в той же чат-комнате, в которой отображаются итоги CI (интеграционного тестирования). Всё для того, чтобы сделать процесс тестирования кода и его внедрения как можно проще, чтобы каждому сотруднику он был удобен в работе.

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

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

Мастер Йода рекомендует:  Создание подсказок в ссылках

Как Гитхаб это делает

Итак, каков рабочий процесс Гитхаба?

  • Содержимое ветви master всегда работоспособно (deployable).
  • Начиная работу над чем-то новым, ответвляйте от ветви master новую ветвь, имя которой соответствует её предназначению (например, «new-oauth2-scopes»).
  • Закоммитив в эту ветвь локально, отправляйте регулярно свою работу и в одноимённую ветвь на сервере.
  • Когда вам понадобится отзыв, или помощь, или когда вы сочтёте ветвь готовою ко слиянию, отправьте запрос на слияние .
  • После того, как кто-то другой просмотрел и одобрил фичу, вы можете слить вашу ветвь в ветвь master.
  • После того, как ветвь master пополнилась новым кодом, вы можете немедленно внедрить его на продакшен и вам следует сделать это.

Вот и весь рабочий процесс. Он очень прост и результативен, он работает для довольно крупных рабочих групп — в Гитхабе сейчас работает 35 человек, из которых, может быть, пятнадцать или двадцать одновременно работают над одним и тем же проектом (github.com). Думаю, что большинство команд разработчиков (групп, одновременно работающих с логикою одного и того же кода, что может порождать конфликты) имеют такой же размер — или меньше такого. Особенно группы, достаточно прогрессивные для того, чтобы заниматься быстрым и последовательным внедрением.

Итак, давайте по порядку рассмотрим каждый шаг.

Содержимое ветви master всегда работоспособно (deployable)

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

Ветвь master стабильна. Внедрение её кода на продакшен или создание новых ветвей на её основе — это всегда, всегда безопасно. Если от вас в master поступает неоттестированный код или он ломает сборку, то вы нарушили «общественный договор» команды разработчиков и у вас на душé должны кошки поскрести по этому поводу. Каждая ветвь подвергается тестированию, а итоги поступают в чат-комнату — так что, если вы не тестировали её локально, то можете запушить ветвь (даже с единственным коммитом) на сервер и подождать, пока Jenkins не сообщит, все ли тесты успешно пройдены.

Ответвляйте от ветви master новые ветви, имена которых соответствуют предназначению

Когда хотите поработать над чем-то новым, ответвляйте от стабильной ветви master новую ветвь, имя которой соответствует предназначению. (Например, в коде Гитхаба прямо сейчас есть ветви «user-content-cache-key», «submodules-init-task», «redis2-transition».) Такое наименование имеет несколько достоинств. Например, достаточно подать команду fetch, чтобы увидеть, над какими темами работают остальные. Кроме того, оставив ветвь на какое-то время и возвратившись к ней позднее, по имени проще припомнить, о чём она была.

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

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

Постоянно отправляйте код именованных ветвей на сервер

Другое крупное отличие от git-flow: беспрерывно делается push ветвей на сервер. С точки зрения внедрения приходится по-настоящему беспокоиться только о ветви master, так что push никого не озадачит и ничего не поломает: всё, что не master — это просто код, над которым идёт работа.

Этим создаётся страховочная копия на случай утраты ноутбука или выхода жёсткого диска из строя. Этим поддерживается, что ещё важнее, постоянный обмен сведениями между разработчиками. Простой командою «git fetch» можно получить список тех TODO, над которыми все сейчас работают.

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

В любое время создавайте запрос на слияние

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


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

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

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

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

И это круто, потому что в запросах на слияние можно комментировать отдельные строки объединённого диффа, или отдельные коммиты, или весь запрос в целом — и копии реплик сложатся в единое обсуждение. Также можно продолжать пополнение ветви кодом, так что если кто-нибудьукажет на ошибку или на позабытую возможность в коде, то можно поместить исправление в ту же ветвь, и GitHub покажет новые коммиты в обсуждении, так что и вот так можно трудиться над ветвью.

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

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

Слияние только после обзора запроса

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

Когда одобрение получено, и ветвь прошла CI, мы можем слить её в master и на внедрение; в этот момент запрос на слияние будет закрыт автоматически.

Внедрение непосредственно после обзора

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

Гитхабоский campfire-бот, по имени hubot, может внедрять код по указанию от любого из сотрудников. Достаточно подать в чате команду hubot deploy github to production, и код поступит на продакшен, где начнётся перезапуск (с нулевым даунтаймом) всех необходимых процессов. Можете сами судить о том, как часто это случается на Гитхабе:

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

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

Заключение GitHub Flow

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

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

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

  • Создайте ветвь
  • Фиксируйте изменения
  • Откройте запрос на слияние

Проверьте и обсудите код

  • Проверьте в бою

Как правильно отправить релиз на git?

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

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

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

Но у меня локально есть только ветка девелоп и удалено есть девелоп и мастер.

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

Я просто не уверен, что эта концепция правильная и второе я не уверен, что можно делать мерж на удаленых ветках.

Посоветуйте как правильно сделать?

6 ответов 6

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

Что вообще происходит и откуда взялись ветки develop и release

Указанная вами статья – про модель рабочего процесса под названием git flow. Это в целом хорошая модель. Она была придумана, чтобы упорядочить бардак и анархию при совместной работе над кодом в больших проектах, и именно в них она эффективна. Если у вас сто человек работает над одним приложением, если вы вынуждены поддерживать старые версии (исправлять баги и критические уязвимости), если в день делаются сотни коммитов — берите, не пожалеете.

А для команд, которые

  • немногочисленны, примерно до 10 человек;
  • работают по agile и дробят задачи настолько, чтобы они делались за день-два;
  • используют в основном самую последнюю версию продукта и не должны тащить старые версии;

. git flow попросту не нужен. Он создаёт больше проблем, чем решает.

Как сделать проще

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

Правильно! Вам и девелоп-то не нужен.

Для небольших команд и соло-разработки больше подходят «легковесные» модели организации рабочего процесса. Самая популярная называется GitHub Flow, от неё отличаются некоторыми деталями и бóльшей глубиной проработки GitLab Flow и Simple Git workflow (Atlassian).

Суть всех простых моделей рабочего процесса

  1. Есть единственная стабильная (постоянная, долгоживущая) ветка master .
  2. Любая фича или исправление бага делается в отдельной ветке, которая ветвится от master .
  3. Как только фича или багфикс готов, прошёл ревью и тестирование, соответствующая ветка мержится в master . Потом ветка обязательно удаляется, чтобы не копить хлам.

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

Как создавать и называть ветки

Принято начинать название feature-ветки с номера задачи в трекере задач.

Вы же где-то ведёте список задач? Начните, если нет, и вот почему:

  1. Чтобы не держать их в голове, т.к. это ненадёжно и съедает ресурсы мозга
  2. Чтобы вы могли их оценивать, планировать, выбирать приоритеты
  3. Чтобы хранить информацию о багах и способах их воспроизвести.
  4. Тренировка для командной работы; вы наверняка не будете всю жизнь работать соло.
  5. Если проект в опенсорсе, то кто-нибудь придёт и заведёт вам задачу-пожелание или задачу-багрепорт. Или возьмёт вашу задачу и сделает, просто так, даром. Нельзя сделать задачу, которая не описана, верно?

Формулируйте маленькие, атомарные задачи, чтобы работа в ветке шла 1-3 дня, не больше. Это важно для работы соло и критически важно для командной работы.

Локальные ветки желательно тоже пушить на удалённый сервер, это хороший способ не потерять код, когда пролил чай в ноутбук, rm -rf / , пожар, кража, метеорит.

Как мержить ветки

Есть два основных способа:

Ветку можно замержить вручную, локально. В командной строке это так:

Если вы используете GitHub, GitLab, Bitbucket — можно открыть пулл/мерж-реквест и потом его замержить. При этом фактически мержатся удалёные ветки, потом вам нужно будет подтянуть себе результат мержа ( git pull ). Этот способ помогает проводить инспекцию кода в команде и разное автоматизированное тестирование, но если вы работаете один, мерж-реквесты почти не нужны.

Особенности:

  • Мержить ветки нужно через —no-ff , чтобы всегда создавался мерж-коммит. Он поможет вам просматривать историю, он помогает найти ветку, в которой был сделан коммит, и точно обозначает место, где эту ветку замержили, его можно отменить с помощью git revert . Любите мерж-коммиты, они вам пригодятся.
  • Не нужно мержить в master то, что не готово, не доделано и т.п. Ветка master священна, в ней всегда должен быть рабочий код.
  • Никогда не нужно мержить ветку master в ветку фичи. Исключения — подтягивание кода из мажорного релиза в долгоживущую ветку, разные ветки для разных тестовых окружений и прочие ситуации, которые почти не встречаются при соло-разработке небольшого проекта.

Релиз

Когда вы готовы сделать релиз, просто возьмите нужный мерж-коммит и повесьте на него тег. Используйте аннотированные (annotated) теги. В них сохраняется дата и автор, как в коммите. Таким образом сохранится информация о том, кто именно и когда принял решение о выпуске релиза.

Чтобы запушить теги на удалённый сервер, делайте так:

Параметр —follow-tags нужен для того, чтобы запушить только аннотированные теги и не пушить легковесные (lightweight), если они у вас вдруг есть.

Не отмечайте релизными тегами коммиты в feature-ветках. Замержили, протестировали результат, отметили тегом полученный мерж-коммит. Всё, что не в master , не может быть релизом.

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

Выпускайте релизы как можно чаще

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

Но постарайтесь собрать группу бета-тестеров (начните с себя), для которых вы будете выпускать приложение после каждого мержа ветки в master . Таким образом вы ускорите получение обратной связи, а чем быстрее цикл ОС, тем быстрее развивается ваше приложение и ваши навыки. В этом суть Agile.

Практика

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

  1. Замержить (слить) develop в master.
  2. Повесить на полученный мерж-коммит тег.
  3. Удалить ветку develop и не вспоминать о ней до поры.

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

Я просто не уверен, что эта концепция правильная

Она одновременно может быть правильной, и не подходящей конкретно вашему проекту.

я не уверен, что можно делать мерж на удаленных ветках.

Нельзя. Вы синхронизируете локальные ветки с удаленными (fetch/pull), мержите, и синхронизируете удаленные с локальными (push). На самом деле даже ветка origin/master тоже является локальной.

Посоветуйте как правильно сделать?

IT — такая интересная область, в которой множество правильных ответов.

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

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

1 создать rc ветку
2 смержить с вашей dev
3 вылить rc ветку

Так делается для того, что в случае креша можно было спокойно переключиться на предыдущую стабильную ветку, пофиксить новую rc ветку и опять зарелизить. Удалять ветки крайне не рекомендую. На практике часто приходиться доставать изменения в других ветках. Но если у вас веток перевалило за N и вы в них уже путаетесь, тогда можно почистить и только локально (git branch -d )

50 коммитов. А модуль2 в r2 тоже N коммитов. Смержили. Удалили r1 (полностью на сервере и локально git push origin :the_remote_branch). И вдруг ветка поломалась или модуль2 не нужен. Короче требуется восстановить только rc1. И начинается поиск коммита по хешу, а коммитов непонятно сколько. Но это не предел, представьте ситуацию когда вы помержились потом сделали доработку в rc1 потом в rc2 опять помержились. В этой ситуации ветку искать очень сложно. – Kostiantyn Okhotnyk 8 окт ’16 в 14:37

В том случае, что Вы описали Вы можете поступить 2 способами:

  1. Пойти по пути git flow, создав release ветку и тут же её завершив.
  2. Сделать слияние develop с master самостоятельно и [опционально] поставив tag на master.

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

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

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

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

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

Дмитрий [KP0H] Пелевин

Сохраняю тишину в голове

Про git flow в разработке

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

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

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

Хватит лирики

В общем-то давайте к практике.

.gitignore

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

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

Типичные файлы .gitignore в зависимости от языка или среды разработки вы сможете найти на GitHub в соответствующем проекте.

Git Flow

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

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

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

Мастер Йода рекомендует:  Подзапросы SQL

Если кратко, то зовется это все Git Flow, и описано множество раз на просторах безграничного интернета.

Git-flow — это набор расширений git предоставляющий высокоуровневые операции над репозиторием для поддержки модели ветвления Vincent Driessen.

Установка Git flow

Для начала нужно иметь установленный git;

Если с Git все хорошо, то в зависимости от используемой операционной системы можно использовать следующие способы установить git flow.

OS X — Homebrew
OS X — Macports

Linux

Windows
Windows SourceTree

Данный клиент поддерживает Git Flow и позволяет весьма просто управлять им из Gui-интерфейса «из коробки».

Начало работы

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

В общем для инициализации нужно использовать команду

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

Feature

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

Ветка типа Feature создается из основной ветки разработки (по умолчанию develop).

В наименовании фичи можно исходить из потребностей конкретно вашего процесса разработки. Может быть вам будет удобно использовать какой-нибудь идентификатор пользовательской истории из вашего трекера, а может краткое текстовое название. В итоге вы получите такую ветку feature/featurename.

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

  • Выполнить слияние ветки фичи в ветку разработки (feature/featurename в develop в моем примере).
  • Переключиться обратно в ветку разработки.
  • Удалить ветки фичи.

Если работа над фичей идет совместно с коллегами — опубликуйте ёё на удаленном севере.


Соответственно чтобы получить кем-то опубликованную фичу необходимо выполнить

Можно отслеживать фичу в репозитории origin выполнив

Release

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

Для начала релиза

Где [BASE] вы можете указать при желании в виде sha-1 хеша коммита из которого нужно начать релиз. Этот коммит должен обязательно принадлежать ветки разработки.

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

И так же по аналогии для отслеживания нужно использовать

Завершение релиза один из наиболее сложных и важных шагов всего процесса ветвления в ходе которого происходят следующие действия:

  • Ветка релиза сливается в ветку мастер
  • Рализ помечается тегом равным его имени
  • Ветка рилаза сливается обратно в ветку разработки
  • Ветка релиза удаляется

Чтобы опубликовать тэги

Исправления

Исправления нам необходимы в том случае, когда требуется срочное изменение состояния продакшн-версии разрабатываемого продукта. Как вы понимаете она у нас находится в ветке master и помечена тэгом версии, соответственно мы ветвим hotfix от тега на ветке мастер.

Version — определяет имя нового исправленного релиза.

[Basename] — не обязательный аргумент, указывающий на коммит, от которого произойдет ветвление.

Завершение исправления выглядит так:

В этот момент оно сливается в ветки develop и master, коммит в ветке master помечается тегом с версией исправления.

Резюме

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

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

Думаю в ближайшее время подготовлю перевод этой статьи.

Если Вы нашли ошибку, пожалуйcта выделите ее и нажмите Shift + E или нажмите здесь чтобы информировать меня. Спасибо.

Каковы плюсы и минусы git -flow vs github-flow?

Недавно мы начали использовать GitLab.

В настоящее время используется «централизованный» рабочий процесс.

Мы рассматриваем переход к github-потоку, но я хочу убедиться.

Каковы плюсы и минусы git -flow vs github-flow?

Как обсуждалось в эпизоде GitMinutes 17, Николас Закас в своей статье «Рабочие процессы GitHub внутри компании»:

Git-flow — это процесс управления изменениями в Git, который был создан Винсентом Дриссеном и сопровождается некоторыми расширениями Git для управления этим потоком.
Основная идея git-flow состоит в том, чтобы иметь несколько отдельных ветвей, которые всегда существуют, каждая для разных целей: master , develop , feature , release и hotfix .
Процесс разработки функции или ошибки передается из одной ветки в другую до его окончательного выпуска.

Некоторые из респондентов указали, что они используют git-flow в целом.
Некоторые начали с git-flow и отошли от него.

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

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

Вы можете увидеть интересную иллюстрацию простого рабочего процесса, основанного на GitHub-Flow, по адресу:
«Простая модель ветвления git«, основными элементами которой являются:

  1. master всегда должен быть развернут.
  2. все изменения, сделанные через функциональные ветки (pull-request + merge)
  3. перебазировать, чтобы избежать/разрешить конфликты; объединить с master

Фактически более полный и надежный рабочий процесс см. gitworkflow (одно слово).

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

Несколько версий в производстве — используйте Git -flow

Если ваш код имеет несколько версий в производстве (т.е. типичный программные продукты, такие как операционные системы, офисные пакеты, пользовательские приложения и т.д.), вы можете использовать git -flow. Основная причина в том, что вам нужно постоянно поддерживать предыдущие версии в производстве, в то время как разрабатывая следующую версию.

Единая версия в простоте программного обеспечения — используйте Github-flow

Если ваш код всегда имеет только одну версию в производстве (т.е. веб-сайты, веб-службы и т.д.), вы можете использовать github-flow. Главный причина в том, что вам не нужно создавать сложные вещи для разработчика. После того, как разработчик завершит работу или завершит исправление, немедленно продвигается к производственной версии.

Одиночная версия в производстве, но очень сложное программное обеспечение — используйте Gitlab-flow

Большое программное обеспечение, такое как Facebook и Gmail, может потребоваться ветвей развертывания между веткой и ведущей веткой, где могут запускаться инструменты CI/CD > , прежде чем они попадут в производство. Идея заключается в том, чтобы ввести дополнительную защиту для производственной версии, поскольку она используется миллионы людей.

Я использую модель git -flow более года и ее нормально.

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

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

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

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

Существует как минимум один графический интерфейс, поддерживающий git -flow для Mac и Windows SourceTree.

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

Git для начинающих

Для людей естественно сопротивляться изменениям. Если Git не встретился вам, когда вы начинали работать с системами контроля версий, наверняка вы чувствуете себя комфортнее в системе Subversion (SVN) .

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

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

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

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

Установка Git

На официальном сайте Git есть детальная информация об его установке на Linux, Mac и Windows. В нашем случае, мы будем использовать в целях демонстрации Ubuntu 13.04 , где установим Git с помощью apt-get:

Начальная настройка

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

Первым этапом является инициализация Git в каталоге. Это можно сделать с помощью команды init , которая создает каталог .git , содержащий всю информацию, связанную с Git для вашего проекта.

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

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

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

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

Подготовка файлов для коммита

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

Проверить статус репозитория

Теперь, когда у нас есть несколько файлов в нашем репозитории, давайте посмотрим, как Git обращается с ними. Для того, чтобы проверить текущий статус репозитория, нужно воспользоваться командой git status :

Добавление файлов в Git для отслеживания

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

Добавляем файлы при помощи команды add :

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

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

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

Если вы будете использовать команду add рекурсивно, она добавит все такие файлы, если они существуют в вашем репозитории.

Удаление файлов

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

Но выполнение простой команды git rm удалит файл не только из Git , но также и из вашей локальной файловой системы! Чтобы

Git прекратил отслеживать файл, но при этом в вашей локальной системе сохранился сам файл, выполните следующую команду:

Коммит изменений

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

Вы можете привязывать к каждому коммиту сообщение, которое добавляется при помощи префикса -m :

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

Избегайте слишком общих сообщений типа « Исправлены ошибки ». Если у вас есть трекер задач, вы можете добавлять сообщения в виде « Исправлена ошибка #234 ».

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

Git идентифицирует коммиты путем добавления длинного шестнадцатеричного числа к каждому коммиту. Как правило, не нужно копировать всю строку, для определения вашего коммита достаточно первых 5-6 символов.

Обратите внимание, что на скриншоте наш первый коммит определяется кодом 8dd76fc .

Дальнейшие коммиты

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

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

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

Вы можете избежать использования этой команды, воспользовавшись префиксом -a для команды git commit , который добавит все изменения в отслеживаемые файлы.

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

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

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

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

Управление проектом

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

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

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

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

Размещение кода в облаке

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

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

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

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

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

Заключение

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

Данная публикация представляет собой перевод статьи « Git for Beginners » , подготовленной дружной командой проекта Интернет-технологии.ру

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

Добавить комментарий