true0r

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

Стандарты - по хорошему надо прочитать и понять всё что издает php-fig в сфере юзерленд кода,
самые важные - PSR 0-4

Вспомогательные (обязательные) технологии - YAML, XML, CSV, JSON;
Библиотеки "все-в-одном" - на бэкенде не водятся (да здравствует linux-way);
Фремворки общего назначения, скелеты приложений - Yii (1,2), Symphony2, ZendFramework2;
CMS-фреймфорки - Drupal, ... Wordpress? ищите под задачу;
Модульность, Зависимости - Composer и все что с ним связано, PEAR/PECL (потихоньку отмирает);
Сборка - Phing (хотя я собираю php-проект gulp'ом - у него API приятнее);
Тестирование - PHPUnit, Behat, CodeCeption;
Деплой(Развертывание релизов) - Mage (aka Magallanes), Deployer
Помощники - Vargant, Docker (тестирование и разработка в готовых окружениях)

Здесь я не упоминал того что нужно знать о самом языке и его компонентах.

теперь поговорим о зоопарке..

технологии и зоопарк специфичный только для PHP:

Сервера приложений - php-fpm, apache-mod-php;
Кэш и быстродействие - APC (APCu для PHP >= 5.5)
дебаг - ZendDebug, XDebug, XHProf

Далее то что не отличается от одного серверного языка к другому.
это часть ответа безгранично велика на самом деле =)

Сервера и прокси - Nginx, Apache, Varnish, etc.
Кэши и NoSQL - Memcached, Redis, Mongo, etc.
СУБД - MySQL, PostreSQL, etc..
Поисковые индексы - ElasticSearch, Sphinx
Очереди и межпроцессовое взаимодействие - RabbitMQ, ZeroMQ, linux-sockets, posix-treads
Протоколы взаимодействия (4 уровень OSI) - HTTP(во всех его подробностях! просто MUST HAVE), POP, SMTP, IMAP, REPL.
Траспортные Протоколы (3 уровнь OSI) - TCP, UDP
Библиотеки уровня системы - cURL (абсолютный MUST HAVE - большинство взаимодействия поверх HTTP строится на этой библиотеке в абсолютном большинстве серверных скриптовых языков)

www.phptherightway.com

Я не смогу посоветовать как реализовать классический MVC, но могу рекомендовать воспользоваться примерами готовых приложений для организации собственной структуры.
Например учебное приложение Microscope https://github.com/DiscoverMeteor/Microscope
, а так же Telescope https://github.com/SachaG/Telescope
+ посмотреть примеры реализации пакетов на atmosphere.meteor.com

У меня лично сложилась такая структура:
1) Все приложение я разделяю на множество пакетов.
Каждый пакет представляет из себя, либо
а) Пакет-библиотека.
Какое-либо функционал, самодостаточный и предназначенный для многократного использования в различных приложениях.
Пример - большая часть пакетов с atmosphere.meteor.com
б) пакет-модуль.
Весь функционал я делю на модулю.
Например: блог, личный кабинет, профиль, админка и тд и тп.
Все они зависимы от одного базового модуля "core" и используют или наследует часть его функционала.
в) основное приложение.
Оно является своеобразным клеем для пакетов.
Подключает необходимые, конфигурирует их и тд.

Если рассматривать приложение с точки зрения mvc, то из моей структуры, необходимо рассказать подробнее о "пакет-модуль".
Такой пакет включает в себя, все что необходимо для его работы: маршруты, коллекции, библиотеки, шаблоны, хелперы и тд.
Пакет сам по себе практически самодостаточен и может лишь тянуть некоторые зависимости из других пакетов.
Таким образом использовать такой пакет можно в разных приложениях без каких либо особых настроек и тд.

Базовая структура пакета-модуля:
module
|
- router (Controller)
|- contollers
|_ subscribers
|- filters
|- hooks

_ libs (Model)
|-collections
|-methods
|- helpers
|-libs
|- publications

_ views
|- templates
|-helpers
|-events
|- etc

При необходимости, могу рассказать подробнее о любом из слоев.

Один из омонимичных доменов:

.am — национальный домен Республики Армения, созвучен с диапазоном радиостанций AM или как зона AMerica.
.cd — национальный домен Демократической республики Конго (иначе — Заира), совпадает с сокращением для компакт-диска.
.dj — национальный домен Джибути, совпадает с сокращением «диджей».
.fm — национальный домен Федеративных Штатов Микронезии, созвучен с диапазоном радиостанций FM. Пример: last.fm.
.im — национальный домен Острова Мэн. Совпадает с сокращением Instant Messaging («мгновенные сообщения»).
.io — национальный домен Британских территорий в Индийском океане. Совпадает с сокращением Input Output («ввод/вывод»).
.is — национальный домен Исландии. Совпадает со словом is, формой третьего лица единственного числа английского глагола to be. Пример: who.is
.it — национальный домен Италии. Совпадает с сокращением IT (информационные технологии), а также с английским местоимением it («это»). Пример: ok.undo.it
.md — национальный домен Молдавии. Совпадает с сокращением аудионосителя MiniDisc и с сокращением Must Die. Также совпадает с сокращением от англ. medical doctor, используемым повсеместно в англоязычных странах. Например, известный американский сериал «Доктор Хаус» в оригинале называется House, MD.
.me — национальный домен Черногории. Совпадает с местоимением «меня», «мне» в английском и других европейских языках.
.net — общий домен верхнего уровня, совпадает с русским словом «нет», из-за чего обрёл в России (и не только) дополнительную популярность. Часто используется с доменными именами в виде транслитерированных русских слов. Примеры: mozga.net, lishnih.net.
.nu — национальный домен острова Ниуэ, созвучно со словом ню.
.tm — национальный домен Туркменистана, совпадает с аббревиатурой «™» (англ. trade mark — торговая марка).
.tv — национальный домен Тувалу, совпадает с аббревиатурой «Телевидение».
.ws — национальный домен Западного Самоа, совпадает с аббревиатурой Web Site.
.in — национальный домен Индии, с английского языка переводится как предлог «в».
.li — национальный домен Лихтенштейна. Совпадает с окончанием глаголов и имён существительных в русском языке. Используется с доменными именами в виде транслитерированных русских слов. Примеры: zadolba.li, zastuka.li, vaf.li, gus.li, yas.li.
.pro - общий домен верхнего уровня для профессионалов в своей области.

В зависимости от того что для чего вам программирование
Для создания сайтов html, css, js, php, ajax и тд...
Для мобильный приложений java, Objective-C и тд...
Для компьютерных программ C, C++, Delphi и тд...

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

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

Оптимальным, на мой взгляд, является написание комментария как краткого описания изменений с позиции собственного видения смысла вносимых изменений, руководствуясь при этом фактически произведёнными изменениями (т.е. не «улетать» слишком высоко в абстракции при описании изменений) и исходить из того, что комментарии предназначены для разработчиков. Если исправляется орфографическая ошибка, то в комментарии следует указать, что «исправлена орфографическая ошибка», если изменены несколько участков кода ради общей логики, то следует описать что именно за логика подразумевается (т.е. дать именно описание общей, абстрактной логики, а не перечислять изменённые методы, классы и т.п.).

В случае Вашего примера, думаю, следовало написать что-то вроде «Убран лишний вызов функции getCharset в CurlResult::fetch» (чтобы были ясны Ваши намерения; Вы же убрали вызов так как он лишний (о чём потом даже написали в своём посте — «просто лишний раз дергал метод»), а не ради исправления какой-то ошибки).

Что касается использования в комментарии названий сущностей из программного кода (имён методов, классов, пространств имён и т.п.), которые были изменены, то, на мой взгляд, следует пытаться находить баланс между желанием конкретизировать область изменений и размером комментария (т.е. я за присутствие в комментарии указания на область изменений, просто конкретизация будет варьироваться от названия конкретных сущностей из программного кода до обобщённых названий). Так, например, вместо комментария «добавлена поддержка рекурсивного удаления файлов» я бы предпочёл комментарий «добавлена поддержка рекурсивного удаления файлов в функции removeDirectory»), а вместо комментария «добавлена поддержка событий в классах Plugin1, Plugin2, Plugin3» предпочёл бы «добавлена поддержка событий в плагинах».

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

Поставьте плагин Webmaster (в списке плагинов поиском), там есть такая штука.
При установке гита под винду, ему можно задать, как быть с EOL. Выберите второй вариант.