Этот пост предназначен для тех, кто приступает только работать на Git. Все нижесказанное будет предназначено для Unix окружения и оболочки Bash.

1. Заходим в Unix, где есть bash & git
2. Для начала работ с git отконфигурируем его глобальные настройки для того пользователя, под которым мы будем работать, то есть под себя:

   git config --global user.name "Your nickname/name"
   git config --global user.email "your@email.com"
   git config --global i18n.commitEncoding utf8
   git config --global status.showUntrackedFiles all
   

   Здесь по строкам: 1 — указываем своё имя, будет видно в логах истории (git log); 2 — ваш email, будет видно там же; 3 — вы указываете, в какой кодировке будете писать комментарии к коммитам (commits), рекомендую UTF-8, а значит, надо, чтобы ваш терминал с Unix был в той же кодировке (если всё сделаете правильно — с русскими буквами проблем не будет, даже если кто-то будет писать commit в windows-1251 кодировке — git умеет конвертировать их прозрачно); 4 — весьма полезная опция — рекомендую поставить (см. последний пример)

3. Создание репозитария («репо», repo). Можно взять готовые исходники, которые вы хотите начать отслеживать git-ом, тогда:

   cd корень_исходников
   git init
   # теперь появится папка .git/
   

   Либо, можете склонировать чей то проект для дальнейших правок, например так:

   cd папка_где_будет_папка_исходников
   git clone sshuser@ssh.host.com:where/git/repo/project.git
   # Теперь будет папка project
   

4. Если вы хотите хранить репозитарий так, чтобы вы или кто-то другой могли его клонировать и закачивать туда, можете поступать так:
   • Если вы проект откуда то уже до этого клонировали, то «закачка» обратно делается просто:

     git push

     Правда, одно условие — оригинальное место, откуда проект скачивали, должно быть read-write доступа. Обычно, общедоступные проекты лежат в read-only доступе.

   • Если вы проект только создали, то вам надо сделать:
     1. Создать место, где будет храниться. Самый простой и надежный способ — создание отдельного Unix аккаунта для этого:

        useradd mygit # Linux вариант

     2. Очень рекомендую положить ваши ssh ключи в ~/.ssh/authorized_keys, чтобы не вводить каждый раз пароль при запуске на удаленной машине:

        man sshd # смотрим раздел "AUTHORIZED_KEYS FILE FORMAT"

     3. Из вашего репозитария, что вы проинициализировали git init сделать bare репозитарий — репозитарий, где нет будет рабочего дерева директорий с исходниками, а будет лишь база git со всеми версиями:

        cd our_project_before_git
        git init # Теперь появилась .git папка с базой, но репозитарий не bare - не годится для всех
        git clone --bare . ../our_project.git # Теперь выше мы создаем bare директорию
        cd ..
        scp -r our_project.git mygit@host.com:our_project.git # закачиваем на хост, откуда потом мы и другие будут забирать его
        

     4. Теперь на удаленном хосте желательно аккаунт mygit ограничить доступом только по git:

        echo /usr/bin/git-shell >>/etc/shells
        # Уточните точный путь до git-shell
        vipw
        # там меняем shell у пользователя mygit на:
        # /usr/bin/git-shell
        # Можно указать shell сразу при создании пользователя через <useradd>

     5. Теперь, чтобы ваш первоначальный репозитарий был закреплен за тем хостом + путь (mygit@host.com:our_project.git) у вас есть два пути:
        1. Либо добавить хост и путь репо как remote origin командой:

           git remote add origin mygit@host.com:our_project.git
           # более подробно - смотрите man git-remote

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

           mygit@host.com:our_project.git

Теперь, пройдемся в кратце еще раз по концепции git, о которой я рассказывал ранее:

Git хранит в своём репозитарии, который хранится в папке .git внутри корня вашего проекта, все файлы всех версий файлов. Точнее, их упакованные версии. Последние версии git иногда хранят дельты, но это редко. Засчет этого, git очень быстро работает, так как оперирует сразу полными версиями файлов, основываясь на иерархии commit-ов. Каждый commit — «снимок» (правильнее — хеш SHA1) рабочей директории (точнее того, что добавлено в «индекс» при commit). То есть, не может быть одного и того же ID commit-в в мире, но с другим сожержимым, кроме вашего проекта именно с теми файлами.

