Сегодня по подписке мне на почту пришла ссылка на статью “Bootstrap’s Grid System vs. Susy: A Comparison”. Пришла как нельзя кстати - я сам задавался для себя таким вопросом - что лучше выбрать для себя в качестве системы построения разметки (grid system) - мега-популярный Bootstrap или менее популярную, но более гибкую и функциональную Susy? И вот пожалуйста - сравнительное описание уже готово - осталось его только прочитать!

Более того, c автором статьи Zell Liew я заочно знаком - на моем бложике есть переводы его статьей по теме Susy: “Краткое руководство по Susy 2”, “Краткое введение в Susy 2 (Часть 2)”, “Статические сетки с помощью Susy 2”. Более того, к этому времени он уже успел написать собственную книгу, посвященную Susy - Learning Susy.

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

Введение

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

Сегодня я хотел бы представить вашему вниманию менее известный фреймворк - Susy. В этой статье я сделаю сравнение между системами построения разметки (grid system) Susy и Bootstrap. Благодаря этой статье читатель может четко уяснить для себя, что собой представляет Susy и можно ли ее использовать на практике.

Что такое Susy

Для того, чтобы ответить на этот вопрос, нужно сначала ответить на другой вопрос - “Что такое grid (CSS-сетка)?”

В терминологии web-дизайна grid (CSS-сетка) - это всего лишь набор вертикальных линий, которые располагаются на web-странице сверху вниз. Эти линии пришли в web из печатного издания (типографии) и сегодня используются web-дизайнерами повседневно и повсеместно для создания основы web-страницы, с помощью которой облегчается возможность организации и представления информации:

Эти вертикальные линии помогают выполнить задачу разделения всего пространства web-страницы на два вида полос. Более широкий вид полосы называется колонкой (column), а более узкий - канавкой (gutter). Организация и расположение элементов страницы “привязывается” к этим колонкам (columns) и канавкам (gutters):

Систему сеток (grid system), описанную выше, используют множество CSS-фреймворков. Наиболее известные (в качестве примера) из них:

• 960 grid system
• 1140px grid system
• Bootstrap
• Foundation

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

Susy является движком для создания разметки web-страницы (layout). Это набор инструментов, с помощью которых можно создать произвольную CSS-сетку (grid), которая отвечает потребностям дизайна конкретной web-страницы. Susy предоставляет в ваше распоряжение гибкость и свободу действий в web-разработке.

Что такое Bootstrap

Bootstrap - это больше, чем просто фреймворк для создания CSS-сетки (grid) разрабатываемой web-страницы. Это полноценный набор инструментов, имеюший в своем составе большое количество самых разнообразных возможностей для создания web-страницы:

• система построения разметки (grid system);
• готовые CSS-стили для большинства стандартных элементов web-страницы, таких как навигация, формы, иконки;
• готовые jQuery-плагины для сложных элементов web-страницы, таких как аккордеон или карусель.

Теперь, когда стала ясна разница между Susy и Bootstrap, становится понятно, что невозможно сравнивать между собой два таких разных программных продукта. Основа у этих инструментов совершенно разная.

Тем не менее, в дальнейшей части этой статьи будет произведено детальное сравнение между Susy и системой построения разметки (grid system) фреймворка Bootstrap. Между ними все же существует несколько общих черт, по которым можно произвести аналогию:

• Язык используемого препроцессора
• Способ создания разметки (markup)
• Возможность редактирования CSS-сетки
• Возможность настройки breakpoints
• Взаимосвязь HTML и CSS
• Документация и сообщество

Язык используемого препроцессора

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

Несмотря на то, что первоначально Bootstrap был создан на Less, на сегодняшний день Bootstrap поддерживает два препроцессора - Sass и Less. Таким образом, язык препроцессора не является препятствием при использовании Bootstrap - можно воспользоваться любым из двух.

Последняя версия Susy (Susy 2) работает только совместно с Sass версии 3.3. и выше, потому что для Susy 2 необходима поддержка Sass-карт Sass maps. Предыдущая более ранняя версия “Susy One” использует для своей работы Sass ниже версии 3.3. К сожалению, Susy не подерживает Less.

