Инструменты для работы с Git – P4Merge

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

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

Утилита доступна для ОС Windows, Mac OS X и Linux



Ну и начинаем установку





Проверяем установку. В смысле что P4Merge доступен через системную переменную PATH.
Жмем Win+R и даем команду P4Merge



Получаем



Если P4Merge запустилась таким образом значит все хорошо.

Теперь настраиваем Git на использование P4Merge как внешней утилиты сравнения и слияния.
К слову сказать, в Git можно настроить несколько внешних утилит сравнения и слияния. И использовать любую из них на выбор.

Я решил сделать настройку через правку файла локального конфига репозитория Git. Для этого добавил в конфиг эти строчки:

[diff]
        tool = p4m

[difftool "p4m"]
        cmd = "p4merge.exe $LOCAL $REMOTE"

[merge]
        tool = p4m

[mergetool "p4m"]
        cmd = "p4merge.exe $BASE $LOCAL $REMOTE $MERGED"
        trustExitCode = true
        keepBackup = false
        keepTemporaries = false

В редакторе Far это выглядит так



Я сделал четыре коммита файла test.txt в репозиторий Git. Приведу их лог, чтобы было более понятно и запустим сравнение файла test.txt из первого (c258082) и четвертого (ffd6b37) коммита.

Дадим команду

$ git difftool c258082 ffd6b37 --tool=p4m --cc test.txt



Git спрашивает запустить ли утилиту, которую мы определили как p4m, жмем Y и получаем



И соответственно видим слева содержимое файла test.txt из первого коммита и справа из четвертого.

Закрываем окошко. И теперь поменяем местами (слева на право) просматриваемые коммиты.

$ git difftool ffd6b37 c258082 --tool=p4m --cc test.txt



Теперь отображение файлов поменялось местами



То есть P4Merge корректно отображает расположение и содержимое сравниваемого файла в зависимости от заданной в команде очередности расположения коммитов.

Теперь посмотрим то же самое обычным git diff. Дадим команду

$ git diff ffd6b37 c258082 --cc test.txt



То же не плохо, но в графическом интерфейсе куда наглядней и приятней.

Теперь я сделал ветку newbranch, изменил в ней файл и сделал коммит, затем вернулся в ветку master, тоже изменил файлик и тоже сделал коммит. Дерево коммитов теперь выглядит так:



Теперь сделаем слияние при помощи P4Merge. Даем команду git merge из ветки master.



Git видит конфликт и предлагает нам его разрешить самим при помощи внешней утилиты. При этом надо понимать и учитывать, что команда git merge уже изменила файл test.txt, так как попыталась сперва сама его смерджить (объеденить). Сейчас файл test.txt выглядит так:



Теперь запустим вешнюю утилиту для разрешения конфликта слияния, как нам советовал Git



После соглашения на запуск p4m, мы видим экран P4Merge



При этом в рабочем каталоге P4Merge немного “намусорила”, создав временные файлы необходимые для слияния, но об этом можно не беспокоится. Она за собой приберется.





Жмем Save и выходим из программы, согласившись с тем как она решила слить (хотя могли бы и все поменять как самим надо). Посмотрим status



Файлик test.txt.origin – это diff файл сгенерированный командой git merge, его можно просто удалить и сделать коммит.





Теперь наше дерево коммитов выглядит так



Вот мы и разрешили конфликт слияния при помощи P4Merge

Основы Git – практика работы с удалёнными репозиториями (часть 2)

Если ветка является отслеживаемой, то просто давая на ней команду git push, Git знает куда отправить эту ветку на удаленный сервер, но в версии Git 2.0, это поведение будет немного изменено, и даже сейчас в версии Git 1.9.5.msysgit.0 выдается следующее предупреждение:

Переводить все это дело лень. И так все понято

Настройка русских шрифтов в Git

Вернее сказать настройка правильного отображения русских шрифтов (кириллицы) в Git.

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

И так сперва рассмотрим как Git работает с русским языком в юникод.

Создадим каталог UTFtest и в нем репозитарий Git. Дополнительных настроек ни каких не делаем, кроме как задаем имя и email пользователя.

Теперь создаем текстовый файлик TestUTF.txt в кодировке юникод. Я использовал для этого Notepad++, но можно и любой другой, главное чтобы он поддерживал создание файлов в юникод без BOM.

В настройках Notepad++ отключение BOM выглядит так

И так мы создали файлик, теперь, посмотрим статус, добавим файл в индекс и сделаем первый коммит.

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

Добавим в наш файлик вторую строчку.

Теперь опять посмотрим статус, добавим изменения в индекс и закоммитим.

Помним, что мы редактировали файлик в кодировке юникод (UTF) без BOM.

Теперь посмотрим простой лог наших изменений.

Git вывел краткую информацию о наших коммитах. Кто, когда, комментарий и контрольную сумму каждого коммита.

