Pixelapse — система контроля версий для дизайнеров
1 мин
Калифорнийские ребята разработали интересный сервис Pixelapse, который позволяет загружать на сайт графические файлы (интеграция с Photoshop), автоматически создает версии файлов и дает богатые возможности для обсуждения работ.
Одним словом Pixelapse — это GitHub для дизайнеров.
Одним словом Pixelapse — это GitHub для дизайнеров.
Сравнение Subversion и Mercurial (HG)
7 мин
Мое первое знакомство с системой контроля версий было еще в школе. Это был Subversion. В то время меня очень впечатлила его сила и возможности. Но шло время. Были не очень приятные моменты с переименовыванием файлов, каталогов и прочее (да, да здравствует svn 1.5, 1.6 и его вечные папки .svn). И все бы продолжалось в том же духе, если бы однажды в компании не задумались о смене системы контроля версий. Все случилось неожиданно быстро и предо мной возник Mercurial. Пришлось почитать о его особенностях, поспрашивать советов бывалых и вот я уже сам помогал своим коллегам разобраться в поведении и работе нового инструмента. Чем дольше я знакомился с Hg, тем больше он мне нравился, точнее, нравился его децентрализованный подход к контролю версий, Subversion же неизбежно отходил на второй план.
Однако, на новом месте работы мне снова пришлось вспомнить о Subversion, что, честно сказать, меня не обрадовало. К счастью, это не было безоговорочной политикой компании и предложить альтернативу было вполне реально, особенно учитывая, что некоторые сотрудники предпочли Git и успешно с ней работают. Значит, дело за малым – наглядно показать, в чем же преимущества работы с децентрализованными системами контроля версий: Git или Mercurial, но, в силу моего личного опыта, рассказать я решил про Hg. Собственно, эта статья есть краткое содержание круглого стола, проведенного мной с целью сравнения и смены системы контроля версий.
Однако, на новом месте работы мне снова пришлось вспомнить о Subversion, что, честно сказать, меня не обрадовало. К счастью, это не было безоговорочной политикой компании и предложить альтернативу было вполне реально, особенно учитывая, что некоторые сотрудники предпочли Git и успешно с ней работают. Значит, дело за малым – наглядно показать, в чем же преимущества работы с децентрализованными системами контроля версий: Git или Mercurial, но, в силу моего личного опыта, рассказать я решил про Hg. Собственно, эта статья есть краткое содержание круглого стола, проведенного мной с целью сравнения и смены системы контроля версий.
Вариант организации контроля версий ПО для аппаратов с множеством сетевых устройств на борту
5 мин
Хочу поделиться некоторыми идеями по поводу организации хранилищ в системе контроля версий. Для определенности: мы используем Меркуриал, но это не столь важно.
В двух словах о задаче. Одновременно ведется несколько проектов. Под проектами понимаются аппараты с цифровыми устройствами на борту (десятки устройств), объединенными в сеть. Речь идет о программном обеспечении бортовых устройств, которое нужно отслеживать с помощью системы контроля версий.
Есть бортовые устройства, одинаковые для разных аппаратов, а есть и специфические. Устройства могут программироваться разными разработчиками, а некоторые из устройств программируют контрагенты. Марки процессоров (контроллеров) бортовых устройств различаются. В разных устройствах могут использоваться одинаковые библиотеки: драйверов, математики и пр.
Разработчики много времени проводят в командировках (на испытаниях), где оперативно нужно менять код и обмениваться обновлениями по Интернету.
Сейчас представляется удивительным, что такая работа проводилась без системы контроля версий. Возможно это удавалось потому, что проектов было не так много, а разработчиков всего двое. Но дальше так продолжаться дело уже не может.
Мы сформировали концепцию контроля версий и потихоньку начинаем рефакторинг проектов в русле данной концепции. Пока мы в начале пути, найденные решения нам нравятся, но возможно не видим всех подводных камней и можем поплатиться за это в будущем. Надеемся, что рекомендации читателей помогут исправить ошибки, пока мы не зашли очень далеко.
В двух словах о задаче. Одновременно ведется несколько проектов. Под проектами понимаются аппараты с цифровыми устройствами на борту (десятки устройств), объединенными в сеть. Речь идет о программном обеспечении бортовых устройств, которое нужно отслеживать с помощью системы контроля версий.
Есть бортовые устройства, одинаковые для разных аппаратов, а есть и специфические. Устройства могут программироваться разными разработчиками, а некоторые из устройств программируют контрагенты. Марки процессоров (контроллеров) бортовых устройств различаются. В разных устройствах могут использоваться одинаковые библиотеки: драйверов, математики и пр.
Разработчики много времени проводят в командировках (на испытаниях), где оперативно нужно менять код и обмениваться обновлениями по Интернету.
Сейчас представляется удивительным, что такая работа проводилась без системы контроля версий. Возможно это удавалось потому, что проектов было не так много, а разработчиков всего двое. Но дальше так продолжаться дело уже не может.
Мы сформировали концепцию контроля версий и потихоньку начинаем рефакторинг проектов в русле данной концепции. Пока мы в начале пути, найденные решения нам нравятся, но возможно не видим всех подводных камней и можем поплатиться за это в будущем. Надеемся, что рекомендации читателей помогут исправить ошибки, пока мы не зашли очень далеко.
Как развернуть систему контроля версий (VCS) без командной строки
8 мин
Recovery mode
Так как наша команда программистов ведет разработку сразу несколько проектов, довольно быстро возникла необходимость в системе контроля версий.
Естественно, поиски были начаты с изучения Хабра — и привели к неожиданному результату. Несмотря на то, что системы контроля версий появились ещё в 1986 году, большинство туториалов по работе с современными системами контроля версий оказались неполными и сильно завязанными на работу с командной строкой.
Мы ничего не имеем против командной строки в целом, но в нашей небольшой команде разработчиков (4 человека) фанатов работы с командной строкой нет :).
Почему мы считаем, что работа с командной строкой неэффективна?
- Трата времени на ввод данных. Набивать команды намного дольше, чем кликать мышкой.
- Трата времени на обучение. Изучение нового синтаксиса в эпоху понятных интерфейсов однозначно дольше, чем обучение графическому интерфейсу.
- Вероятность ошибки. Ошибиться при вводе данных через командную строку легче (человеческий фактор никто не отменял).
- Нарушение принципов автоматизации. Возможно, это самый главный пункт. Компьютер создан для ускорения работы и замене человека при выполнении рутинных операций. В случае с командной строкой мы всегда работаем вручную, по сути, приходится каждый раз писать один и тот же программный код (пусть и примитивный).
К сожалению, нам не удалось найти полноценного русскоязычного мануала по работе с современными системами контроля версий. Собрав информацию из разных статей и англоязычных видео на YouTube, мы решили сделать своё собственное руководство, которое:
- Будет пошаговой инструкций (по ней же будут работать наши программисты).
- Будет работать от начала и до конца (то есть по ней вы получите небольшой, но законченный результат — работающую распределенную систему контроля версий).
- Будет работать с использованием только графических интерфейсов (причины см. выше).
Изучение структуры папок проекта в Unity — системы контроля версий
4 мин
Туториал
Добрый вечер хабрчане, решил перевести один единственный урок из раздела Архитектура — MASTERING UNITY PROJECT FOLDER STRUCTURE — VERSION CONTROL SYSTEMS на официальном сайте Unity. В самом конце статья немного модифицирована, была изменена настройка проекта VCS (Version Control System).
P.S для тех кто только знакомится с Unity3d и предпочитает видеоуроки советую ознакомится с официальными видеоуроками для новичка на русском языке.
В этом уроке я хочу пролить немного света на:
— Структуру папок проекта в Unity.
— Какие папки и файлы необходимы для систем контроля версий (VCS).
P.S для тех кто только знакомится с Unity3d и предпочитает видеоуроки советую ознакомится с официальными видеоуроками для новичка на русском языке.
В этом уроке я хочу пролить немного света на:
— Структуру папок проекта в Unity.
— Какие папки и файлы необходимы для систем контроля версий (VCS).
Масштабирование Git (и кое-какая предыстория)
10 мин
Перевод
Несколько лет назад Microsoft приняла решение начать долгий процесс по восстановлению системы разработки во всей компании. Мы большая компания, с множеством коллективов — у каждого собственные продукты, приоритеты, процессы и инструменты. Есть некоторые «общие» инструменты, но их много разных — и ОЧЕНЬ БОЛЬШОЕ количество разработанных внутри компании инструментов одноразового использования (под коллективами я имею в виду подразделения — тысячи инженеров).
У этого есть отрицательные стороны:
- Множество избыточных инвестиций в коллективы, которые разрабатывают похожие инструменты.
- Невозможность финансировать какой-либо инструментарий до «критической массы».
- Затруднения для сотрудников в перемещении по компании из-за разных инструментов и процесса.
- Сложность в обмене кодом между организациями.
- Разногласия с новичками в начале работы из-за чрезмерного изобилия инструментов «только для MS».
- И так далее...
Введение в Git Merge и Git Rebase: зачем и когда их использовать
4 мин
Recovery mode
Перевод
Часто у разработчиков возникает выбор между Merge (слияние) и Rebase (перемещение). В Гугле вы увидите разное мнение, многие советуют не использовать Rebase, так как это может вызвать серьезные проблемы. В статье я объясню, что такое слияние и перемещение, почему вы должны (или не должны) использовать их и как это сделать.
Git Merge и Git Rebase преследуют одну и ту же цель. Они предназначены для интеграции изменений из одной ветки в другую. Хотя конечная цель одинаковая, принципы работы разные.
Некоторые считают, что вы всегда должны использовать Rebase, другие предпочитают Merge. В этом есть свои плюсы и минусы.
Слияние — обычная практика для разработчиков, использующих системы контроля версий. Независимо от того, созданы ли ветки для тестирования, исправления ошибок или по другим причинам, слияние фиксирует изменения в другом месте. Слияние принимает содержимое ветки источника и объединяет их с целевой веткой. В этом процессе изменяется только целевая ветка. История исходных веток остается неизменной.
Git Merge и Git Rebase преследуют одну и ту же цель. Они предназначены для интеграции изменений из одной ветки в другую. Хотя конечная цель одинаковая, принципы работы разные.
Некоторые считают, что вы всегда должны использовать Rebase, другие предпочитают Merge. В этом есть свои плюсы и минусы.
Git Merge
Слияние — обычная практика для разработчиков, использующих системы контроля версий. Независимо от того, созданы ли ветки для тестирования, исправления ошибок или по другим причинам, слияние фиксирует изменения в другом месте. Слияние принимает содержимое ветки источника и объединяет их с целевой веткой. В этом процессе изменяется только целевая ветка. История исходных веток остается неизменной.
Система контроля версий для hardware или чем на самом деле должен заниматься отдел стандартизации
9 мин
До 2020 года я работал конструктором (разрабатывал электронику и электрику). Сейчас я сменил сферу деятельности, но считаю важным поднять вопрос, который возник в свое время пока он совсем не выветрился из головы. В статье затронута важность разработки стандартов в команде hardware разработчиков, а также приведен пример одного из стандартов для ведения репозитория для сборку.
Git Submodule иногда ломаются, как их починить?
5 мин
Recovery mode
Наверняка если вы начали читать эту статью, то знаете, что такое git и для чего он нужен. НО не все используют такую интересную функциональность в git как submodules.
Это дает возможность прицепить к вашему проекту другие проекты и переиспользовать их в вашем. Для примера рассмотрим такую историю.
Есть репозиторий, в котором содержится groovy скрипт, который решает задачу по извлечению из системы хранения чувствительных данных Vault.
Эмоциональный код
19 мин
Перевод
Я зарабатываю программированием с 1979 года, и большую часть этого времени мне приходится работать с чужим кодом. Поначалу было: "Добавьте эту маленькую функцию к тому, что у нас уже есть". Теперь — "как мы можем стать лучше" и " стоит ли сохранять данный код?". Прочтение кода всегда было огромной составляющей в моей работе, и по этой причине для меня очень важно, какой код пишу я (и люди, с которыми работаю). Конечно, хочется, чтобы он был быстрым — в конце концов, я программист на C++. Кроме того, он должен быть корректным. Но есть нечто большее, помимо этих двух вещей: я хочу, чтобы код был читабельным, понятным, разумным и даже приятным.