Способ создания разметки (markup)

Чтобы увидеть разницу в способе создания разметки (markup) web-страницы, давайте создадим простой пример:

Фреймворк Bootstrap требует использования в обязательном порядке классов наподобие

1

.row

1

.col-md-4

Вышеупомянутое требование является наиболее критикуемым моментом в Bootstrap. Противники Bootstrap заявляют, что все подобные классы относятся к репрезентационным и им не место в HTML-разметке страницы.

Ниже приведен пример кода, с помощью которого создается разметка на Bootstrap - со всеми необходимыми классами в данном случае. Дополнительно применены классы, относящиеся непосредственно к системе построения разметки (grid system):

<div class="container-fluid">
  <div class="row">
    <div class="col-md-8 content">
      <h2>
        Content
      </h2>
    </div>
    <div class="col-md-4 sidebar">
      <h2>
        Sidebar
      </h2>
    </div>
  </div>
</div>

Для сравнения, ниже приведен код на Susy для создания аналогичной разметки (markup):

<div class="wrap">
  <div class="content">
    <h2>
      Content
    </h2>
  </div>
  <div class="sidebar">
    <h2>
      Sidebar
    </h2>
  </div>
</div>

Как хорошо видно, разметка на Susy гораздо проще и более семантичная, нежели аналогичная разметка на Bootstrap. Однако, создание разметки с помощью Susy на этом не заканчивается - необходимо добавить CSS-стили для классов

1

content

1

sidebar

Первое, на что необходимо обратить внимание, так это тот факт, что Bootstrap добавляет канавки (gutters) в качестве CSS-свойства

1

padding

По умолчанию, Susy “прилепляет” канавку (gutter) в качестве CSS-свойства

1

margin

1

gutter-position

1

#susy

$susy: (
  gutter-position: inside
)

Примечание переводчика - автор немного “поскромничал”, не сказав, что у него имеется своя собственная статья, посвященная позиционированию gutter в Susy - “Understanding Gutter Positions in Susy”.

В каждой CSS-сетке, создаваемой с помощью Susy, к классу

1

.container

1

container

1

.container

1

.wrap

.wrap {
  @include container(1140px);
}

В предыдущем случае, когда выполнялась разметка с помощью Bootstrap, выделялись 8 колонок (columns) под контент и 4 колонки (columns) под блок с классом

1

.sidebar

1

span

1

.content

1

.sidebar

.content {
  @include span(8 of 12);
}

.sidebar {
  @include span(4 of 12);
}

Разметка на Susy более простая, нежели на Bootstrap. Однако, обратной стороной этой простоты является факт, что придется выполнить больше работы по подключению миксинов и общей настройке классов. В то время как Bootstrap предоставляет все необходимые классы в готовом виде.

Возможность редактирования CSS-сетки

Bootstrap предоставляет возможность редактирования системы построения разметки (grid system) только в ограниченных пределах. Имеется возможность свободно изменять такие вещи, как:

• количество колонок (columns)
• размер канавки (gutter)
• значения четыре доступных breakpoints (

  1

  xs

  ,

  1

  sm

  ,

  1

  md

  ,

  1

  lg

  )

Все вышеперечисленные параметры можно настроить двумя способами:

• выполнить конфигурирование на вкладке “Customize and download” официальной страницы Bootstrap прежде, чем скачивать готовый дистрибутив
• если используется любой из препроцессоров (Sass или Less), то изменить значения соответсвующих переменных

  1	_variables

В обоих случаях, настройки для колонок (columns) и канавок (gutters) находятся в разделе с названием Grid System; настройки для медиа-запросов (media queries) находятся в разделе под названием Media Queries Breakpoints.

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

• количество колонок (columns)
• размер каждой из колонки в отдельности
• размер канавки (gutter)
• позиционирование канавок (gutters)
• количество breakpoints
• направление потока слева направо или справа налево
• блочную модель (box model)

… и еще много чего.