Представьте себе иерархическое дерево, каждый узел которого может иметь одного и более «родителей» (parents), где есть «конечные» узлы, которые не являются родителем для какого либо узла — это «концы» ветки. Ветка в git — не что иное, как указатель на этот самый последний commit, которым все заканчивается. Когда вы делаете очередной commit, указатель ветки переназначается в новый последний commit, а предыдущий становится «родительским» для вновь созданного. Git, оперируя названиями веток, берет всегда от туда «конечный» commit, и далее по parents идет вверх по иерархии. У git есть очень гибкий синтаксис указания списка commit-ов через ветки и иерархические статусы узлов (parents, «предков»), а также через временным интервалы (например, что было сделано за последнюю неделю, например). Имена веток могут содержать ‘/’ символ. Например: git diff feature/foo..master покажет изменения между веткой feature/foo и master, а если быть более точным — покажет изменения в commit-ах, которые недостежими в обоих ветках (то есть, если идти по иерархии от концов обеих веток вверх, то учитывать только те коммиты, которые есть только в одной их них. Если мы доходим до «резвилки», то послее нее, разумеется, коммиты есть в обоих вариантах, и тогда поиск прекращается). По умолчанию принято, что default ветка в git имеет имя master. Часто, разработчики под ней выпускают релизные версии.

Но устройство git такого, что при работе с ним вам надо очень активно использовать ветвление — т.е. создавать свои ветки для новых «фич», тестировать программу, и если все нормально — «сливать» с главной веткой. Это позволяет четко вести разрботку и разграничивать правки кода. Причем, создание веток вами идет локально — вы можете им давать любые имена, не опасаясь, что они пересекутся по названию с ветками других разрботчиков проекта — по умолчанию, новые имена веток хранятся в локальной копии репозитария и при «push» операциях это не затрагивается. Вы легко можете закачать новую ветку в удаленный репозитарий:

git push origin my_new_branch:my_new_branch

Либо даже удалить в удаленном репозитарии какую либо ветку:

git push origin :my_new_branch

Немного по этим двум примерам: синтаксис закачки/выкачки имеет формат src:dst, где src — имя ветки на source, dst — имя ветки на destination. То есть, если мы делаем push, то src — это имя ветки в нащем репозитарии, а dst — имя ветки в удаленном, а если мы делает :my_new_branch, то src — «пусто», т.е. нет, а my_new_branch — имя удаленной ветки — то есть толкнуть «нечто пустое» куда-то — это значит «удалить».

В git есть промежуточный слой между репозитарием и вашей рабочей директорией — индекс (index или stage). Файлы, добавленные в индекс, в документации называются staged. Это поначалу может показаться непривычно, но потом это становится понятным. Это как бы «фильтр», «прослойка», между вашим проектом и репозитарием. Ведь проекты, почти всегда — это не просто исходними, но и служебные файлы, которые создаются при компиляции, тестировании и т.п.. Чтобы не тащить с собой в репозитарий весь «этот мусор», который создается в директории проекта, и индивидуален для каждого разработчика проекта, git имеет этот index. Index — это тоже дерево файлов и директорий, но «очищенное», и содержит в себе только то, что будет добавлено при очередном commit. Если git status показывает какой либо файл как untracked — значит того файла нет в индексе, и пока вы его специально не добавите git add, он не попадет в репозитарий. Для удобства можно делать git add . из корня проекта — добавить все, что не отслеживается, но тогда надо активно следить за файлами .gitignore!

Возьмите себе за правило активно использовать файл .gitignore (см. man gitignore). Этот файл указывает git-у, какие файлы надо исключать при работе и не добавлять в индекс! Эти файлы могут присутствовать в любой поддиректории проекта, и их действие распространяется либо на поддиректории той, где есть этот файл, либо только на файлы в этой — в зависимости, как описана маска файла. Например:

# Это комментарий

# Исключать только Makefile.old из текущей директории!
/Makefile.old

# Исключать все файлы с расширением .o как в этой, так и в поддиректориях
*.o

