Idera Inc покупает Embarcadero Technologies

   Слухи о том, что компания Idera, Inc покупает компанию Embarcadero Technologies, которые появились на форумах и в блогах в середине сентября подтвердились. Вчера инвестиционная компания Thoma Bravo, LLC опубликовала об этом событии свой пресс-релиз. А немного позже был опубликован и официальный пресс-релиз «Idera Announces Intent to Acquire Embarcadero, Expands Position in Database Management and Developer Tools Markets«.
   Вот и закончился семилетний период жизни нашего любимого Delphi в компании Embarcadero Technologies. За это время было сделано 11 релизов Delphi:

  • Delphi 2009 (25 августа 2008) — полная поддержка unicode; новые элементы языков программирования (например, Generics); обновление VCL…
  • Delphi 2010 (25 августа 2009) — повышение производительности; поддержка Windows 7 API, Direct2D и мультисенсорного ввода; IDE Insight; расширение RTTI…
  • Delphi XE (30 августа 2010) – новые возможности VCL, RTL и Open Tools API; доработки в редакторе кода; обновление DataSnap…
  • Delphi XE2 (1 сентября 2011) – поддержка Windows 64, Mac OS X и iOS; кросс-платформенная библиотека FireMonkey; библиотека LiveBindings; улучшения в технологии DataSnap…
  • Delphi XE3 (3 сентября 2012) – поддержка Windows 8; улучшенная поддержка Apple Mac OS X; Firemonkey 2/FM²; удалена поддержка iOS…
  • Delphi XE4 (22 апреля 2013 ) – вернулась поддержка iOS; функционал для разработки мобильных приложений (iPhone и iPad); улучшено взаимодействие с базами данных…
  • Delphi XE5 (11 сентября 2013) — поддержка разработки ПО для устройств с архитектурой ARM, работающих под управлением Android…
  • Delphi XE6 (15 апреля 2014) — исправлены сотни ошибок; новые компоненты (Application Tethering Components, Taskbar component, компоненты для работы с датчиками (акселерометр, GPS и гироскоп)…), взаимодействие с сервисами в облаках (BaaS); возможность создания приложений для Google Glass; новые иконки в IDE…
  • Delphi XE7 (2 сентября 2014) – изменения в RTL и FireMonkey, удалены компоненты для работы с BDE…
  • Delphi XE8 (7 апреля 2015) — поддержка iOS 64; в IDE интегрирована новая система контроля версий Mercurial Version Control System; добавлены два новых независящих от платформы типа данных (FixedInt и FixedUInt)…
  • Delphi 10 Seattle (31 августа 2015) — поддержка Windows 10, iOS 8.4, Android 5.1.1, API WinRT, DirectX 12; новые компоненты…

Как видите, программисты компании Embarcadero трудились над развитием Delphi в стиле «ни дня без строчки», т.е. «ни года без релиза». Для сравнения компания Borland за 13 лет (с 1995-го по 2008-й), если не считать «мертворожденных» Kylix и Delphi 8.NET, были сделаны всего 10 резов Delphi. Хотя авторство Delphi 2009 спорно, т.к. эта версия была выпущена Embarcadero всего через несколько месяцев после покупки компании Borland. По большому счету, не важно, какая компания разрабатывает Delphi (скорбим только о Borland). Важно то, чтобы команда разработчиков Delphi дружной толпой, не снижая набранного темпа, продолжила работу над своим проектом под крышей Idera, а компания Idera уделяла больше внимания и средств на дальнейшее развитие и продвижение Delphi.

Читать на сайте автора.

App Indexing для начинающих

С недавнего времени компания Google позволяет связывать содержимое сайтов и мобильные приложения на Android и IOS при помощи технологии App Indexing .

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

Например, вы искали какую-нибудь страничку с интернет банком (рекламное место), а при поиске вам сразу же предложили мобильное приложение этого банка.

Вот тут опубликована отличная документация для веб мастеров (а вот тут для Android  разработчиков).

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

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

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

1. Изменения в приложении.

Для пробрасывания контекста, в приложение есть специальный инструмент App Indexing API .

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

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

Вот измененный код фильтров намерений в начальной активности для добавления в манифест приложения :

<intent-filter android:label="@string/filter_title_viewrusdelphi">
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
    <!-- Accepts URIs that begin with "example://gizmos” -->
    <data android:scheme="rusdelphi"
        android:host="app" />
