Обзор плагинов и скриптов для работы в технике Pixel Perfect.

Для начала - что такое техника Pixel Perfect? Все просто и можно догадаться по названию - это техника верстки, при которой сверстанный HTML-шаблон в точности (пиксель-в-пиксель) совпадает с оригиналом, PSD-макетом.

Другими словами, если наложить “картинку” сверстанного HTML-шаблона на картинку оригинального PSD-макета, то обе картинки должны совпасть. Совместиться должны все элементы картинок - текст, изображения, графические элементы.

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

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

Первоначально в программе Photoshop оригинальный PSD-макет сохраняется как изображение в формате

1
.png
. Затем в браузере открывается сверстанный по этому макету HTML-шаблон. При помощи плагина PNG-копия макета накладывается на сверстанную страницу. И становится видна разница в расположении элементов на HTML-странице и на PNG-копии.

В этом и заключается вся несложная процедура Pixel Perfect проверки сверстанной страницы. Там, где на странице элементы не совпадают с оригиналом, производится коррекция значений в файлах стилей.

Pixel Perfect под Firefox

Для браузера Firefox имеется плагин Pixel Perfect для одноименной проверки сверстанной страницы.

После установки плагина Pixel Perfect его значок появиться в панели инструментов браузера Firefox. Стоит сказать, что плагин Pixel Perfect поддерживает только последние версии браузера Firefox (к примеру, в версии v.31 этот плагин не будет работать).

Теперь нужно открыть в Photoshop оригинальный PSD-макет и сохранить его целиком как изображение в формате

1
.png
через “Save for Web…”.

Важно! Перед экспортом в PNG-изображение PSD-макет необходимо привести к оригинальному размеру! Для этого в Photoshop зарезервирована комбинация hotkeys: Ctrl+1 - под Windows\Linux, Cmd+1 - под Mac OS X.

Как только PNG-копия PSD-макета подготовлена и сохранена, открываем в окне браузера Firefox сверстанную по этому макету HTML-страницу.

Запускаем плагин Pixel Perfect щелчком мыши по его иконке в панели инструментов браузера. Сразу же появится окно плагина, в котором он предложит нам выбрать заранее подготовленное PNG-изображение (копию PSD-макета):

Pixel Perfect Add Layer

Жмем на кнопку “Add Layer”, выбираем подготовленное PNG-изображение и получаем результат - наложение двух слоев (сверстанного и оригинального):

Pixel Perfect Compare Layers

Видим, как не совпадают текст и кнопка HTML-страницы c PNG-оригиналом. Поэтому открываем в Firebug (этот плагин активируется автоматически при запуске плагина Pixel Perfect) вкладку со стилями и начинаем правку\подгонку:

Pixel Perfect Correct CSS Styles

Обратите внимание на режим “Invert” плагина Pixel Perfect - с помощью него можно очень точно корректировать элементы HTML-страницы.

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

Ниже приведен видео-ролик, в котором показан процесс работы с плагином Pixel Perfect (видео не мое, поэтому за качество во всех смыслах ответственности не несу) - для наглядности работы пойдет:

Рассмотрение плагина Pixel Perfect под браузер Firefox закончено.

PerfectPixel под Google Chrome

Плагин PerfectPixel под браузер Chrome очень похож по назначению и функционалу (и названию!) на плагин Pixel Perfect под браузер Firefox.

После установки PerfectPixel необходимо зайти в настройки расширений браузера Chrome - chrome://extensions/ и активировать для плагина галочку “Allow access to file URLs”, тем самым разрешив плагину доступ к локальным HTML-страницам:

PerfectPixel Activate

Важно! Перед экспортом в PNG-изображение PSD-макет необходимо привести к оригинальному размеру! Для этого в Photoshop зарезервирована комбинация hotkeys: Ctrl+1 - под Windows\Linux, Cmd+1 - под Mac OS X.

После этого запускаем плагин PerfectPixel, добавляем в нем новый слой (PNG-копию оригинала) и проверяем:

PerfectPixel Work