Наподобие других систем для построения разметки (grid system), таких как Singularity или GridsetApp, которые наиболее часто применяются для постороения ассиметричной разметки (asymmetric layout), Susy также умеет создавать ассиметричные CSS-сетки. Хорошие примеры построения таких сеток размещены здесь:

• The Marber - Gridset
• The Gerstner - Gridset
• Typekit + Gridset Demos

Примечание переводчика - у автора статьи на его официальном сайте имеется статья, посвященная созданию ассиметричной разметки на Susy - “Creating Asymmetric Layouts With Susy”.

Одна из таких сеток, созданная Nathan Ford мне нравиться и я сделал аналогичный вариант ассиметричной разметки с помощью Susy. Теперь нет необходимости применять какую-либо стандартную систему построения разметки (grid system) - Susy может удовлетворить всем требованиям разработчика.

Примечание переводчика - автор статьи использовал online-инструмент SassMeister для написания кода под препроцессор Sass. Если данный вопрос незнаком читателю, то можно обратиться к ссылке - “Знакомимся с редактором SassMeister”.

Возможность настройки breakpoints

Как уже упоминалось ранее, Bootstrap имеет возможность применения в создаваемой разметке до 4 контрольных точек (breakpoints):

1

xs

1

sm

1

md

1

lg

В рассматриваемом нами примере, если попробовать уменьшить размер окна браузера меньше 991px, то блок с классом

1

.content

1

.sidebar

Предположим, что возникла задача сделать так, чтобы оба блока с классами

1

.content

1

.sidebar

<div class="container-fluid">
  <div class="row">
    <div class="col-xs-6 col-md-8 content">
      <h2>
        Content
      </h2>
    </div>
    <div class="col-xs-6 col-md-4 sidebar">
      <h2>
        Sidebar
      </h2>
    </div>
  </div>
</div>

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

<div class="wrap">
  <div class="content">
    <h2>
      Content
    </h2>
  </div>
  <div class="sidebar">
    <h2>
      Sidebar
    </h2>
  </div>
</div>

В данном случае необходимо добавить контрольную точку

1

breakpoint

При создании такой контрольной точки

1

breakpoint

1

.content

1

.sidebar

1

.content

1

.sidebar

.content {
  @include span(6 of 12);
  @media (min-width: 980px) {
    @include span(8 of 12);
  }
}

.sidebar {
  @include span(6 of 12);
  @media (min-width: 980px) {
    @include span(4 of 12);
  }
}

Bootstrap требует аккуратного обращения с именами CSS-классов при создании HTML-разметки. Когда создается проект на Bootstrap, мне всегда приходиться помнить точные имена классов для контрольных точек.

В Susy наоборот - весь процесс кодинга перемещается из области HTML-документа в область Sass-файла, в котором также необходимо соблюдать осторожность. Я предпочитаю размещать контрольные точки (breakpoints) именно в таблице стилей, так как в этом случае общая картина проекта становиться более наглядной для меня.

В зависимости от предпочтений, можно использовать Bootstrap или Susy - оба они хорошо выполняют свою задачу построения разметки. Лично я предпочитаю Susy, так как в этом случае имется возможность “разъединить” HTML и CSS между собой. Данный факт плавно приводит меня к следующему вопросу.

Взаимосвязь HTML и CSS

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

Просто представим на минуту то время, когда весь CSS-код размещался внутри HTML-кода с помощью атрибута

1

style

1

.col-xs-6

1

.col-md-4

1

.row

1

style

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

1

.col-

1

.content

<div class="col-md-7 content">
  <h2>
    Content
  </h2>
</div>

Становиться понятно высказывание о том, что HTML и CSS-файлы с такой тесной взаимосвязью очень тяжело поддерживать.

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

1

.content

1

span

.content {
  @include span(7 of 12);
}

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

Так как благодаря Susy появляется возможность свободного управления HTML и CSS-файлами, то можно применить на своей практике любую из популярных CSS-методологий, таких как SMACSS, OOCSS или BEM. При этом отпадает необходимость заботиться о том факте, каким образом любая из этих методологий будет взаимодействовать с вашим конкретным HTML-файлом.

