Рубрика «система контроля версий»

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

image

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

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

Git Merge

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

Масштабирование Git (и кое-какая предыстория) - 1
Несколько лет назад Microsoft приняла решение начать долгий процесс по восстановлению системы разработки во всей компании. Мы большая компания, с множеством коллективов — у каждого собственные продукты, приоритеты, процессы и инструменты. Есть некоторые «общие» инструменты, но их много разных — и ОЧЕНЬ БОЛЬШОЕ количество разработанных внутри компании инструментов одноразового использования (под коллективами я имею в виду подразделения — тысячи инженеров).

У этого есть отрицательные стороны:

  1. Множество избыточных инвестиций в коллективы, которые разрабатывают похожие инструменты.
  2. Невозможность финансировать какой-либо инструментарий до «критической массы».
  3. Затруднения для сотрудников в перемещении по компании из-за разных инструментов и процесса.
  4. Сложность в обмене кодом между организациями.
  5. Разногласия с новичками в начале работы из-за чрезмерного изобилия инструментов «только для MS».
  6. И так далее...

Читать полностью »

Добрый вечер читатели, решил перевести один единственный урок из раздела Архитектура — MASTERING UNITY PROJECT FOLDER STRUCTURE — VERSION CONTROL SYSTEMS на официальном сайте Unity. В самом конце статья немного модифицирована, была изменена настройка проекта VCS (Version Control System).

P.S для тех кто только знакомится с Unity3d и предпочитает видеоуроки советую ознакомится с официальными видеоуроками для новичка на русском языке.

В этом уроке я хочу пролить немного света на:
— Структуру папок проекта в Unity.
— Какие папки и файлы необходимы для систем контроля версий (VCS).
Читать полностью »

Bitbucket + Eclipse. Инструкция по настройке от А до Я.

После перехода с Windows на Linux и установки Eclipse 4.3 Kepler у меня появилась необходимость добавления своего приложения для Android в систему контроля версий. Разрабатываю я его пока один и контроль версий нужен, чтобы видеть историю изменений и иметь возможность откатиться на более раннюю версию, плюс это хорошее и удобное резервное копирование проекта.
Решение данной задачи я собирал в нескольких местах, после чего родилась идея написать подробное руководство.
Делать свой первый проект открытым я пока не планировал, поэтому вместо популярного GitHub выбрал Bitbucket. Он позволяет делать любое кол-во открытых и закрытых репозиториев совершенно бесплатно.
Отмечу, что в инструкции очень много скриншотов!
Читать полностью »

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

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

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

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

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

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

Читать полностью »

Мое первое знакомство с системой контроля версий было еще в школе. Это был Subversion. В то время меня очень впечатлила его сила и возможности. Но шло время. Были не очень приятные моменты с переименовыванием файлов, каталогов и прочее (да, да здравствует svn 1.5, 1.6 и его вечные папки .svn). И все бы продолжалось в том же духе, если бы однажды в компании не задумались о смене системы контроля версий. Все случилось неожиданно быстро и предо мной возник Mercurial. Пришлось почитать о его особенностях, поспрашивать советов бывалых и вот я уже сам помогал своим коллегам разобраться в поведении и работе нового инструмента. Чем дольше я знакомился с Hg, тем больше он мне нравился, точнее, нравился его децентрализованный подход к контролю версий, Subversion же неизбежно отходил на второй план.
Однако, на новом месте работы мне снова пришлось вспомнить о Subversion, что, честно сказать, меня не обрадовало. К счастью, это не было безоговорочной политикой компании и предложить альтернативу было вполне реально, особенно учитывая, что некоторые сотрудники предпочли Git и успешно с ней работают. Значит, дело за малым – наглядно показать, в чем же преимущества работы с децентрализованными системами контроля версий: Git или Mercurial, но, в силу моего личного опыта, рассказать я решил про Hg. Собственно, эта статья есть краткое содержание круглого стола, проведенного мной с целью сравнения и смены системы контроля версий.
Читать полностью »

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

Одним словом Pixelapse — это GitHub для дизайнеров.

image

Коротко о возможностях:

  • Сравнение двух и более версий, путем расположения их рядом друг с другом или методом наложения. Прикольная штука, своеобразный графический merge в браузере, быстрый и удобный.
  • В комментариях можно ссылаться на конкретные версии и на пользователей,Читать полностью »

https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js