Функционал и работа плагина PerfectPixel ничем не отличается от функционала и работы плагина Pixel Perfect.

Ниже приведен видео-ролик с официальной страницы плагина PerfectPixel для демонстрации работы в нем:

Рассмотрение плагина PerfectPixel можно на этом закончить.

X-Precise

Если в двух предыдущих случаях были рассмотрены бесплатные плагины под два популярных браузера Firefox и Chrome, то в данном случае речь пойдет о платном ($5 на момент написания статьи) скрипте X-Precise, написанном на JavaScript и использующем библиотеку jQuery.

Подключение X-Precise

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

Затем нужно распаковать папку

1
_xprecise
в корневую директорию проекта. И подключить скрипт
1
xprecise.min.js
к HTML-странице для запуска интерсейса скрипта X-Precise.

Обратите внимание, что скрипт для своей работы использует библиотеку jQuery (v1.3.2), поэтому подключение X-Precise должно выглядеть таким образом:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js" type="text/javascript"></script>
<script src="_xprecise/xprecise.min.js" type="text/javascript"></script>

Затем нужно создать копии PSD-оригиналов в формате JPG и сохранить под тем же именем, что и файл оригинала в директории

1
/_xprecise/
скрипта X-Precise.

При сохранении в формате JPG рекомендуется выбирать режим оттенков серого, так как при таком варианте лучше видна разница между сверстанной копией и оригиналом (помните об опции “Invert” плагина Pixel Perfect?).

Скрипт X-Precise попытается автоматически загрузить JPG-изображение из директории

1
/_xprecise/
по имени файла этого изображения, считая, что имя файла иображения идентично имени файла открытой HTML-страницы (index.html -> index.jpg).

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

Использование X-Precise

Основным достоинством скрипта X-Precise является его способность автоматически запоминать и хранить все настройки.

В целом, интерфейс скрипта X-Precise и его применение ничем не отличается от плагинов Pixel Perfect или PerfectPixel. Для желающих - можно ознакомиться со скриншотами по ссылке на главной странице проекта.

pixLayout

pixLayout - еще один плагин (наподобие X-Precise) под библиотеку jQuery, предназначенный для попиксельной верстки. Однако, в отличие от предыдущего скрипта, pixLayout бесплатный (интересная особенность - скрипт создан отечественным разработчиком).

Для своей работы скрипт pixLayout может использовать изображение в двух популярных форматах - JPG или PNG.

Домашняя страничка проекта расположена здесь - pixLayout. Скрипт прекрасно документирован как на родном (русском), так и на языке Уильяма Шекспира. Полюбоваться и поиграться можно на демо-страничке скрипта - pixLayout Test.

Для подключения к тестируемой странице необходимо прописать базовый набор строк:

<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="jquery.pixlayout.js"></script>
<script type="text/javascript">
  $(function(){
    $.pixlayout("/path_to_picture/picture.ext");
  });
</script>

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

$(function(){
  $.pixlayout({
    src: "/img/layout.jpg",
    opacity: 0.8,
    top: 50,
    center: true,
    clip: true,
    show: true
  }, ".wrapper");
});

Краткая справка по использованию скрипта pixLayout

Краткая справка по использованию скрипта pixLayout приведена в двух абзацах ниже (также взята с официального сайта):

Перемещение

  • кнопки: ‘влево’, ‘вправо’, ‘вверх’, ‘вниз’
  • кнопки: W, A, S, D, когда картинка видима
  • кнопки панели навигации

Операции

  • Уничтожить (удалить весь html и css код pixLayout со страницы) - крестик в правом верхнем углу панели;
  • Закрепить панель - иконка в правом верхнем углу панели;
  • Краткая справка - знак вопроса в правом верхнем углу панели;
  • Свернуть параметры - стрелка “вверх”” внизу панели;
  • Показать\убрать картинку - центральная кнопка панели навигации или Shift + E.

Ниже приведено официальное видео, демонстрирующее работу со скриптом pixLayout:

Заключение