</intent-filter>

<intent-filter android:label="@string/filter_title_viewrusdelphi">
    <action android:name="android.intent.action.VIEW" />
    <!-- Accepts URIs that begin with "http://example.com/gizmos” -->
    <data
        android:host="rusdelphi.com"
        android:pathPrefix="/app"
        android:scheme="http" />

    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
</intent-filter>

В примере приведен сайт http://example.com/gizmos, а мы его переписали на наш rusdelphi.com/app.

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

Проверим наше приложение при помощи команд adb :

adb shell am start -a android.intent.action.VIEW -d "http://rusdelphi.com/app" com.rusdelphi.wifipassword
adb shell am start -a android.intent.action.VIEW -d "rusdelphi://app" com.rusdelphi.wifipassword

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

Снимок

2. Подтверждение сайта в консоли разработчика.

В консоли разработчика нужно подтвердить наш сайт. Для это заходим во вкладку приложения -> Службы и Api -> ИНДЕКСИРОВАНИЕ ПРИЛОЖЕНИЙ GOOGLE ПОИСКОМ

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

3. Размещение ссылок на сайте.

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

<link rel="alternate" href="android-app://com.rusdelphi.wifipassword/rusdelphi/app" />

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

Screenshot_2015-09-29-12-45-32

 

 

Читать на сайте автора.

Блокировка перерисовки окна на время обновления его дочерних окон

Открыл для себя сообщение WM_SETREDRAW. Позволяет на какое-то время отключить перерисовку контрола (окна), тем самым избавить пользователя от лишних мерцаний, эффекта шлейфа и тому подобного. Применил в своём сплиттере, теперь при изменении размеров – красота. Сравните две анимашки (т.к. это gif – сохранил в оттенках серого, иначе появляются цветовые артефакты).

До применения WM_SETREDRAW:

before_gs

Здесь прекрасно видно, что панель слева от сплиттера не успевает отрисовываться (да и правая отстаёт).

А это уже после обрамления кода по изменению ширины AlignControl’а в WM_SETREDRAW:

after_gs

 

Обрамление в коде выглядит вот так:

var
  LLockPaint: Boolean;
begin
    LLockPaint := Parent.HandleAllocated and Parent.Visible;
    if LLockPaint then
      SendMessage(Parent.Handle, WM_SETREDRAW, 0, 0);
    try
      // код по изменению размеров контролов
    finally
      if LLockPaint then
      begin
        SendMessage(Parent.Handle, WM_SETREDRAW, 1, 0);
        RedrawWindow(Parent.Handle, nil, 0, RDW_INVALIDATE or RDW_UPDATENOW or RDW_ALLCHILDREN);
      end;
    end;
end;

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

Эту технику можно применять в тех случаях, когда в одном окне необходимо перерасположить несколько контролов. Ну как пример, когда в IDE меняется Layout (Desktop speedsetting) – без блокировки рисования пользователь видит неприятные мерцания.

И ещё одно важное замечание: WM_SETREDRAW меняет видимость окна (оно как бы скрывается, но при этом область под окном – не перерисовывается). И если окно уже было скрыто, то оно может быть ошибочно отображено (и наоборот), поэтому не забывайте проверять этот момент.

Читать на сайте автора.

Delphi Notes Splitter обновлён (v1.09)

По этой ссылке можно перейти на страницу с заметкой о компоненте и ссылкой на исходник.
Версия 1.07.
Версия 1.08.

В новой версии:

(*) Метод UpdateControlSize обрамлён сообщением WM_SETREDRAW для плавного изменения размеров компонент, окружающих сплиттер

Ссылка для скачивания: Исходник компонента + исходник демо приложения + скомпилированное демо (zip-архив 216 К)
В следующей заметке расскажу чуть более подробнее о WM_SETREDRAW и там будет наглядный пример.

Читать на сайте автора.

Изменение курсора и автоматическое восстановление при выходе из метода

Не знаю как у вас, а у меня коде (vcl приложение) полным-полно таких конструкций: var tmpOldCursor: TCursor; begin tmpOldCursor := Screen.Cursor; try Screen.Cursor := crHourglass;

Читать на сайте автора.

Изменение курсора и автоматическое восстановление при выходе из метода

Не знаю как у вас, а у меня коде (vcl приложение) полным-полно таких конструкций:

var
tmpOldCursor: TCursor;
begin
tmpOldCursor := Screen.Cursor;
try
Screen.Cursor := crHourglass;
// код который может работать относительно долго
// например, выполнять запрос в БД
finally
Screen.Cursor := tmpOldCursor;
end;
end;

И мне это надоело. По двум причинам:

увеличение размера модулей — по 8 строк кода на каждый такой случай

разбухание секции uses, ведь чтобы это работало нужно в каждый модуль работающий с курсором добавить uses Forms, Controls;

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

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

Читать на сайте автора.

Календарь с подсветкой дней на базе TCalendar без создания нового компонента

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

Читать на сайте автора.

Запись вебинара. Новый подход разработки компонентов FireMonkey в RAD Studio XE8. “Контрол – Модель – Презентация”. Часть 2

Читать на сайте автора.

RAD Studio 10 Seattle

Официальный релиз! Да-да… XE8 -> 10 Seattle 🙂 Сайт: Что нового в RAD Studio 10 Seattle Скачать/купить: RAD Studio 10 Seattle Образы: http://cc.embarcadero.com/Item/30352 или http://cc.embarcadero.com/Item/30353 Справка: What’s New RAD Studio 10

Читать на сайте автора.

Что дал переход с SVN на Git или Git как ключ для синергии хороших практик

    Год назад мы в проекте выполнили переход с SVN на Git. Нас привлекали возможности бранчевания и работы с репозиторием без сети. «Сарафанное радио» регулярно доставляло сообщения о преимуществах модели распределенных систем контроля ревизий. В итоге, переход себя полностью оправдал, и Git раскрыл множество прекрасных возможностей, о которых во время перехода даже не подозревали. Но самое замечательное, что побочным эффектом оказалось поднятие общего уровня и культуры разработки.
   
     В первой части я расскажу о своих ощущениях после перехода на Git.  Если вы уже знакомы с ним, то возможно вам следует перейти сразу ко второй части, где я попытался снизить градус слащавости и пафоса и перейти уже наконец то к делу. Во второй и третьей части я коснусь практических вопросов, которые проливают свет о влияние гита на культуру разработки. 