Документация и сообщество

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

Документация к Bootstrap и его сообщество достаточно развитые. Если у вас возникают какие-либо проблемы, вы всегда можете написать вопрос на Stack Overflow или на любой другой форум, посвященный кодингу. Обязательно найдется знающий человек, который сможет и захочет помочь в решении вашего вопроса.

Напротив, документация по Susy не такая детальная; а сообщество (пока) не слишком большое. При изучении возможностей Susy и способов создания web-сайтов на основе этого фреймворка могут возникнуть проблемы, которые и отталкивают многих от перехода с Bootstrap на Susy. Для того, чтобы попробовать устранить этот недостаток, мною написана книга “Learning Susy”. Всем интересующимся можно ознакомиться с ней.

Заключение

Несмотря на тот факт, что Bootstrap и Susy являются совершенно различными инструментами, в этой статье мы смогли произвести сравнение между системами построения разметки (grid system) обоих фреймворков. Как я уже упоминал ранее, у меня есть твердое убеждение в том, что Susy является гораздо более удобным инструментом для создания разметки.

Если вы заинтересовались возможностью дальнейшего изучения Susy, посетите официальный сайт этого проекта, почитайте документацию к этому фреймворку или скачайте бесплатно “5 глав из моей книги”.

Продолжаю увлекательное знакомство новичка с сервисом GitHub и с системой контроля версий Git.

Так как имею учетную запись на GitHub, которую регулярно использую, то у меня возник вопрос, который не мог не возникнуть, рано или поздно. Касается он такой темы, как fork.

Не знаю даже, как правильно поступить дальше - попытаться самому описать вопрос, своими словами; или же попытаться сделать вольный перевод статьи на эту тему - Fork A Repo. Но лучше все же расскажу своими словами.

Fork - это копия репозитория

Fork - это вcего навсего копия репозитория. Это тоже самое, что branch в Git. Только на GitHub такой branch называется

1

fork

1

fork

1

fork

Для чего нужен

1

fork

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

1

pull request

Если авторам оригинального репозитория ваши изменения понравятся, то они могут внести их в свой собственый оригинальный репозиторий - принять запрос и выполнить слияние.

Существование fork полностью отвечает идеологии OpenSource и GitHub, в частности. Идеология OpenSource заключается в свободном обмене исходным кодом программ и fork однозначно помогает в этом деле. С помощью fork можно одним движением получить копию любого исходного кода, выложенного на GitHub в свободном доступе.

Fork - создание копии репозитория

Давайте от слов перейдем к делу и на практике выполним хотя бы один fork на GitHub. К слову сказать, в приведенной выше статье-оригинале Fork A Repo дается ссылка на репозиторий Spoon-Knife, созданный авторами статьи для учебных целей - научиться работать с fork на GitHub. Вы, уважаемый читатель, также можете свободно воспользоваться им для себя, чтобы научиться пользоваться fork.

Я воспользуюсь другим репозиторием, который выложен в свободном доступе достаточно известным верстальщиком Юрием Артюхом (akella). Ниже привожу шаги по созданию Fork на GitHub.

• захожу на GitHub под своей учетной записью
• перехожу по ссылке github/akella/sass, по которой расположен репозиторий akella/sass

Фактически, теперь я нахожусь в репозитории akella/sass пользователя akella (Юрий Артюх). Об этом красноречиво говорит надпись akella/sass в левом верхнем углу окна браузера. В правом верхнем углу окна браузера нахожу кнопку Fork.

И нажимаю на нее:

Может случиться, что вы, уважаемый читатель, ничего и не заметите. Но это не так на самом деле. Приглядитесь к “главной” надписи - она изменилась с

1

akella/sass

1

gearmobile/sass

1

forked from akella/sass

Теперь этот репозиторий мой - точнее, у меня теперь копия оригинального репозитория

1

akella/sass

Если изменения мне покажутся существенными, то я могу отправить пользователю akella запрос на слияние

1