В этом небольшом обзоре мы познакомились с четырьмя инструментами для попиксельной (pixel perfect) верстки. Два из них - это бесплатные плагины под браузеры. Другие два - скрипты на JavaScript для подключения к HTML-странице.

Что выбирать для своей работы - решать каждому.

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

В минус скрипту X-Precise можно сказать, что он платный ($5), требует подключения к проверяемой HTML-странице и зависит от библиотеки jQuery. В минус pixLayout также можно сказать, что для своей работы он требует дополнительной “возни” с подключением к HTML-странице.

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

На этом все.


Перевод статьи, посвященной вопросу - что такое fast-forward в системе Git

Оригинал данного вольного перевода размещен здесь - Fast-Forward Git Merge. Статья довольно свежая - от 20.09.2013. Почему перевод статьи? Потому что на русском ничего не нашел (окромя книги официальной).

Слияние (

1
merge
) ветвей является весьма распространенной и обыденной операцией, выполняемой в системе Git. Однако, в некоторых случаях Git выполняет слияние ветвей в режиме fast-forward. Но что такое режим fast-forward и чем он отличается от обычного режима слияния ветвей.

Давайте разберем этот вопрос на конкретном примере. Допустим, при работе в репозитории мною была создана ветка

1
speedup
из текущей ветки
1
master
:

$ git checkout -b speedup

Поработав некоторое время в этой ветке, я создал несколько

1
commit
‘ов (три коммита, три белых кружка на рисунке):

Ветка speedup

После этого я решил, что работа в ветке

1
speedup
мною выполнена и я сделал
1
push
этой ветки на свой удаленный репозиторий.

Между тем, обратите внимание на тот важный факт, что в ветке

1
master
не было внесено никаких изменений с того самого момента, когда я сделал ответвление от нее - ветку
1
speedup
.

Когда менеджер проекта уведомится о том факте, что разрабатываемая мною ветка готова для интеграции в проект, то им будет выполнены стандартные шаги по публикации моей работы - команды

1
git fetch
и
1
git merge
. Так как в ветке
1
master
не было внесено изменений с того момента (серый кружок), как была создана ветка
1
speedup
, то при слиянии система Git применит метод fast-forward. В этом случае вся последовательность коммитов будет иметь линейный вид (левая часть рисунка):

Fast-Forward Git

Примечание переводчика: другими словами, Git просто произведет перемещение указателя HEAD с серого кружка (последний коммит ветки

1
master
) на последний белый кружок (последний коммит ветки
1
speedup
). И будет считать, что все это - ветка
1
master
. Получится своеобразный проброс указателя HEAD вдоль последовательной линии коммитов. Именно поэтому автор упоминает термин линейного вида.

Другим вариантом слияния веток в данном случае является использование флага

1
-no-ff
в команде
1
git merge
, что представляет из себя сокращение от - no fast-forward. В этом случае ситуация будет несколько иной - ее схематичное изображение на правой части рисунка вверху.

В этом случае при слиянии веток

1
master
и
1
speedup
системой Git создается коммит (кружок со штрихованной границей), задача которого - информировать о слиянии веток. Другими словами - цель и задача этого коммита только в информировании о слиянии веток
1
master
и
1
speedup
.

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

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

1
merge
в режиме no fast-forward - это когда вы нажимаете ту самую зеленую кнопку “Merge” в web-интерфейсе сервиса GitHub при выполнении pull request:

GitHub Pull Request

К сожалению, на сегодняшний день web-интерфейс GitHub выполняет операцию слияния (

1
merge
) так, как если бы для этой команды был установлен флаг
1
-no-ff
. Другими словами, даже если при слиянии веток ситуация позволяет использовать режим fast-forward, GitHub не будет его использовать.

Одним из разумных объяснений такого поведения GitHub является тот факт, что каждая операция

1
pull request
должна быть однозначно идентифицирована. К примеру, несколько последних коммитов проекта (в качестве примера мною был взят проект ESLint - ничего личного) могут выглядеть таким образом:

ESLint