Дифирамбы Git’у     


    Часто пользователи SVN не видят обоснованных причин для перехода на Git (на самом деле слово Git можно смело заменить на DVCS, однако опыт у меня есть только связанный с Git, потому дальше Git будет мелькать чаще). И в действительности среди плюсов на поверхности лежит лишь концепция распределенности и мифическая легкость ветвления (бранчевания).   Как сказал мой друг, парадокс гита заключается в том, что вначале не можешь понять чем Git хорош, а потом не знаешь как это рассказать. Это надо только прочувствовать. Сухое сравнение разных концепций не всегда убедительно. Многие возможности есть в обоих VCS.  А по некоторым возможностям SVN имеет преимущества. Кто-то скажет, что у них разные области и назначения, но используют то их чаще всего одинаково. Технические аспекты лучше всего смотреть в официальном руководстве для гита https://git-scm.com/book/ru/v1 (на мой взгляд лучшее руководство по гит), поэтому дальше в статье будут ощущения и эмоции. 

     С каждым днем только крепнет уверенность, что уже ничто не заставит вернуться обратно. Сказать честно, вначале было много сомнений, стоит ли игра свеч, а не будет ли это потеря времени? Теперь смело заявляю, что Git это намного больше чем SVN, или VCS в парадигме SVN (sic!).  Система хранения ревизий с точки зрения SVN является просто хранилищем кода и его изменений, преследуя такие простые практические цели как обмен общими файлами проекта, навигация и возможность вернуться к нужной версии или найти виновника и задачу, в рамках которых был поломан продукт. Слышу от оппонентов: «мне Git не нужен, так как я работаю один/у нас нет веток/в гите нельзя работать с бинарными форматами/ гит слишком сложен/ и т.п.»  На самом деле он нужен всем (программистам, дизайнерам он может и не подходить) и вот почему.

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

    Почему  же в гите все это можно обеспечить? Краеугольный камень — это распределенность. Что она дает? Обычно говорят, что распределенность дает возможность работать без подключения к интернету и обмениваться ревизиями минуя центральный репозиторий. Да — это верно. Но не на это я хочу  обратить внимание. Главное, что репозиторий у вас ЛОКАЛЬНЫЙ. Вот именно так: капсом и болдом.  Это позволяет манипулировать ветками и коммитами без опасения повлиять на работу коллег. У нас есть правило, звучащее как «в репозиторий должен попадать только рабочий, целостный код, прошедший ревью». На сколько сложно это правило соблюдать в SVN, на столько легче его соблюдать в гите.
     Что же еще делать в гите легко и является ежедневной рутиной, о чем SVN джедаи могли бы только мечтать?  В Git’e легко создавать ветки, выполнять слияние, манипулировать коммитами. Вам, как заправскому шулеру, ничего не стоит  строить цепочки коммитов, дробить коммиты на более мелкие, менять коммиты местами, менять описание текста коммита и его состав.  Каждая операция требует минимального времени выполнения, никакой передачи данных по сети или копирования каталогов. 
     Ну ок. Все мы уже поняли, что Git хорош как Чак Норис в ковбойской шляпе и из хорошей задачи можно устроить отличный фарш из коммитов. Но зачем? Вот типичные моменты рабочего процесса под Git:
  • Ветки создаются под каждую задачу или просто для проверки какой-либо идеи;
  • Коммиты создаем часто, очень часто. Хотим ли особо акцентировать внимание на изменение в коде либо просто закончили итерацию, на все один ответ — коммит. В Git нет проблемы зафиксировать каждый логический блок изменений в рамках задачи отдельным коммитом. В SVN такое желание приведет к неконсистентному состоянию кода в центральном репозиторие;
  • Увлеклись, написали кучу кода, и вот у нас в одном файле изменения, которые относятся к разным логическим частям? В Git это совершенно не проблема — разные логические части одного файла Git позволяет зафиксировать разными коммитами; 
  • Забыли написать тесты и проверить их работу до написания функционала? Не проблема, пишем тесты и новый коммит вставляем перед коммитом задачи;
  • Хотим отправить изменения в центральный репозиторий, но перед этим избавиться от избытка лишней информации и вместо 15 коммитов, отправить 4 сгруппированных? Все верно — и это не проблема. 
  • Я уже не говорю про классические преимущества DVSC, такие как совместная работа над одной задачей разных членов команды. 
     Звучит как фантастика? Отнюдь — просто обычные будни работы с Git. Когда долго не работаешь с SVN забываешь, что там эти операции не возможны. Гит дает чувство пьянящей свободны, нет практически ничего, что вы не могли бы в нем делать. Все делается очень легко: манипулирование ветками и коммитами напоминает игру. И вы от это получаете удовольствие, потому что все ваши, даже сложные, задумки реализуются, а желания предугадываются.  Ну и конечно вы получается удовольствие от того, что в памяти всегда свежи ощущения от SVN.

Наши практики по работе с репозиторием кода

     Гит добавляет в методологию разработки новые аспекты, которых вовсе не ожидаешь, пока не начнешь его использовать.  Эти аспекты мы раскрывали постепенно, шаг за шагом вводя простые правила:
  