pull request

1

gearmobile/sass

1

akella/sass

Я также могу удалить репозиторий gearmobile/sass, если в нем отпадет надобность. Надеюсь, вы хорошо помните, как удалять репозиторий на GitHub - “Как удалить репозиторий на GitHub”.

Продолжаю совместно с вами постепенно изучать магию Git\GitHub.

Слово магия здесь применено не случайно - не иначе, как магией возможности Git\GitHub не назовешь. По крайней мере, я впечатлен этими возможностями. Другое дело, что процесс изучения Git у меня лично идет как-то тяжеловато. Ну, это не страшно - главное, не останавливаться!

В этом разделе я попытаюсь осветить для себя (и возможно, для вас, уважаемый читатель) вопрос создания ветвей (branches) в Git, перемещение между ветвями (branches), слияние (merge) ветвей. Этот вопрос очень подробно и хорошо описан на странице официальной документации - “Git Branching - Basic Branching and Merging”. Здесь я попробую самостоятельно описать данный вопрос.

Инициализация Git-репозитория

Создаю тестовую директорию

1

git_branches

$ mkdir git_branches
$ cd git_branches
$ touch index.html
$ touch style.css

$ git init
Initialized empty Git repository in /home/username/Desktop/projects/git_branches/.git/

$ git add .
$ git commit -m 'first launch'
[master (root-commit) eeb12ca] first launch
 2 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 index.html
 create mode 100644 style.css

$ git status
On branch master
nothing to commit, working directory clean

Обратите на строку

1

On branch master

1

git status

1

master

Итак, мы уже кое-что узнали. А именно - при инициализации Git-репозитория была автоматически создана ветвь (branch) по имени

1

master

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

1

index.html

1

style.css

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

Git - создание новой ветви (branch)

В системе Git (как уже упоминалось ранее) имеется механизм ветвления (branches). Попробую на словах объяснить, что он из себя представляет.

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

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

1

second

1

master

$ git checkout -b second
  Switched to a new branch 'second'

Строка

1

Switched to a new branch 'second'

1

second

$ git status
  On branch second
  nothing to commit, working directory clean

Строка

1

On branch second

Отлично! Теперь давайте я внесу некоторые изменения в файлы

1

index.html

1

style.css

Не забуду также проиндексировать и зафиксировать внесенные изменения. Обратите внимание на вид команды -

1

git commit -a

1

git add

1

git commit -m

$ git commit -a -m 'Modify Brach Second'
  [second e4b5d5d] Modify Brach Second
  2 files changed, 24 insertions(+), 14 deletions(-)
  rewrite index.html (72%)

Смотрим, что у нас получилось в окне браузера - то, что и ожидалось:

Git - переключение между ветвями (branches)

А теперь настал самый интересный момент. Как вы помните, мы сейчас находимся в ветви

1

second

1

master

$ git checkout master
  Switched to branch 'master'

Оп! Мы видим старую картину - Git “запечатлел” тот момент, когда мы совершили переход из ветви

1

master

1

second

1

master

$ git log --pretty=oneline
  b7105dab98d2f3798b5456c35695a4e906a80e92 Master Branch
  eeb12ca79f224af90cd31cf470143998a6312249 first launch

Если я снова вернусь в ветку

1

second

$ git checkout second
  Switched to branch 'second'

  $ git log --pretty=oneline
  e4b5d5df7a4b9a3ee56a7298726bdab4691a5a58 Modify Brach Second
  b7105dab98d2f3798b5456c35695a4e906a80e92 Master Branch
  eeb12ca79f224af90cd31cf470143998a6312249 first launch

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

Git - слияние ветвей (branches)

В предыдущем шаге я создал ветвь

1

second

1

master

Фактически, я хочу сделать слияние двух веток -

1

master

1

second

1

master

$ git checkout master
  Switched to branch 'master'

  $ git merge second
  Updating b7105da..e4b5d5d
  Fast-forward
   index.html | 8 ++++++--
   style.css  | 6 ++++++
   2 files changed, 12 insertions(+), 2 deletions(-)