Внимательно посмотрите на приведенный выше рисунок. На нем хорошо видно, что некоторые слияния (

1
merge
) веток могут быть выполнены в режиме fast-forward. Но своеобразный подход GitHub к слиянию веток привел к тому, что линейная история коммитов была превращена в нечто похожее на рисунок железнодорожного пути.

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

Режим no fast-forward хранит всю информацию о слияниях веток. Такой подход может оказаться запутанным и сложным, если необходимо прочитать историю коммитов.

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

На этом все.


Краткий обзор команды git diff

Итак, продолжаю знакомиться с системой Git и на этот раз вопрос будет касаться команды

1
git diff
. Это краткая заметка, которая ни в коей мере не претендует на полноценный обзор. Скорее всего - философское рассуждение на тему сравнения в Git.

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

Когда изменение обнаружено, тогда можно решать, что с ним делать - оставить, удалить или отредактировать.

Перед использованием команды

1
diff
стоит напомнить о трех состояниях системы Git: Working Area, Staging Area, Repository. Фактически, команда
1
diff
производит сравнение между разными состояниями одного файла.

Поэтому, когда запускается команда

1
diff
, следует принимать во внимание, что и с чем будет сравниваться.

Working Area

Рассмотрим первый случай, когда имеется отслеживаемый файл

1
index.html
, в который вносятся изменения.

Но изменения в этом файле не индексируются (

1
git add
) и не фиксируются (
1
git commit
).

В этом случае, чтобы увидеть изменения, нужно запустить команду:

$ git diff

В этом случае производится сравнение между фиксированной версией файла

1
index.html
(в области Repository) и его измененной версией (в области Working Area).

Вывод будет примерно таким:

$ git diff
diff --git a/index.html b/index.html
index 8fbea1c..fff54a9 100644
--- a/index.html
+++ b/index.html
@@ -5,6 +5,6 @@
   <title>Index</title>
 </head>
 <body>
-
+  <h1>Header 1</h1>
 </body>
 </html>

В этом примере все предельно ясно и понятно. Строка

1
--- a/index.html
- это фиксированная версия файла
1
index.html
. Строка
1
+++ b/index.html
- это измененная версия файла
1
index.html
.

Две строки:

-
+  <h1>Header 1</h1>

… отображают, сколько и каких строк удалено (знак минус); сколько и каких строк добавлено (знак плюс).

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

1
git diff
выполняет сравнение версии файла из области Repository и этой же версии из области Working Area.

Staging Area

Второй вариант - файл

1
index.html
отслеживается, в него внесено изменение, которое проиндексировано (внесено в область Staging Area).

Команда

1
git diff
ничего не покажет, так как изменения в файле
1
index.html
были перенесены (
1
git add
) из области Working Area в область Staging Area. Другими словами, область Working Area чистая и в ней нет ничего, чтобы можно было сравнить с областью Repository.

В этом случае для команды

1
git diff
необходимо добавить ключ
1
--staged
. Тогда вывод будет примерно таким:

$ git diff --staged
diff --git a/index.html b/index.html
index 8fbea1c..fff54a9 100644
--- a/index.html
+++ b/index.html
@@ -5,6 +5,6 @@
   <title>Index</title>
 </head>
 <body>
-
+  <h1>Header 1</h1>
 </body>
 </html>

Ключ

1
--staged
указывает, что необходимо сравнивать область Repository с областью Staging Area.

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

1
git diff --staged
производит сравнение области Repository с областью Staging Area.

Repository

Третий вариант - файл

1
index.html
отслеживается, в него внесены изменения, которые проиндексированы (
1
git add
) и зафиксированы (
1
git commit
).

В этом случае область Working Area и Staging Area чистые от изменений, поэтому область Repository нельзя сравнивать с ними - там нет ничего для сравнения.

Поэтому команда

1
git diff
или
1
git diff --staged
ничего не покажет - сравнивать то не с чем!

Так как все изменения зафиксированы и перенесены в область Repository, то и сравнивать их между собой нужно только там, в этой области.