1.    На первом шаге у нас была одна постоянная ветка, бранчи использовались очень эпизодически и не было стабильной версии продукта.  Да и так бывает. Бывало даже так, что одним коммитом фиксировалось сразу несколько задач. С этого мы начинали. 
2. Потом появились ветки SVN (до SVN использовали VSS  и Perforce). SVN — хорошая система. Какое-то время использовали собственную модель бранчевания, потом сдались и перешли на стандартную раскладку trunk, tags, branches. В branches  мы создавали ветки только под большие задачи. Прошло много времени, но я хорошо помню боль и отчаянье от работы с ветками в SVN. Это было долго — долго создавать ветки, долго переключать, долго смотреть лог, а слияния веток превращались в испытание. Но с проблемами можно было мириться, если работать только с долго живущими ветками.
3. А следом появилось ревью кода. Это была практика, которая все перевернула. Сейчас мне сложно представить разработку без ревью.
4. Идеальным дополнением к ревью кода стал Git. Модель Git (DVCS) как нельзя лучше подходит для ревью кода. Следующие пункты раскроют это утверждение.
5.
Первым делом мы ввели правила написания текста коммита. Как писать коммит у нас жестко формализовано. Сами правила начали появляться еще при SVN, но только переход на Git заставил к ним относиться строго. Главное требование гласит: текст коммита обязан содержать мотивацию принятия решений и изменений, присутствующих в коде коммита. Перед выкладыванием на сервер каждая задача проходит ревью кода. Ревью кода выполняется с помощью инструмента CodeReviewer. И вот тут основной момент — ревьюверу задачи должно быть понятно все только на основе информации из коммита: непосредственно кода и текста описания коммита.  Если возникают вопросы, то описание коммита перерабатывается.  Можно найти множество плюсов подобного подхода:
  • Экономия времени. Раньше приходилось  многократно пересказывать и отвечать на одни и те же вопросы, если ревьюверов несколько. 
  • Саморевью и самоконтроль. Описание должно быть убедительное, а знания о проблеме систематизированы.  Часто бывает, то что убедительно в голове, на «бумаге» уже не столь явно. Приходилось сталкиваться с ситуацией, когда написание текста коммита приводило к полной переработке решения. Качественное описание порождает качественное решение.     «Так подожди, это же явно следствие, а не причина, необходимо установить причину», — говорит нам рациональная часть нас, «Так делать нельзя, иначе меня все равно завернут на ревью, а мое позорное описание останется на веки вечные в истории».  Однако если есть какие то условия которые толкают зафиксировать неидеальное решение, лучше их указать в тексте коммита и написать, например, что причиной скверного решения была необходимость закрыть задачу в короткий срок. В будущем люди скажут спасибо и не будут фантазировать, почему именно так было сделано, и смогут выработать наиболее верный подход к проблеме. 
  • История  коммитов теперь стала рассказывать гораздо больше и наиболее востребованную информацию. 

Раньше типичные коммиты были вот такими:

  • + мелкие исправления
  • + исправлена ошибка List index out of bounds(0) связанная с бендами
  • *refactor CreateControl method
  • *fix popup message window drawing
  • +Неблокирующее выполнение SQL-блоков. Задача 12862
  • fix: Определение паскаль операции по незакрытому тэгу <Pascal ; Удаление выборки из кэша при выгрузке библиотеки
  • + Выгрузка библиотек при снятии/установке флага использования кэша метаданны

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

Теперь текст коммита стал вот таким:

«fix: исправить фокусировку на следующию ячейку после нажатия Enter #issue 40436

#Проблема 
Фокус переводился совершенно рандомно, без привязки к группировке колонок и визуальному порядку.

#Причины
В #problem-hash 234816912 в погоне за многострочными записями поломали наш механизм переход по горячим клавишам. 

#Решение
Решено задействовать встроенные в DevExpress методы перехода на следующею ячейку и отказаться от нашей логики, которая была написана для довольно старой версии DevExpress компонентов. Во-первых, в новой используемой версии девэкспресса появились вложенные банды. Похоже по истории изменений версий DevExpress и по их коду, что они и старые баги поправил, которые мы закрывали нашей реализацией. Во-вторых,  не удалось заметить, что DevExpress коллекция VisibleColumns не отсортирована, как написано в комментарии к нашему методу сортировки видимых колонок (проверялась и отсортированность колонок после перемещения их во время выполнения).Переход кнопками»вверх» «вниз» оставлен прежний, так как работает.» 

Бывает получаются и вот такого размера тексты коммита

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

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

6.
Правила оформления задачи в ветках.
Каждую задачу, как правило, можно декомпозировать на несколько шагов. Отделив, например, рефакторинг от непосредственно кода, исправляющего ошибку. Каждый шаг — отдельный коммит в отдельной ветке задачи. В последствии вся ветка попадет в центральный репозиторий, сохраняя для поколений структурированное решение задачи. Теперь даже коммит, который был выполнен «заодно» и не являющийся непосредственно необходимым для закрытия задачи, находится в контексте задачи (в той же ветке), позволяя видеть цель и мотивацию автора.
Задача в  SVN  — это большой, размазанный по разным модулям патч.  Больших усилий стоит разобраться в таком патче. Гораздо проще, когда каждая задача — это структурное решение, и можно пробежаться по отдельным шагам. В таком решении отделяются «зерна от плевел». 

Репозиторий стал неотъемлемой частью кода проекта. 


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

