• О культуре разработки в группах программистов
    0
    Отличная статья, со многим соглашусь. Будет ли продолжение? Описанные подходы выглядят как первые шаги. В том плане, что в цикле forming-storming-norming-performing эти активности позволяют удержать контроль на первых двух этапах (конечно особенно сложных). Интересно было бы поделиться также механиками на терьем и четвертом :)
  • Comment from a drafted post.
  • IMHO, как писать на Хабр
    +6
    А что развлекательное не может быть полезным? Это же целый жанр — развлекательно-позновательное.
  • Интервальное повторение на LinguaLeo
    +7
    Тут тонкий момент, кто сможет гарантировать что синоним – это не действительно одно из значений перевода?

    Допустим у слова slightly есть следующий список значений: мало, незначительно, несущественно, немного, слегка; еле-еле; едва; слабо. Мы допустим выбираем запутыващий синоним "чуть-чуть" и реальное значение "еле-еле", вас такой выбор устроит? Устроит ли что "чуть-чуть" будет засчитан как неверный ответ?

    Тут скорее должен браться не синоним, но похожее слово, например – warm: теплое или мягкое? (теплое и мягкое – не синонимы).
  • Притворитесь умным
    0
    окей, ломом?
  • Притворитесь умным
    +1
    Мне кажется, если владельцы квартиры не пускают, надо попроситься к соседям и разбить шваброй высунувшись из соседнего окна.
  • Хабр, знакомься — новый LinguaLeo с персональной системой обучения иностранному языку
    +1
    Он остался, поменялся критерий — теперь нужно не тренировку пройти, а накормить лео на 100% тогда будет выведено сообщение на дашборде. Скоро вернем и виджет.
  • О том, как стартап может вылететь из индекса в одночасье
    0
    Насколько я понял редирект был только для роботов:
    техподдержка сообщила о том, что наш основной домен отдает 301-ый редирект для поисковых роботов на адрес комовского сайта-паразита
  • Прокачай английский с LinguaLeo: cоздавай тематические словари, тренируй память и занимайся в группе!
    +1
    Ручной возврат есть. Нужно перейти в словарь, выбрать слова например за Июль 2012 и отправить на тренировки снова:

    Скриншот
    image
  • Прокачай английский с LinguaLeo: cоздавай тематические словари, тренируй память и занимайся в группе!
    0
    Не очень понял, что для вас было бы ключевым, возможность группировать слова по статьям или добавлять слова в словарь из статей? Для первого у нас есть механизм наборов слов в словаре, для второго — плагины для браузеров. Вы пробовали эти инструменты?
  • Git Rebase: руководство по использованию
    0
    Я думаю, вам будет интересно почитать эту ветку обсуждений habrahabr.ru/post/161009/?reply_to=6933652#comment_5547341 :)
  • Еще одни часы на газоразрядных индикаторах
    0
    На e-bay за них дадут приличную цену, особенно учитывая, что таблички на английском
  • 300 миллионов пользователей и переход на WebKit
    0
    В знак солидароности с компанией Opera перехожу с Хрома на нее :)
  • Диалоги на английском — знакомьтесь, общайтесь и повышайте уровень языка!
    0
    а в чем разница между терминами и оборотами, когда речь идет о знаниях? Кто-то умеет passive voice использовать, а кто-то умеет правильно времена группы continuous использовать.
  • Диалоги на английском — знакомьтесь, общайтесь и повышайте уровень языка!
    0
    Даже нубы могут друг друга поправлять, так как обладают во многом не пересекающимися знаниями.
    Кстати можно фильтровать по уровню знания языка (правда пользователь его определяет для себя сам).
  • Mozilla — разработчикам: «если не хотите платить 30%-й налог, Firefox OS вам понравится!» Включите в свои планы открытую альтернативу iOS и Android!
    0
    А разве задача в унификации? mozilla просто хочет свою часть рынка мобильных пользователей.
  • Git Rebase: руководство по использованию
    0
    Спасибо! Отличное замечание. Чуть позже добавлю в текст самой статьи.
  • Git Rebase: руководство по использованию
    0
    А вы распечатайте для начала эту и эту картинки и повесьте на стену. А лучше перерисуйте, а то у меня руки не очень прямые, да и цвета какие-то не очень выразительные вышли. Мне кажется такие вот «комиксы» куда наглядней, чем таблички.
  • Git Rebase: руководство по использованию
    0
    Именно это я и хотел сказать — причем «паттерны» — это как бы частички вашего собственного опыта, а не вычитаные где-то рецепты. То есть их конечно можно вычитать, но понимать что и как именно они делают все равно надо, иначе если произойдет что-то непредвиденное разобраться самостоятельно будет крайне трудно. :)
  • Git Rebase: руководство по использованию
    0
    Спасибо, сейчас исправлю, писал по памяти.
  • Git Rebase: руководство по использованию
    0
    Race condition фактически есть, но реально, это надуманная проблема — если я с кем-то работаю в одной ветке — значит я много общаюсь с ними, постоянно делюсь кодом, обсуждаю архитектуру. Ничего не мешает договориться о моменте ребейза и зафризить ветку — это конечно хак за пределами SCM, но мне при работе в общей ветке не приходилось сталкиваться с race condition. Насчет того пропадет ли «гоночный» коммит при ребейзе — надо поставить эксперимент — в теории выглядит именно так, но надо бы убедиться — поэкспериментирую на досуге.
  • Git Rebase: руководство по использованию
    0
    Дайте им ее почитать, вдруг они проникнутся. ;)
  • Git Rebase: руководство по использованию
    +2
    Git pull — rebase конечно не делает git pull и git rebase, так как git pull — это fetch & merge, а git pull --rebase — это fetch & rebase. Кроме того нужно понимать, что когда удаленная ветка ребейзена и вы делаете git pull --rebase базовый коммит — это не общий коммит в ветках feature и origin/feature, а первый незапушенный вами (то есть локальный) коммит. Линейка локальных коммитов, которая перемещается при git pull --rebase, легко конвертится в серию патчей, которые можно накатить, что бы с веткой не происходило — rebase, squash, такую серию патчей можно накатить куда угодно, поэтому я не понимаю, почему все так боятся ребейзить удаленные ветки.

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

    Не надо придумывать никаких универсальных административных политик. Цель статьи — чтобы после прочтения стало понятно, как физически работает rebase в описанных ситуациях. Владея этим знанием нужно применять их по обстоятельствам, а не по своду каких-то магических методик. Если у меня 1 локальное изменение и я взял git pull и сижу правлю огромное количество конфликтов в коде, который я даже не трогал — что-то тут пошло не так, да? Наверно нужно откатиться и взять git pull --rebase.

    Нет никаких солюшенов и сводов правил, есть вы и git, некий набор инструментов в рамках гита и ваше умение ими пользоваться.
  • Git Rebase: руководство по использованию
    0
    Правда? Пока проблем не обнаружено. Со вторичными тематическими ветками не пробовал но шаренные ветки ребейзил. git pull --rebase вытягивает новую ветку и перемещает локальные коммиты наверх. Да и git help pull говорит:

    --rebase
    Rebase the current branch on top of the upstream branch after fetching. If there is a remote-tracking branch corresponding to the upstream branch and the upstream branch was rebased
    since last fetched
    , the rebase uses that information to avoid rebasing non-local changes.


    Что намекает, что это допустимая ситуация. Возможно в более ранних версиях гита это был грязный трюк, но сейчас это вполне работает.
  • Git Rebase: руководство по использованию
    +1
    А вот еще классный вариант придумал — не делать фичу 3 пока не сделаны первые две. Сложно писать код на такой зыбкой почве как две динамично меняющиеся кодовые базы совместимость которых тестится только у меня в бранче. Ну и да декомпозиция задач 1 и 2 на более мелкие может облегчить этот процесс за счет того, что каждый этап занимает меньше времени и по сути делается в отдельной ветке (может с тем же названием, может «новая» ветка — продолжение отребейзенной старой)
  • Git Rebase: руководство по использованию
    +2
    У вас тут есть одно внутреннее противоречие из-за которого все проблемы:
    — ветки 1 и 2 должны вестись изолировано
    — ветка 3 должна содержать объединенные изменения из ветки 1 и 2.
    Отсюда следует, что эти изменения не могут храниться в одних и тех же коммитах. Два выхода:
    1. Либо изменения приезжают в ветку 3 с помощью мерджа и храняться в мердж-коммитах — запутываем граф.
    2. Либо изменения из веток 1 и 2 дублируются в других коммитах — в ветке три — их можно переносить туда cherry-pick-ом, но тогда готовьтесь к конфликтам и дублированию пикнутых коммитов при интеграции ветки 3 в мастер, в который уже проинтегрированы ветки 1 и 2. Ну и черрипик не слишком быстрая операция так как предполагает много ручной работы.
    3. Либо вам надо отказаться от полной изолированности ветки 1 и 2, то есть когда ветки 1 и 2 готовы к интеграции в ветку 3 они склеиваются ребейзом до текущего состояния (можно пометить его веткой release) и далее снова разрабатываются изолировано. Ветка 3 ребейзится на состояние release.

    Третий вариант я не посчитал, так как он нарушает одно из входящих условий
  • Git Rebase: руководство по использованию
    0
    Стойте, а код из ветки 1 в ветку 2 не может попадать? То есть изменения объединяются только в ветке 3?
  • Git Rebase: руководство по использованию
    0
    Можно ли разбить фичи 1 и 2 на этапы? Например после завершения определенной работы в ветке 1 и 2 они готовы к вливанию в 3? В каком порядке фичи будут мерджиться в мастер заранее известно или по готовности? Может вам стоит пилить общий для всех этих 3 веток функционал в базовой ветке, относительно которой ребейзить все эти три фиче-ветки? И там уже тестировать перед вливанием в мастер?

    Мне что-то то кажется что между вашими тремя ветками и мастером должна быть промежуточная ветка в которую вы вливаете изменения из этих трех.
  • Git Rebase: руководство по использованию
    0
    Реально сложная задача, может она неправильно поставлена? Почему все три фичи не могут делаться в одной ветке если они так тесно взаимосвязаны?
  • Git Rebase: руководство по использованию
    0
    Что мешает ребейзенную ветку влить в мастер merge-ем с опцией --no-ff? Выйдет тоже самое, не?
  • Git Rebase: руководство по использованию
    0
    Да, тогда конечно squash тут не поможет не думал о такое ситуации.
  • Git Rebase: руководство по использованию
    0
    Почитал про fixup, спасибо за наводку!
  • Git Rebase: руководство по использованию
    0
    И пока вы работаете в ветке вы не переключаетесь на другую ветку? Или все-таки у вас БД столько же сколько веток (или она редко меняется, или изменения непротиворечащие). А зачем вам ветки в таком случае вообще? :)
  • Git Rebase: руководство по использованию
    0
    Опять вы говорите о merge как об операции наложения изменений. Git merge тоже основан на merge. Git stash apply тоже основан на merge. Только споры обычно идут операции git merge, а точнее о том, стоит ли перед ней делать git rebase или нет. А еще о том, как подливать кодовую базу в тематическую ветку — через перебазирование самой ветки или через слияние изменений. Спасибо за интересную беседу anyway. У меня до ковыряния в сорцах гита еще не доходило.
  • Git Rebase: руководство по использованию
    0
    Да не обязательно апи, схема бд может поменяться например, или у вас для каждой ветки своя БД развернута?
  • Git Rebase: руководство по использованию
    0
    >> Исполнителю опять нужно идти и ребазировать-решать конфликты
    А при мердже этого делать разве не надо в такой ситуации? :) Тут проблема не merge или rebase — проблема в самой ситуации. Код устаревает постоянно пока не влит в мастер. После вливания в мастер код заставляет устаревать другой код, еще не влитый в мастер. Это жизнь.
  • Git Rebase: руководство по использованию
    +1
    Большое спасибо за ссылку, к сожалею не могу сейчас почитать — отложил в закладки. Не пойму, почему на них нельзя откатиться? Можно. Код не будет работать? Да возможно. Семантический конфликт? Это за пределами системы контроля версий.

    Теряется смысл контроля версий из-за семантического конфликта? А часто вы деплоите приложение из тематической ветки? :) Вы рассматриваете именно конфликтные ситуации — в случае если изменения в разных модулях например — то всего этого нет, так?

    А семантический конфликт разве не возможен при обычном merge? Не было такого что после подливания мастера ваш код ломался? Ну там функцию в api выпили например в мастере. Rebase — физический уровень манипуляции коммитами, он не защищает и не провоцирует семантические конфликты.

    То что теряется старая ветка легко поправимо — если после ребейза сломалась ветка, а вам надо срочно сделать демонстрацию заказчику — можно сделать git reset --hard на коммит E (на него указывает ORIG_HEAD и его можно увидеть в git log --all. Ребейз можно отложить. Я не говорю о том, что мол rebase — золотая пуля. Это просто инструмент который может быть полезен.

    Если делать ребейз периодически то фикс семантики можно делать не только в конце — а деплоиться на промежуточные версии (на мой взгляд) бессмысленно. Смысл системы контроля версий на мой взгляд не теряется. И кстати а «посмотреть» разве не входит в задачи scm? Code review, например, провести вполне можно.

    Все ваши утверждения верны, тут вопрос в отношении к этим фактам и стилю работы с кодом, а также задачами, которые в каждом конкретном случае вы ставите перед scm.
  • Git Rebase: руководство по использованию
    +2
    Прочитайте пожалуйста мой коммент. Очень надеюсь, что он поможет понять почему стрелки нарисованы именно так, а не иначе.
  • Git Rebase: руководство по использованию
    +2
    Это если трактовать стрелку как действие. Тут стрелки отображают структуру данных (ну вы наверняка в универе рисовали односвязные списки, можно считать, что это они).
  • Git Rebase: руководство по использованию
    +1
    Сорри, не убедили. Вырванный из контекста кусок кода мне, к сожалению, ничего не доказывает. do_recursive_merge — просто наложение изменений на дерево проекта (наложение диффа), про try_merge_command — не могу сказать про что, некогда ковырять. Я говорил о merge как о команде гита, которая создает коммит с двумя родителями. По вашей логике patch — тоже merge. Если вы это и имели ввиду — то ок, спор чисто терминологический и мы друг друга просто недопоняли.

    Если вы считаете что rebase или cherry-pick можно разложить на несколько мерджей (в моей терминологии), попробуйте это в двух словах сделать.