В этом случае команда сравнения

1
git diff
будет выглядеть примерно таким образом:

$ git diff 0644c20  73a4c4c
diff --git a/index.html b/index.html
index fff54a9..8fbea1c 100644
--- a/index.html
+++ b/index.html
@@ -5,6 +5,6 @@
   <title>Index</title>
 </head>
 <body>
-  <h1>Header 1</h1>
+
 </body>
 </html>

Здесь

1
0644c20
- это первые семь символов hash-суммы последнего commit’а,
1
73a4c4c
- первые семь символов hash-суммы предпоследнего commit’а.

Их можно получить командой:

$ git log --oneline

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

Итак, разобрались с третим вариантом - когда сравниваются командой

1
git diff hash_sum_1 hash_sum_2
между собой различные коммиты, расположенные в области Repository.

На этом все.


Решил написать небольшой обзор по редактору Remarkable

Озадачился выбором markdown-редактора под Linux. После недолгих поисков с легким и приятным удивлением нашел две программы под эту операционную систему. Все течет, все меняется и вот теперь под Linux есть два достойных markdown-редактора.

Первый редактор - это Remarkable, второй редактор - это Haroopad. После недолгого сравнения обеих программ оставил в своей коллекции редактор Remarkable по нескольким причинам.

Обзор Remarkable

Чем мне понравился Remarkable? Это простая и интуитивно понятная программа, с таким же приятным и понятным интерфейсом. Что называется - установил и пользуйся.

Одна особенность этого редактора - на момент написания статьи существует только версия под Linux (преимущественно под Ubuntu).

После установки и запуска редактор будет иметь такой примерный вид:

Remarkable - markdown editor

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

Вставка, открытие и сохранение документа; иконки Undo и Redo; форматирование текста - Bold, Italic, Stroke; удобные кнопки для вставки на страницу изображения, ссылки или timestamp:

Remarkable - insert images and links

Окно редактора Remarkable разбито на две части - левая для редактирования, правая - для предпросмотра. Все как и должно быть в нормальном markdown-редакторе.

Предварительный просмотр можно отключить:

Remarkable - disable live preview

Есть также “ночной” режим работы:

Remarkable - night mode

Программа поддерживает синтаксис Github Flavoured Markdown:

Markdown Support

Markdown Support

На GitHub имеется подробный пример markdown-синтаксиса - Remarkable Demo, созданного в этом редакторе. Там есть что посмотреть и чему поучиться - своеобразная реклама редактора Remarkable.

Ниже приведен официальный демо-ролик, показывающий возможности редактора Remarkable:

Одна приятная и мощная особенность редактора - возможность экспортирования в HTML или PDF.

Remarkable автоматически подсчитывает число строк, слов и символов в тексте и отображает эту информацию в строке состояния.

Заключение

Мой субъективный вывод - программа Remarkable является отличным выбором markdown-редактора под Linux. Простая, удобная, интуитивно понятная.

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

На этом все.


Продолжаю изучение темы Git и GitHub. На повестке дня стоит вопрос - каким образом можно изменить ссылку существующего репозитория?

Нет - не так! Попробую зайти с другой стороны и сказать иначе. Имеется готовый репозиторий Template, размещенный на сервере GitHub. Этот репозиторий является шаблоном (template starter) при создании разнообразных проектов. Нечто похожим на известный HTML5 Boilerplate.

Репозиторий Template клонируется на локальную машину с именем разрабатываемого проекта, такой командой:

$ git clone https://github.com/gearmobile/template.git project

Затем в созданном репозитории Project разрабатывается требуемый проект.

Но есть одно НО - необходимо преобразовать видоизмененный репозиторий Project в отдельный, самостоятельный репозиторий. Конечно, по большому счету, это уже и есть отдельный, самостоятельный репозиторий.

Но вот ссылка у репозитория Project указывает на оригинал - репозиторий Template. И если произвести

1
push
на GitHub, то произойдет обновление репозитория Template.

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