По ходу ревью в код могут вносится изменения, каждое такое изменение может вносится squash коммитом. Это коммит, который в последствие с помощью команды rebase можно объединить с другим коммитом (что бы ощутить мощь Git достаточно пробежаться по оглавлению способов изменить историю https://git-scm.com/book/ru/ и http://97things.oreilly.com/wiki/index.php/Record_your_rationale).
Таким образом, можно будет и в ревью видеть развитие мысли автора. А после завершения ревью одной командой rebase можно изменить историю и получить красивое дерево коммитов, без лишнего мусора, объединив squash, fixup коммиты с базовыми.

7. Правило «юнит тесты до функциональности». Это правило говорит о том, что юнит тесты должны располагаться в дереве коммитов до исправления ошибки, которую они тестируют. В результате всегда можно проверить работу юнит теста до исправления ошибки и после. Убедиться, что тест и исправление написаны верно.

Пример:

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

Про культуру 

     Система постоянно меняется, практически невозможно постоянно актуализировать все требования к приложения и его описания. Но теперь репозиторий взял на себя новую ответственную роль. Стал рассказывать не только кто и когда написал код, но и почему(такую роль бывает берет на себя багтрекер, но это слишком далеко от кода). Можно проследить мысль автора, узнать мотивы. Это формирует еще один уровень метаинформации. С помощью такого слоя информации мы стараемся закрыть наиболее критическое место описания системы. Практика показывает, что гораздо проще восстановить предисторию и все причины принятия конкретного решения для будущей переоценки, если они привязаны к коду  и расположены прямо в репозитории. Почему важно сохранять подобного рода информацию можно почитать еще здесь 97things.oreilly.com/wiki/index.php/Challenge_assumptions_-_especially_your_own и во многих других местах.  Но при при чем здесь культура?

    Чтобы понимали, что я имею в виду под культурой, приведу отрывок из книги Бориса Евсеевича Чертока «Ракеты и Люди», за который меня наверное уже недолюбливают как друзья, так и коллеги, слишком уж часто я его вспоминаю:
«В первые годы работы над ракетной техникой практически никто из руководителей, критикующих завод, не мог конкретно сформулировать, что нужно сделать для повышения культуры производства, определить роль каждого начальника цеха, мастера и рабочего. Было слишком много общих решений. Устинов беспощадно расправлялся с начальниками цехов и производств за грязь и бескультурье. При посещениях завода он начинал с туалетов. Обычно в цехах задолго до подхода к туалету разносился характерный «аромат». В самих туалетах надо было ходить по лужам. Устинов приходил в ярость и гремел: «Какой сортир, такой и начальник цеха. Пока не добьетесь образцовой чистоты в своих сортирах, не будет чистоты и в цехах».С тех пор прошло очень много лет. Проблема чистоты общественных туалетов на наших заводах и в институтах так же, впрочем, как и в стране в целом, не решена. Это оказалось куда труднее, чем создать самое грозное ракетно-ядерное оружие и завоевать мировой приоритет в космонавтике.Явный дефицит культуры, общей производственной чистоты и гигиены до сих пор является одной из причин низкого качества многих отечественных изделий. За время войны и в последующие годы забота об элементарном комфорте в цехах, создание рабочему достойной и привлекательной общей обстановки считались излишней и непозволительной роскошью. Затраты на чистоту, комфорт, элементарный сервис с лихвой окупаются повышением производительности и качества. «

  Если театр начинается с вешалки, то проект начинается с репозитория. Отношение к репозиторию закладывает отношение ко всему проекту. Аккуратность, формализованность, структурированность, обоснованность, ответственность и прозрачность  — качества, которые культивируются приведенными выше правилами работы с репозиторием, переносятся и на другие аспекты проекта. Сам workflow выполнения задачи сопротивляется поспешным, не продуманным, ошибочным и не обоснованным решениям. Код должен выглядеть хорошо и аккуратно не только внутри, но и снаружи. Мелочей не бывает. При переходе на Git о таких вещах, к сожалению, почти не задумывались. Git конечно, не серебряная пуля и не Святой Грааль, но крайне эффективный инструмент, который может сильно изменить ландшафт методологии разработки.

    Гит раскрывает свои возможности постепенно. Постоянно открываем что-то новое. В начале используется базовый набор команд. Но потом постепенно открываются все новые и новые возможности и пути оптимизации операций и повышения собственной эффективности. Кажется, что мы используем от 20 — 40% возможностей Git. Мы продолжаем познавать Git, постоянно экспериментируем и дорабатываем наши правила и стандарты. Возможно читатель поделится и своими успешными практиками. 

Несколько полезных ссылок

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

Читать на сайте автора.