Теперь посмотрим дельту, разницу между нашими коммитами, то есть более подробно, что было изменено.

Как видим Git показал нам что было изменено в файле во втором коммите при сравнении его с первым коммитом.

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

От сюда вывод, что Git по умолчанию использует UTF-8 и как следствие с русским языком проблем не возникает.

Теперь на всякий случай покажу что же такое этот BOM и как сей зверь выглядит в коммитах.

Для этого создам текстовый файл в Far Manager, добавлю его в индекс, закоммитю, добавлю в файлик еще одно строчку и снова сделаю коммит.

Хотя в редакторе Far manager служебного кода BOM не видно, но он там есть

На заметку: В редакторе Far manager, так же можно отключить создание BOM метки.

Все! Мы убедились, что при использовании кодировки UTF-8 ни каких проблем с русским языком, как в комментариях к коммитам, так и с просмотром русского текста в дельте логов, не возникает. И при этом не надо делать ни каких дополнительных настроек.

Исключение может составлять только если у вас есть файлы с русскими именами. Приведу примерчик. Создам файл Русский.txt. И посмотрим статус и содержимое каталога в консоли.

Вот как выводит консоль имена файлов на русском языке.

Чтобы это подправить дадим команду

$ git config --local core.quotepath false

И снова посмотрим статус и содержимое каталога в директории

Теперь Git стал нормально отображать русские названия файлов. А вот линуксовая утилитка ls с русским не подружилась (вернее сказать bash не подружился), но это ни какого отношения к Git не имеет.

Но если очень хочется то можно заставить ls выводить русские имена файлов правильно задав дополнительный ключик

$ ls --show-control-chars

Теперь добавим на наш файлик Русский.txt в индекс и закоммитим его. Потом добавим в этот файл строку и снова закоммитим. А затем посмотрим дельту

Как видим с русским языком снова все хорошо. То есть дополнительная настройка понадобилась только в том случае, когда есть файлы с названиями на русском языке.

Теперь настроим Git на работу с русской кодировкой Windows (CP 1251)

Создадим каталог CP1251 и Git репозитарий в нем. Затем создадим файлик Win.txt в стандартной кодировке Windows. Посмотрим статус, добавим этот файл в индекс и закоммитим его.

Напомню что все это дается с установками Git по умолчанию.

Теперь добавлю в файлик Win.txt еще одну строчку и закоммичю его, а затем посмотрим дельту, то есть разницу между первым и вторым коммитом.

И так смотрим разницу между коммитами

Ууууупс! Что за ерунда???? Видим что комментарии к коммитам отображаются правильно, так как они в юникоде (UTF-8), а вот содержимое файлов у нас идет кодами, что не очень то удобно, верней вообще не удобно. Это происходит потому, что вывод команды git log, так же происходит в UTF-8.

Попробуем поправить ситуацию. Дадим команду

$ git config --local core.pager "iconv.exe -f cp1251 -t utf-8 | less"

Данная команда переопределяет вывод пейджера (программы less, стандартной линуксовой программы постраничного вывода). Она конвертирует кодовую страницу cp1251 в UTF-8, как видно из синтаксиса команды iconv.exe.

iconv.exe идет вместе с дистрибутивом Git, поэтому нет смысла качать дистрибутив с сайта. Единственное ей могут понадобится дополнительные библиотеки, которые можно скачать тут. Нужно выбрать Dependencies (zip)

Теперь посмотрим еще раз дельту

Мы видим что теперь содержимое файлов в дельте отображается правильно, а вот комментарии к коммитам стали отображаться не правильно. Это произошло потому, что весь вывод команды git log, конвертируется и строчки комментариев были рассмотрены как-будто они в кодировке cp1251.

Попробуем исправить и это командами

$ git config --local i18n.commitEncoding utf8

$ git config --local i18n.logoutputencoding cp1251

Я несколько раз поправил файлик. Посмотрим два последних коммита и их дельту.

Как видно почти все отображается нормально. Исключение составляет только вывод после команды git commit (я его подчеркнул красной чертой и подсветил желтым). С этим можно конечно смирится если очень хочется вести проект в кодировке Windows CP1251. Как поправить этот маленький недочет я не знаю. Может кто подскажет – буду очень признателен.

Просто git log без дельты тоже выводит все нормально

Файл настроек Git для данного проекта CP1251 выглядит так:

Но вообще лучше вести проекты в UTF-8

Первоначальная настройка Git

Теперь, когда Git установлен в вашей системе, самое время настроить среду для работы с Git’ом под себя. Это нужно сделать только один раз — при обновлении версии Git’а настройки сохранятся. Но, при необходимости, вы можете поменять их в любой момент, выполнив те же команды снова.

В состав Git’а входит утилита git config, которая позволяет просматривать и настраивать параметры, контролирующие все аспекты работы Git’а, а также его внешний вид. Эти параметры могут быть сохранены в трёх местах:

1) C:\Program Files (x86)\Git\etc\gitconfig (У вас может быть другой путь, это зависит от того куда вы установили Git.) Этот файл содержит значения, общие для всех пользователей системы и для всех их репозиториев. Если при запуске git config указать параметр --system, то параметры будут читаться и сохраняться именно в этот файл.

2) Файл .gitconfig в домашнем каталоге пользователя %userprofile%  Этот файл хранит настройки конкретного пользователя. Этот файл используется при указании параметра --global.

3) Файл config в каталоге Git’а (т.е. .git\config) в том репозитории, который вы используете в данный момент, хранит настройки конкретного репозитория. Этот файл используется при указании параметра --local.

Настройки на каждом следующем уровне подменяют настройки из предыдущих уровней, то есть значения в .git/config перекрывают соответствующие значения в /etc/gitconfig.

 

Задаем имя пользователя

Первое, что вам следует сделать после установки Git’а, — указать ваше имя и адрес электронной почты. Это важно, потому что каждый коммит в Git’е содержит эту информацию, и она включена в коммиты, передаваемые вами, и не может быть далее изменена:

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

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

Проверка настроек

Если вы хотите проверить используемую конфигурацию, можете использовать команду git config --list, чтобы показать все настройки, которые Git найдёт:

$ git config --list
user.name=John Doe
user.email=johndoe@example.com
color.status=auto
color.branch=auto
color.interactive=auto
color.diff=auto
...

Некоторые ключи (названия) настроек могут появиться несколько раз, потому что Git читает один и тот же ключ из разных файлов (например из \etc\gitconfig и %userprofile%\.gitconfig). В этом случае Git использует последнее значение для каждого ключа.

Также вы можете проверить значение конкретного ключа, выполнив git config <key>:

$ git config user.name
John Doe

Ну и как получить помощь по командам Git

Если вам нужна помощь при использовании Git, есть три способа открыть страницу руководства по любой команде Git:

$ git help <verb>
$ git <verb> --help
$ man git-<verb>

Например, так можно открыть руководство по команде config

$ git help config

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

Выбор редактора

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

Поэтому я решил настроить Notepad++ как редактор сообщений к коммитам. Notepad ++ можно скачать тут. Я его выбрал потому что он нормально работает с юникодом, ну и вообще не плохой бесплатный текстовый редактор и портабельный к тому же. Вы можете выбрать любой другой.

Я скачал портабельную версию и разархивировал. Теперь его надо добавить как редактор в Git. Для этого сперва добавляем путь к каталогу куда разархивировали Notepad++ в системную переменную PATH.

И затем в git даем команду

$ git config --local core.editor "notepad++.exe -multiInst -nosession -notabbar -noPlugin"

После этой команды в секции [core] локального файла конфига .git/config появится такая строчка

editor = notepad++.exe -multiInst -nosession -notabbar -noPlugin

В принципе эту строчку можно добавить туда и в ручную в любом текстовом редакторе.

Есть и другой способ, без использования команды core.editor, но путь все же должен быть прописан в переменной PATH. Можно добавить переменную окружения windows GIT_EDITOR и прописать туда строчку notepad++.exe -multiInst -nosession -notabbar -noPlugin.

В данном случае это будет работать для всех проектов данного пользователя. Так как это пользовательская переменная. Если же такую же переменную сделать системной, то она будет работать для всех пользователей. Хочу еще раз отметить, что при использовании переменной GIT_EDITOR нет необходимости давать команду настроек core.editor.

Для чего служат ключи запуска notepad++ в этой команде можете почитать в справке к редактору.

Есть другие два способа добавить Notepad++ как редактор коммитов без изменения системной переменной PATH.

Например, если вы разархивировали его в папку C:\Notepad++

то в файл конфига в секцию [core] надо добавить строчку

editor =\"C:/Notepad++/notepad++.exe\" -multiInst -nosession -notabbar –noPlugin

Так тоже можно сделать, дабы не захламлять переменную PATH.

Ну и используя переменную окружения Windows GIT_EDITOR, но в данном случае в ней уже надо будет прописать полный путь к Notepad++. Это тоже способ без использования переменной PATH.

Прописываем строчку

"C:\\Notepad++\\notepad++.exe" -multiInst -nosession –notabbar

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

В Windows 8.1 Pro x64 у меня почему-то строчка запуска как Windows 7 не сработала, но я ее чуток переделал и стала работать вот такая строка

"C:\\Notepad++\\notepad++.exe" -notabbar -multiInst -nosession -noPlugin

В ходе экспериментов при всплытии по команде git commit, она предлагала то создать файл –notabbar или noPlugin. Но после того как я поправил строчку описанным выше способом все заработало нормально.

Итого есть аж четыре способа как настроить внешний редактор Notepad++ и Git.