У меня же стоит такая задача - скопировать стартовый репозиторий Template на локальную машину, преобразовать его в конкретный проект, вновь залить на GitHub уже как самостоятельный репозиторий с именем проекта в качестве имени репозитория. Как поступить?

Можно решить вопрос несколькими способами. Ниже приведу пару из них - самых простых и доступных для моего понимания вечного newbie в Git\GitHub. Может быть, по мере освоения темы дополню статью более универсальным и грамотным способом.

Правка config

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

1
config
по пути
1
.git/config
, в секции
1
[remote "origin"]
, в переменной с именем
1
url
:

$ cat .git/config

[core]
  repositoryformatversion = 0
  filemode = true
  bare = false
  logallrefupdates = true
  ignorecase = true
  precomposeunicode = true

[remote "origin"]
  url = https://github.com/gearmobile/template.git
  fetch = +refs/heads/*:refs/remotes/origin/*

[branch "master"]
  remote = origin
  merge = refs/heads/master

Поэтому в локальном репозитории Project можно просто изменить эту ссылку с помощью любого текстового редактора.

Отредактирую файл

1
config
и изменю в нем ссылку с

https://github.com/gearmobile/template.git

на

https://github.com/gearmobile/project.git

… где последняя - это ссылка на новый пустой репозиторий Project, который я создал на GitHub.

Теперь конфигурационный файл

1
config
для локального репозитория Project будет выглядеть таким образом (обратить внимание на переменную
1
url
):

$ cat .git/config

[core]
  repositoryformatversion = 0
  filemode = true
  bare = false
  logallrefupdates = true
  ignorecase = true
  precomposeunicode = true

[remote "origin"]
  url = https://github.com/gearmobile/project.git
  fetch = +refs/heads/*:refs/remotes/origin/*

[branch "master"]
  remote = origin
  merge = refs/heads/master

Все - теперь локальный репозиторий Project является абсолютно самостоятельным и уникальным репозиторием, связанным ссылкой со своей удаленной копией на сервере GitHub.

Осталось только сделать

1
push
, чтобы залить на GitHub. Правда, здесь придется воспользоваться ключом
1
-f
(как это описано в предыдущей статье Откат коммитов на GitHub):

$ git push -f

Команда set-url

Второй способ практически идентичен предыдущему за тем лишь исключением, что он более правильный, так как для изменения url-адреса репозитория используется предназначенная для этого консольная команда Git -

1
set-url
.

Точно также создаю на локальной машине копию Another Project удаленного репозитория Template:

$ git clone https://github.com/gearmobile/template.git another-project

Ссылка в новом репозитории Another-Project все также указывает на свой оригинал - репозиторий Template:

$ cat .git/config

[core]
  repositoryformatversion = 0
  filemode = true
  bare = false
  logallrefupdates = true
  ignorecase = true
  precomposeunicode = true

[remote "origin"]
  url = https://github.com/gearmobile/template.git
  fetch = +refs/heads/*:refs/remotes/origin/*

[branch "master"]
  remote = origin
  merge = refs/heads/master

Создаю на GitHub новый репозиторий Another-Project, который будет удаленной копией локального (уже существующего) репозитория Another-Project. И изменяю ссылку на вновь созданный удаленный репозиторий Another-Project:

$ git remote set-url origin https://github.com/gearmobile/another-project.git

Проверяю, изменилась ли ссылка в конфигурационном файле

1
config
(переменная
1
url
):

$ cat .git/config

[core]
  repositoryformatversion = 0
  filemode = true
  bare = false
  logallrefupdates = true
  ignorecase = true
  precomposeunicode = true

[remote "origin"]
  url = https://github.com/gearmobile/another-project.git
  fetch = +refs/heads/*:refs/remotes/origin/*

[branch "master"]
  remote = origin
  merge = refs/heads/master

Да, ссылка была успешно изменена на новый удаленный репозиторий Another-Project. Можно вносить изменения и выполнять

1
push
на GitHub.

Небольшое заключение

Преимущество двух описанных выше способ в том, что не теряется история коммитов.

На этом пока все.