Pull to refresh

Правильный цикл работы с версиями SVN

Reading time 2 min
Views 24K
Website development *
Я думаю многие любопытные люди уже знают, как нужно верно работать с SVN.
Но во многих статьях это описано достаточно поверхностно. Хочется немного приоткрыть завесу верного цикла версионирования, при разработке проекта, на примере TortoiseSVN.
И так, поехали
Читать дальше →
Total votes 72: ↑54 and ↓18 +36
Comments 56

Software Configuration Management // Контроль версий

Reading time 12 min
Views 19K
Project management *
И снова здравствуйте.

Продолжаю публиковать цикл статей о SCM — управлении конфигурацией ПО.
3 предыдущие заметки можно прочитать в этом же блоге.

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

Disclaimer


Далее будут описаны основные техники, реализованные в подавляющем большинстве систем контроля версий. Как они реализуются в приложениях, которые использует читатель, оставим на откуп многочисленным руководствам пользователя, how-to, FAQ и прочим документам, коих можно найти без труда. Главное – понять, по каким принципам и зачем оно работает именно так.

Всё понятно, продолжай
Total votes 30: ↑28 and ↓2 +26
Comments 27

Делаем релизы с помощью Maven в Java

Reading time 8 min
Views 48K
Java *
Sandbox

О чем эта статья?


Эта статья о том:
  1. Что такое релиз?
  2. Как нумеруются релизы?
  3. Зачем при релизе нужен бранч?
  4. Почему релиз это больше, чем просто jar (war, ear, zip, etc)?
  5. Что такое maven-release-plugin?
  6. Делаем бранч c помощью release:branch.
  7. Подготовка к релизу с помощью release:prepare.
  8. Выпускаем релиз с помощью release:perform.

Для чтения и понимания этой статьи я рекомендую освежить свои знания по Maven. Многие термины могут быть непонятны без понимания этой технологии.
Читать дальше →
Total votes 58: ↑57 and ↓1 +56
Comments 24

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

Reading time 9 min
Views 33K
Programming *Version control systems *
Sandbox
Вступление

Как справедливо заметил Fred Brooks, серебряной пули, способной поразить зверя разработки программного обеспечения, не существует. Пока возникают новые требования, идеи и находятся новые баги, программы живут и изменяются. Путь, который проходит код от версии к версии, может быть крайне сложен и извилист. К его созданию причастно много людей: разработчики, тестировщики, бизнес-аналитики, заказчики и т.п. Несмотря на то, что существует много разных видов разработки – аутсорсинг, продуктовая разработка, open-source и т.п., проблемы, стоящие перед командой, остаются примерно одинаковыми. Программное обеспечение – вещь сложная, потребитель хочет получить его как можно быстрее (и дешевле). Качество при этом должно быть приемлемым. Перед командой разработки стоит серьезная задача – наладить эффективное взаимодействие. Одним из самых главных средств коллаборации внутри команды разработчиков является сам код, который они пишут.

Читать дальше →
Total votes 37: ↑31 and ↓6 +25
Comments 72

Моделирование истории в централизованных и распределенных системах управления версиями

Reading time 6 min
Views 6.3K
Programming *Version control systems *

Вступление


В своей практике мне довелось участвовать в миграции проекта (codebase имел 5+ лет истории) с централизованной системы управления версиями (centralized VCS — SVN) на распределенную (distributed VCS — Mercurial). Подобные активности часто сопровождаются определенным количеством FUD (fear, uncertainty and doubt) среди команды, вовлеченной в этот процесс. Если технические моменты конвертации (структура новых репозиториев, инструментальная поддержка, работа с большими бинарными файлами, кодировки и т.п.) по большему счету будут решены в определенный момент, то вопросы, связанные с преодолением кривой обучения для команды для эффективного использования новой системы, на момент перехода могут только начинаться.

При таких переходах важно измение взгляда на новую систему контроля версий и ее использование (mindset shift). Тут очень помогает хорошее понимание принципов, на которых основаны VCS. Если разобраться в основах, использование системы заметно упрощается. Соответственно, данный материал будет посвящен различиям в моделировании истории между централизованным и децентрализованным системами управления версиями.
Читать дальше →
Total votes 7: ↑7 and ↓0 +7
Comments 2

GitHub Flow: рабочий процесс Гитхаба

Reading time 10 min
Views 121K
Git *GitHub *
Translation
Краткое предисловие переводчика.
Захватывающе интересная статья одного из разработчиков «GitHub Inc.» о принятом в компании рабочем процессе потребовала употребить пару специальных терминов при переводе.

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

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

К сожалению, некоторые переводчики бывают склонны грубо убивать сочную метафору «иньекции» (или даже «впрыскивания», если угодно), содержающуюся в термине «code injection», так что и его также переводят словосочетанием «внедрение кода». Эта путаница огорчает меня, но ничего не могу поделать. Просто имейте в виду, что здесь «внедрением кода» я стану назвать внедрение его именно в производство (на продакшен), а не в чей-нибудь чужой код.

Я стремился употреблять словосочетание «в Гитхабе» в значении «в компании GitHub Inc.», а «на Гитхабе» — в значении «на сайте GitHub.com». Правда, иногда разделять их сложновато.

Проблемы git-flow


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

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

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

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

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

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


Читать дальше →
Total votes 111: ↑105 and ↓6 +99
Comments 47

Системы контроля версий: Fossil, часть II

Reading time 10 min
Views 14K
Version control systems *
Tutorial
Продолжаем разговор о Fossil.

В первой части мы познакомились с использованием Fossil в однопользовательском режиме на одном рабочем месте. Следующий шаг — перенос репозитория на другой компьютер — с работы на домашний, или на ноутбук, который мы берем с собой в поездку. Самый простой вариант — это просто скопировать репозиторий, благо это всего один файл, на новое рабочее место. Можно так и сделать, но самое простое решение не всегда самое лучшее, есть вероятность, что возникнут небольшие проблемы.
Читать дальше →
Total votes 21: ↑18 and ↓3 +15
Comments 8

Руководство по Git. Часть №1: все, что нужно знать про каталог .git

Reading time 4 min
Views 53K
VK corporate blog Programming *Git *
Translation



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

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

Это первая часть гайда по Git из блога Pierre de Wulf в переводе команды Mail.ru Cloud Solutions
Читать дальше →
Total votes 64: ↑53 and ↓11 +42
Comments 64

Руководство по Git. Часть №2: золотое правило и другие основы rebase

Reading time 6 min
Views 25K
VK corporate blog Git *
Translation
Посмотрим, что происходит, когда вы выполняете git rebase и почему нужно быть внимательным. 

Это вторая и третья части гайда по Git из блога Pierre de Wulf в переводе команды Mail.ru Cloud Solutions. Первую часть можно почитать тут.
Читать дальше →
Total votes 48: ↑48 and ↓0 +48
Comments 26