Команда слияния проста - я просто указываю имя той ветки (branch), которую хочу слить (merge) с текущей, в которой я нахожусь на данный момент.

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

Давайте снова “заглянем” в окно браузера - что он нам интересного покажет?

Показал он то, что и следовало показать - результат объединения двух ветвей

1

master

1

second

Git - графическое представление ветвей (branches)

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

Это можно сделать, набрав в консоли команду:

$ git log --oneline --abbrev-commit --all --graph

На Stack Overflow я нашел примеры красивых изображений консоли с псевдографическим выводом команды

1

git log

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

1

git log

1

--graph

Помимо псевдографики, ветви в Git можно визуализировать с помощью настоящего графического приложения. Под Mac OS X и Linux имеется достаточно большое количество таких приложений. Например, под Mac OS X это GitX, под Linux - Gitk или Gitg:

Git - удаление ветви (branch)

В разделе слияния ветвей в Git я научился процессу объединения двух ветвей в одну. Такой процесс в Git имеет название

1

merge

1

master

1

second

1

second

Выполняется это командой:

$ git branch -d second
  Deleted branch second (was 19a8328).

Посмотрим на вывод команды

1

git hist

$ git hist
  * fa8b252 2014-09-03 | Last Commit in Master Branch (HEAD, master)
  *   22a9487 2014-09-03 | Merge Second Branch in Master Branch (origin/master, origin/HEAD)
  |\
  | * 19a8328 2014-09-03 | Six Commit in Second Branch
  | * e273e6c 2014-09-03 | Fifth Commit in Second Branch
  | * 8e2fe40 2014-09-03 | Fourth Commit in Second Branch
  | * 3290a23 2014-09-03 | Third Commit in Second Branch
  | * 0584a1c 2014-09-03 | Second Commit in Second Branch
  | * 38fab33 2014-09-03 | First Commit in Second Branch
  * | 8543256 2014-09-03 | Seventh Commit in Master Branch
  * | e852688 2014-09-03 | Six Commit in Master Branch
  * | d6ccde3 2014-09-03 | Fifth Commit in Master Branch
  * | c0d8e2f 2014-09-03 | Fourth Commit in Master Branch
  * | 7d2377a 2014-09-03 | Third Commit in Master Branch
  |/
  * b3e0f1f 2014-09-03 | Second Commit in Master Branch
  * be4e1f0 2014-09-03 | First Commit in Master Branch
  * ac2961a 2014-09-03 | Added git_branches
  * db9e01b 2014-09-03 | Initial commit

У меня осталась одна ветвь -

1

master

Еще один важный практический вопрос при работе с Git - это операции с файлами.

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

1

rm

1

mv

1

git rm

1

git mv

Команда git rm

Для удаления файлов в системе Git, как уже упоминалось выше, имеется специальная команда

1

git rm

1

rm

Как хорошо известно, в системе Git файл может одновременно существовать в трех ипостасях: в области “Working Directory”, в области “Staging Area”, в области “Repository”. Удаление файла из области “Working Directory” не приведет к его удалению из областей “Staging Area” и “Repository”.

Поэтому, чтобы удалить файл, нужно (в идеале) выполнить три команды подряд для удаления файла из Рабочей области “Working Directory”, затем из области индекса “Staging Area” и потом из области репозитория “Repository”:

$ rm index.html
$ git add .
$ git commit -m 'Delete file index.html'

Команда

1

git rm

$ rm index.html
$ git add .

Сделано это всего лишь для удобства пользования системой Git. Давайте на примере посмотрим работу команды

1

git rm

1

index.html

Удалим его командой

1

git rm

Видим, что файл

1

index.html

1

git status

Любой последующий commit зафиксирует удаление этого файла:

Команда git rm -cached

У команды

1

git rm

1

--cached

1

git rm

1

second.html

Удалим его командой

1

git rm --cached

Отлично! Видим, что произошло удаление файла

1

second.html

1

git status

1

second.html

Команда git rm -f

