Git subtree

С git submodule многие плюются, но есть альтернатива.

Первоначально до версии Git 1.7.11 , использовалась subtree merge strategy , после этой версии написали удобную комманду git subtree.

Начнем с преимуществ и недостатков этого подхода по сравнению с git submodule, ну а потом рассмотрим сначало старый  подход работы, после - новый, с командой:

+:
1) Управляться с простым воркфлоу просто:)
2) Достаточно старые версии поддерживаются (v1.5.2-)
3) Код подпроектов сразу появляется после clone проекта.
4) subtree не принуждает пользователей проекта учить что-то новое, и они даже не обязаны знать об использовании мердж стратегии сабтри.
5) subtree не добавляет новых файлов метадаты как submodules (.gitmodule)

-:
1) нужно познакомиться с новой мердж стратегией.
2) комитить код в репозитории подмодулей на порядок сложнее.
3) Ответсвенность за то, чтобы не мешать изменения в проекте и подмодуле в одних коммитах лежат на плечах разработчиков, а не системы.

Git merge strategies

Когда мы делаем мердж гит сам выбирает по контексту какую стретегисю ему выбрать, но он выбирает из двух стратегий:
- recursive;
- octopus;

Recursive выбирается чаще всего, она может мерджить две бранчи, при этом у них может быть сложная историй наследований с несколькими общими корнями.
Octopus в отличие от первой умеет мерджить одновременно больше двух веток, но она не настолько умна если у историй есть несколько общих корней.

Есть еще одна стратегия:
- subtree

Она помогает решать проблему подмодуля со своим репозиторием (Subtree Merging альтернатива git submodule)

git reflog

Инструмент который помогает решать неприятные ситуации случившиеся в локальном репозитории.

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

Именно  git reflog который пишет все наши действия поможет нам выкрутиться из пикантной ситуации.

Git submodules

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

Есть два неверных пути:
1) делать копии библиотек в репозитории проектов, со всеми вытекающими последствиями обновления версий библиотек
2) сделать отдельный репозиторий под библиотеку, в случае этого варианта у нас начинается возня с тем как изменения в этом репозитории потестировать - ведь библитека всегда используется внешней стороной, она сама себя вызывать не будет, ее нужно как-то все-таки впихнуть в проект.

A Git repo inside a Git repo
 + Pull down updates easily
 + Test your changes with an actual dependent project
 + Share changes easily
 + History independent of containing repo

Сабмодуль - это репозиторий внутри другого репозитория.

Git working togather

Разделители строк

OS	Expects Character(s)
OSX/Linux	LF(LineFeed) \n
Windows	CR(Carriage Return) and LF pair \r\n

On Unix-like systems:

$ git config --global core.autocrlf input

Настройка меняет при комите CR/LF -> LF

On Windows systems:

> git config --global core.autocrlf true

Настройка меняет при чекауте LF -> CR/LF, но изменяет назад CR/LF -> LF при коммите

On Windows-only projects:

> git config --global core.autocrlf false

Git attributes file

Purging history

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

Вот приведены примеры когда нам не стоит переписывать историю:
1) Не нужно нудить иногда, ничего страшного нет в том, что бред попал - его удалили, и это помеченно в истории, иногда лучше сэкономить время и реализовать дополнительную фичу чем колупать историю.
2) Каждый должен следить за своей историей и делать там правки на основании код ревью и прочего и это показывает реальный обьем проделанных работ, потом может быть не понятно почему так долго что-то делалось, если почистить историю.

А вот примеры когда нужно подчистить историю:
1) Залитые файлы нарушают чьи-то копирайты - храня это в истории, мы храним и частный код в виде конкретного комита.
2) Были случайно залиты тяжелые файлы - это забивает наш репозиторий.

Git stashing

Когда нужно сделать что-то очень срочно, а мы на полпути в поточной работе, которое и комитить рано и не понятно как. По-этому у нас есть возможность взять отредактированные файлы и положить во временное пространство:

 
$ git stash save
Saved working directory and index state
WIP on gerbils: b2bddead Add dogs.

WIP - Work In Progress
gerbils - name of branch where stashed files were gotten from
b2bddead Add dogs. - хеш код востановленного стешингом коммита и его сообщение

JMockit. Reflection-based utilities

Все утилиты этого инструмента из пакета  mockit.Deencapsulation  статические и без состояний. Все это ни что иное как обвертки более высокоуровневого API над Reflection API .
Итак давайте потестим вот что:

import static mockit.Deencapsulation.*;

public final class DeencapsulationTest
{
   final SubClass anInstance = new SubClass();

   static class BaseClass
   {
      protected int baseInt;
      protected String baseString;
      protected Set<boolean> baseSet;
   }

   static final class SubClass extends BaseClass
   {
      private static StringBuilder buffer;
      private static char static1;
      private static char static2;

      private int intField;
      private int intField2;
      private String stringField;
      private List<string> listField;

      private SubClass() { intField = -1; }
      private SubClass(int a, String b) { intField = a; stringField = b; }
      private SubClass(String... args) { listField = Arrays.asList(args); }

      private long aMethod() { return 567L; }
      private static Boolean anStaticMethod() { return true; }
      private void instanceMethod(short s, String str, Boolean b) {}
      private static void staticMethod(short s, String str, Boolean b) {}

      private final class InnerClass
      {
         InnerClass() {}
         InnerClass(boolean b, Long l, String s) {}
      }
   }

   // example tests
}

А теперь сами вызовы:

Behavior-based testing with JMockit

Гит клон длинными словами

git init
git remote add origin PATH/TO/REPO
git fetch
git checkout -t origin/master

Ключ t как я понимаю означает track - тоест мы подвязываемя к удаленному бранчу, в данном случае master to origin/master

И снова rebase

И так повторим ребейс:
Вот в чем суть: допустим у нас есть две бранчи master и unicorns. unicorns создана из мастера. И ее судьба состоит в том, что по завершении работы в ней она будет влита обратно в мастера.

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

Делается это так:
1) Мы как и вели, ведем разработку в ветке unicorns.
2) делаем $ git rebase master 
  происходит следующее:
      1. все комиты из unicorns заносятся в некий бранч temp(temp area)
      2. новые комиты мастера переносятся вперед старых.
      3. сразу за ними возращаются из temp комиты самого unicorns.
Теперь юникорн можно смело мерджить в масетер и мы получим ровную небугристую историю.

Running tests with JMockit

Моменты с JDK

JMockit можно запускать под JDK 1.5+. Тестировать можно код написанный под любой JDK.

По разному запускаются тесты для JDK 1.5 и JDK 1.6+.

В случае JDK 1.5 нам нужно подключать JMockit как агент: -javaagent:/proper/path/jmockit.jar

В JDK 1.6+ достаточно чтобы JMockit просто был в класспазе.

Java regexp как работать с мультизаменой в мульристрочности

Мульристрочность?
Чтобы работать с "мультистрочными"(большими и с переносом строк) String нужно при компилирование патерна включить следующие ключи:

Pattern pattern = Pattern.compile("some pattern", Pattern.MULTILINE | Pattern.DOTALL);

Прочитать

http://largescalejs.ru/
http://www.addyosmani.com/resources/essentialjsdesignpatterns/book/

http://www.petrikainulainen.net/spring-mvc-test-tutorial/

Reset remote url

git remote set-url origin git://new.url.here