# Исключать все txt файлы только в этой директории
/*.txt

# Исключать всю директорию build в текущей папке
/build/

#  Исключать все директории в этой и ниже с именем blib, файлы могут быть с таким именем
blib/

И еще парочка заметок. Git не хранит права файлов в репозитарии, за исключением ‘x’ флага, и при клонировании все файлы имеют права либо 644, либо 755. Поэтому не делайте репозитариев, с расчетом на отдельные права некоторых файлов (например, права 600 или 700). Сначала это может кому-то не понравиться, потом привыкаешь. Для разработки проектов этого достаточно, так как все проекты по правильному делаются с двумя фазами — компиляция и инсталирование. Правильные права должны выставляться на последнем этапе дистрибутива. Также, любой клонированный репозитарий может быть репозитарием для другого, если вы это позволите — получается очень распределенная, несокрушимая система К тому же, работа над каждым репозитарием не требует интернета — вы можете делать commit-ы в репозитарий на своем диске (вместо ssh хоста в моих примерах можно использовать обычные Unix пути), а если захотите, то при наличии интернета уже «сливать» коммиты в другой remote репозитарий (см. man git-remote, man git-push)

Вернемся к примерам в начале статтьи. Теперь мы имеем репозитарии, с которыми можно работать. Теперь несколько советов по работе

1. Рекомендую прописать у себя в ~/.bash_profile такие команды, которые использую на основании своего опыта:

   alias gitcommit='git commit -a'
   alias gitdiff='git diff|less -S'
   alias gitgraph='git log --graph --all --decorate|less -S'
   alias gitremote="git remote show origin"
   alias gitlog='git log --decorate'
   export LESS=S#4
   

   Теперь пояснения:
   gitcommit — укороченная команда, когда вы делаете commit (принятие изменений, их фиксация в базе), так, чтобы перед commit были обновлены файлы из рабочего дерева в индекс, а также, чтобы те файлы, которые вы удалили, были также удалены в commit. При такой команде не попадают в commit те файлы, которые есть в рабочем дереве, но нет в индексе (из надо добавлять git add)
   gitdiff — просмотр изменений между рабочим деревом и индексом, но запускает less с опцией -S
   gitgraph — очень полезная командочка для просмотра «дерева» commit-ов и веток
   gitremote — смотрит в удаленный репозитарий origin (может быть несколько репозитариев в git — я сделал для широкоупотребимой ситуации) и показывает статус вашего репозитария в сравнении с удаленным
   gitlog — почти то же, что gitlog, но вместе с commit хешем показывается, если есть, имя версии ветки, которая заканчивается этим commit
   export LESS … — устанавливаем переменную, чтобы команда less работала наиболее удобным способом (см. man less)

2. Как правило, работа сводится к такому примерно списку команд:

   cd my_project
   # например, текущая ветка - master
   git pull # вытащить, если есть, что-то новое из репозитария из ветки master
   
   # не обязательно, но если вы работает в команде, лучше, чтобы ваша новая "фича" велась в отдельной ветке до ее окончания
   git checkout -b new_branch
   # теперь мы в new_branch
   # редактируем как надо что либо
   
   # Проверяем, что мы наделали, смотрим, появились ли новые файлы, которых нет в репозитарии (untracked)
   # если есть untracked - думаем, либо добавлять их в репо,
   # либо добавить в .gitignore, чтобы не маячили в глазах
   # здесь нам пригодится настройка git config --global status.showUntrackedFiles all (см. начало статьи)
   # без этой настройки новые целые директории не показываются пофайлово, а только как имя директории
   git status
   
   # опционально, если есть untracked файлы - можем добавить их, либо сразу директорию - как здесь - всё под '.'
   git add .
   
   # Если порядок наведен, тогда делаем commit:
   # если есть alias из моих "команд", тогда:
   gitcommit
   # либо на "голом" git:
   git commit -a
   
   # тестируем, проверяем, что наваяли, и если все OK, тогда...
   
   # закидываем изменения либо нашей ветки "новой" с созданием оной там, что нежелательно, как правило:
   git push origin new_branch:new_branch
   
   # либо в master, не переключаясь с нашей new_branch, что нежелательно
   git push origin new_branch:master
   
   # А лучше сделать так:
   # переключаемся обратно на master
   git checkout master
   # На всякий случаем тащим что-то новенькое - вдруг кто-то закинул новое, пока мы работали над new_branch
   git pull
   # Теперь объединяем изменения в new_branch с master, могут быть конфликты, если при последнем pull мы что-то получили новое
   git merge new_branch
   # если конфликты - смотрим git diff, правим file, помечаем как resolved (git add file), делаем git commit -a и т.п..
   # Заливаем в репозитарий master уже с нашими изменениями
   git push
   

Пока всё. Думаю, этого вполне достаточно, чтобы стартануть для работы с git

P.S. Также можете почитать:

1. Книга «Pro Git» на русском, в переводе (каждый может помогать в переводе через ее git репозитарий )
2. Сравнение Git с SVN от Ruslan Brest

Давайте сначала поймем, зачем он вам нужен.

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

1. В одном репозитарии (условно — одна папка) у вас хранится сразу вся история проекта с разными версиями. Вы можете создавать экспериментальные ветки, в случае успешного кода их затем объединять в стабильные ветки. Можно легко переходить в «прошлое». Например, можно быстро устранить баг в стабилной версии, а затем продолжать работать в экспериментальной альфа-версии.
2. Легко просматривать, что вы изменили вчера и сейчас. Удобно, когда вы приходите утром на работу и хотите вспомнить, на чем же вы остановились.
3. Заодно — git, выходит само собой, удобное средство резервирования и синхронизации. Вы можете разместить репозитарий на сервере, и с него подтягивать дома рабочие файлы, которые делали на работе,  а после правок заливать изменения обратно.
4. В git — каждый клонированный репозитарий - не только рабочая площадка, но также и полноценный репозитарий. Если вы работали на ноутбуке, а сегодня накрылся ваш сервер с репозитарием, то ваша локальная версия на ноуте — опять же, репозитарий со всей «историей».
5. Для git не надо online - вам достаточно «подтянуть» с сервера изменения, если были, и отключить ноутбук от интернета. Затем, работайте хоть в самолете! Делайте коммиты, пишите и просматривайте, что вы изменили. Только лишь, когда вы захотите «сбросить» все изменения в ваш главный репозитарий, только тогда вам нужен инет.

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

Git, по моему опыту, гораздо понятнее программисту, чем тот же SVN, и гораздо логичнее. Я долго не мог принять, что в SVN создание ветви — делается через копирование файла. Какая-то странная логика. Затем, когда я освоил git, мне куда понятнее, что создание ветви — это создание нового узла дерева со своим parent или даже несколькими parent-ами. Обычнная иерархия, которая понятна не только программисту! Благодаря этому, очень легко прерывать проект и делать ответвления новый подверсий, работать с ними и затем, например, объединять с другими ветками. Git — это как бы мощный diff с элементами иерархии (diff хорошоф знаком тем, кто работает с Unix).

Что нужно четко понимать в git?

Отличительная идеология git от многих других программ контроля версий — наличие index. Index — это «промежуточный слой» между вашим рабочим файловым деревом, и того, что должно быть добавлено в репозитарий. В репозитарий добавляется только то, что есть в индексе. А в индекс вы добавляете из рабочего дерева то, что необходимо добавить затем в репозитарий. Запутано, скажете вы? Когда вы начнете работать, вы поймете, что это очень даже логично! Именно эта «фишка» git поначалу у меня вызывала непонимание.

Ветвление — одна из замечательных свойств git-а. Ветвить можно не просто разные версии программ, а даже по «мелочи». Например, вы хотите добавить новую фичу в программу. Если вы начнете работать на текущей стабильной версии, вы рискуете создать ситуацию, когда в рабочей версии будет найден баг, вам надо будет быстро его исправить, а вы не закончили и не отладили проект с вашей новой фичей. Тем самым, попадете в затруднительную ситуацию. Выход из нее простой — создали подветку, делаете свою новую фичу. Если необходимо, вы можете быстро переключаться между ветками. Ветвление в git — не ресурсоемкий процесс. Им удобно пользоваться и даже нужно. Иначе использование git превратится в стрельбу из пушки по воробьям.

Также, сразу постарайтесь приучить себя к такому способу ведения проекта в git, как активное использование масок для игнорирования файлов. То есть, вы ведете проект, но в нем есть два типа файлов и директорий — условно назовем служебные и проектные. Служебные  — те, что создаются в процессе работы и нужны только для компиляции. Проектные — те, что должны отслеживаться git-ом, лежать в репозитарии, и являться частью проекта в целом. Служебные должны исключаться через файл .gitignore (man gitignore). Приучите себя сразу формировать этот файл, от рождения проекта, и постепенно, по мере работы, добавлять в него новые и новые файлы и маски. Этот файл также упростит вам жизнь с командами add & status.

Также, при групповой работе надо знать, что git — не локирует файлы на время редактирования кем либо. Один и тот же файл могут править несколько программистов. Принцип тут такой — если изменения происходили в «далеких» местах друг от друга в файле, git их объединит автоматом, если же нет — будет создан конфликт, требующий ручного исправления кем либо.

Еще несколько понятий и терминов.

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

Diff - текстовые отличия в формате diff между ветками, commit-ами, файлами и т.п.. Формат его легко читаем и даже сразу понятен, если посмотреть на него — вы видите, что добавляли или удаляли и когда.

Merge - объединение веток. Благодаря иерархии (что из чего следовало) и инструментам нахождения отличий (diff), git сам определяет, что было добавлено в код, что удалено, и на основе этих изменений он делает новые файлы в объединении. Но иногда может случиться так, что один и тот же файл в близких местах менялся в разных ветках. Вот тогда возникает конфликт (см. ниже)

Conflict - конфликт. Если вы делали merge, и при этом возникли противоречия, git создает «конфликт». Эта ситуация, когда файл с конфликтом помечается внутри базы git особым образом, в самом текстовом коде возникают текстовые метки типа ‘<<<<’ или ‘>>>>>>’ с кодами из обоих веток и от вас требуется ручное редактирование файла — устранение конфликта. Вам надо посмотреть эти метки в самом коде, решить, что правильнее, отредактировать, а потом дать понять git-у, что файл вы привели в норму (git add …). С бинарными файлами несколько иначе, но смысл тот же.

Repository - репозитарий, то есть хранилище. Как уже говорил, любая копия может юыть репозитарием одновременно для кого либо. Вы можете сами для себя определить, где будет главная копия. Закачку и выкачку лучше всего осуществлять через ssh протокол. Делается просто — там где лежит репозитарий, он должен лежать под правами, скажем пользователя user. Тогда, чтобы вытянуть от туда, вам надо знать либо пароль user, либо иметь ssh ключ. А сама выкачка делается также просто, без всяких ssh команд: «git clone user@therehost.com:git/myproject.git», например. А дальше, git запомнит адрес репозитария, и обмен данными превратится в две простые команды: «git push» и «git pull». Если еще правильно организовать доступ по ssh ключам, то можно вообще не вводить пароли
Также, маленький нюанс — репозитарий может быть двух типов: bare и обычный. Обычный — это файловое дерево проекта + .git служебная директория, где все и хранится git-овское. А bare — это только файлы .git — там нет рабочей директории, и bare используется только для репозитариев с целью сохранения и взятия информации их них. Обычно, bare репозитариям дают суффикс ‘.git’. В остальном — работа синхронизации идентична.

Если вы поставили git на Unix, то все по нему можно узнать из man-ов: «man git», или, например: «man git-diff» и т.п.. Все в нем делается через одну команду — git, а вторым параметром указывается сама команда. А сам «мен» по ней состоит из git и через дефис той команды, что вам нужна (список всех команд — man git).

Также, есть Windows версия, причем, в том числе с графической поддержкой, показывающей иерархии и изменения от одного commit-а к другому. Находится она здесь: mSysGit — там выбираете, например, msysGit-fullinstall-* самый свежий и ставите. Установка проста, как и все программы для Windows. Ленивые могут использовать только графическую оболочку, а продвинутым, пожалуй, будет интересен «Git Bash» из того же комплекта. Лично я предпочитаю работать в «Git Bash», так как там привычная мощная оболочка bash со всеми ее плюсами (включая, кстати ssh-* команды).

Заключение

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

Я, как программист-одиночка, сейчас уже сложно представляю себе работу без git. Даже если проект поддерживается одним человеком, git сильно облегчает жизнь. И это не смотря на то, что все качества git-а раскрываются в групповой работе над проектом. Самым лучшим примером будет то, что ядро Linux поддерживается только через этот инструмент контроля версий. А ядро — самая динамично-развивающаяся часть кода в мире Linux — над ней работают сотни людей. А требования к ее надежности — самые высокие!

SVN-документация одним файлом HTML для чтения (рекомендую)
Обобщенный список разных форматов этой книги

P.S. Если хотите знать, чем различаются и что чем лучше — Git или SVN — читайте здесь и здесь (анг)

Итак, пишем пост, там, где хотим сократить свой пост для главной страницы, ставим курсор в желаемом месте разбивки, нажимаем кнопку и вуаля! На этом месте появится ссылка «Читать далее» для вашей текущей темы WordPress.

P.S. Этот пост получился очень коротким, так что такой ссылки в нем я решил не ставить

Пришлось написать свой плагин, только для GreaseMonkey. Он довольно корректно заменяет обычные кавычки на угловые прямо в посте (надо только нажать на иконку ). Когда пост вы публикуете, уже нет авто-замены кавычек «темой» или WordPress-ом (не знаю точно, где это срабатывает). Тем самым, вы получаете более красивый пост, и с правильными угловыми кавычками

Еще, что делает этот плагинчик — он заменяет три точки на один Unicode символ ‘…’ (не знаю почему, но почему то многие автозаменялки делают именно это — мне и три точки нравятся ), и два или три тире он заменяет на длинное Unicode тире.

Для установки идем по ссылке, там нажимаем кнопку «Install». Перед этим у вас должен стоять GreaseMonkey (я его рекомендую поставить всем — ресурсов много не ест, зато много чего можно в него поставить )

Для простых задач, например, для таких, когда настройки к какой либо программе надо указать с помощью XML конфиг файла, подойдет редактор XML Notepad, который сделан ненавистной многими фирмой Micro$oft.

Лично я, пришел к выводу, что все редакторы XML либо слишком навороченные и платные, либо ненавороченные и не такие удобные, как XML Notepad. Не могу понять, почему такой популярный формат имеет такую низкую поддержку на уровне редактора… Наверное, может быть потому, что XML часто генерируется программами и ими же парсится, а редактировать ручками не так восстребованно. Но иногда очень надо, а пользоваться обычным текстовым редактором — глупо (постоянно следить за ескейпингом символов)

Из плюсов нашего героя можно перечислить: простота, и понятность.

Минусы: в нем можно настроить либо \r\n, либо \n символы концовки строки, миксовать он не умеет. Можно отключить Indent (имеет имя Auto Format в настройках, не мог сразу догадаться, что это именно Indent). Как то странно, IMHO. Еще один неприятный момент, но он лежит в нормальных рамках Unicode & UTF-8 — он вставляет всегда символ BOM вначале документа. Символ этот нужен для Unicode, для UTF-8 он бесполезен. Скорее всего, это издержки того, что внутри Windows такой документ храниться в Unicode, а для него BOM часто необходим (он указывает процессору Unicode в каком порядке идут старшие и младшие байты 16 разрядной кодировки). Но, многие программы спокойно работают с BOM, так как он аннулируется UTF-8.

Но плюсы перевешивают минусы. Если привыкнуть к этому редактору, то редактировать небольшие XML с ним очень просто.

Краткое пояснение: редактор представляет собой, в общем плане, два окна — левое и правое. В левом — идут названия элементов, аттрибутов и псевдо-нод (например, #text — текстовый child, #comment — комментарий и т.п..). В правом — значения этих элементов, напротив тех, что слева. Если вам надо отредактировать готовый XML, например, какие либо настройки, и не менять структуру XML, то редактирование сводится к изменению только значений в правом окне (перемещаемся курсом вверх-вниз, нажимая Enter — редактируем, Shift-Enter - вставка новой строки в значении). Это очень удобно! А чтобы в правом окне были все значения, как на ладоне, достаточно сделать из меню View -> Expand All, или Alt+V -> Enter или Alt + V -> E. После этого можно приступать к их редактированию.

Для удобства идеалогии редактирования, все строится на понятиях node и sibling (брат/сестра в переводе). Например, даже аттрибут елемента — это тоже node, у него есть parent — елемент, чьим аттрибутом он является. Из этого вытекает простое правило — для всех них существует две команды, через меню — вставка Before и After. Before — это вставить новый sibling перед текущим, выражаясь в понятиях DOM,  After — вставить после. Есть также третья команда — Child — вставить в текущую node.