В предыдущем разделе я рассмотрел вариант, когда созданный и проиндексированный файл удаляется из области индексирования “Staging Area”, но остается в области “Working Directory”. Выполняется это с помощью команды

1

git rm --cached

Логическим продолжением этой команды является та же самая команда

1

git rm

1

-f

1

git rm -f

Давайте рассмотрим на примере созданного и проиндексированного файла

1

third.html

1

git rm -f

Файл

1

third.html

1

git rm -f

1

git rm

Команда git mv - перемещение или переименование файлов

В системе Git имеется “своя” команда для перемещения или переименования файлов. Слово “своя” здесь не даром взято в кавычки - аналогия с командой

1

git rm

1

git mv

Остается только зафиксировать эти изменения любым коммитом:

$ git commit -m 'Move index.html to papka'
  [master 868d428] Move index.html to papka
   1 file changed, 0 insertions(+), 0 deletions(-)
   rename index.html => papka/index.html (100%)

Переименуем файл

1

index.html

1

git mv

Вот и все несложные операции по перемещению\переименованию или удалению файлов с помощью команд

1

git rm

1

git mv

Продолжаю открывать для себя возможности системы Git и сервиса GitHub.

Уже сейчас, обладая минимальными базовыми знаниями Git и владея учетной записью на сервере GitHub, я не представляю, как я мог жить раньше без обоих этих вещей. Это действительно удобно и надежно!

Благодаря им я знаю, что у меня никогда и ничто не потеряется; и все, что нужно - у меня всегда под рукой. На работе поработал над чем-либо - отправил на GitHub; домой пришел - “стянул” наработки с GitHub и продолжил работу с прерванного места.

Вот на последнем я хотел бы остановиться подробнее. Конечно, веб-разработчик, давно и хорошо знакомый с Git и GitHub, может только улыбнуться насчет того, чем я собираюсь поделиться. Настолько все это просто и понятно. Но это просто и понятно для него, опытного web-разработчика. А для начинающего веб-программиста - это новое и неизведанное. Впрочем, достаточно лирики - переходим к практике.

GitHub - команда push

В предыдущей статье я познакомился с возможностью создания репозитория на сервисе GitHub. И возможностью клонирования этого репозитория на локальную машину - “GitHub и Git - создание и работа с репозиторием”.

Напомню, что в том примере было произведено клонирование репозитория с помощью команды:

$ git clone git@github.com:gearmobile/arbeit.git

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

После внесений изменений в локальный репозиторий - индексации и фиксации - необходимо было отправить произведенные изменения на удаленный сервер, на GitHub.

Для этой цели существует (и я ею воспользовался) команда

1

push

$ git add .

$ git commit -m 'Continue write article about push and pull in GitHub'
[master 5af3abc] Continue write article about push and pull in GitHub
 1 file changed, 18 insertions(+)

$ git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)
nothing to commit, working directory clean

$ git push
...
Counting objects: 7, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 1.65 KiB | 0 bytes/s, done.
Total 4 (delta 1), reused 0 (delta 0)
To git@github.com:semenencko/articles
   022b756..5af3abc  master -> master

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

GitHub - команда pull

Продолжим логическую картину моего рабочего процесса (workflow). На следующий день я прихожу на работу и у меня есть время и возможность поработать над своим проектом. Естественно, я хочу продолжить с того места, на котором остановился дома. Для этого я воспользуюсь командой

1

pull

В данном случае команда

1

pull

В выводе консоли (на картинке) видно, что было произведено добавление одного измененного файла по имени README.md, в котором были добавлены две строки.

Обратите внимание на разницу между командами

1

clone

1

pull

1

clone

1

pull

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

GitHub - команда fetch

Существует разновидность команды

1

pull

1

fetch

Команда

1

pull

Команда

1

fetch

На картинке выше показано, что была выполнена команда

1

git fetch

1

git status

1

git pull

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

$ git pull
$ git add .
$ git commit -m 'Added fetch image'
$ git push

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

1

git fetch

Вернувшись к вышесказанному, можно сделать вывод, что команда

1

pull

1

fetch

1

pull