Алексей Киселев

Почитайте про набирающую популярность модель ветвления Trunk Based Development.
При использовании этой модели вам потребуется ветка master (trunk) и ветки для релизных версий. В master вы ведете разработку (в вашей терминологии это development) для каждой версии выходящей к пользователям вы создаете отдельную ветку, например 1.0.x.
Самое главное: все изменения вносятся разработчиками только в ветку master. Только ответственные люди могут создавать релизные ветки и переносить изменения из master в них, в том числе и при внесении изменений в выпущенные версии. Релизы
собираются только с релизных веток.

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

Процесс выглядит так:
1. Разработчик делает pull master.
2. Если нужно создает локальную ветку и работает в ней.
3. Прогонят тесты на ветке и мержит ее с master.
4. Делает push.
5. CI видит новый коммит, получает его и выполняет на нем модульные, интеграционные и приемочные тесты.

Я не очень понимаю, для чего могут потребоваться автоматические коммиты, мое мнение - этот процесс должны контролировать люди. А задачи в issue-tracker должны закрывать тестеры или разработчики, если они написали соответствующие тесты.

В том, что на CI не пройдут тесты нет ничего страшного. Он вообщем-то для этого и нужен. Откатывать коммит не нужно, нужно быстрее делать новый, в котором ошибка исправлена.

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

Разметка задачи тегами с последующей фильтрацией будет эффективней. Asana умеет навешивать теги на задачи.

Это называется merge bubbles. Git создает merge-коммит во время каждой операции pull. Во время слияния 2-х веток Git может сделать или merge с созданием merge-коммита или rebase без создания новых коммитов. Кто-то настроил его так, что он всегда создает merge-коммиты.

За данное поведение Git отвечает настройка branch.autosetuprebase.
Данная настройка может иметь 4 значения:
* never - Git никогда не выполняет rebase
* local - Git выполняет rebase только для локальных веток
* remote - Git выполняет rebase только для удаленных веток
* always - Git всегда выполняет rebase.

Для удобства выставите ее в always глобально.

git config --global branch.autosetuprebase always

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

Возможно вам больше подойдет стратегия ours.

git pull -s ours

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

mysvn.ru
только там Git нет.
А локализация есть в TortoiseSVN или TortoiseGit.

Roboform?

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

Создайте в разделяемой папке bare репозиторий Git:

mkdir repo
cd repo
git init --bare

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

git remote add origin [путь к папке разделяемого репозитория]
git push origin master #отправляем ветку master в удаленный репозиторий по ссылке origin

Теперь клонируем разделяемый репозиторий в Windows.

git clone [путь к разделяемому репозиторию]

и работаем в копии. Изменения отправляем и получаем командами push и pull.

Это проблема библиотеки libgit2. Судя по исходникам поддержка ssh была добавлена 12.12.2013, совсем недавно.
У вас возможно используется одна из предыдущих релизных версий. Какая-то поддержка ssh появилась начиная с версии 0.20.0.

Ветки пока не нужны, достаточно master.
Если ваша активная разработка связана с внесением новых функций, необходимых заказчику, делайте все в ветке master. Я предлагаю вам сделать тег на той версии, которая работает у заказчика на боевом сервере. После этого продолжайте разработку в master и таким образом получите development версию продукта. Которую вы будете ставить на development сервер.

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

И помните Git - это не deployment tool. То как вы описываете свою проблему, наводит на мысль, что вы просто делаете pull одной из веток на серверах. Хорошо если я ошибаюсь, так как делать этого не нужно, плохо с точки зрения безопасности.

Для управления артефактами хочу порекомендовать Ivy. Артефакты могут быть абсолютно любыми от сборок .Net или jar-файлов до кусков инсталляторов или дистрибутивов. Если с ней разобраться, то можно очень хитрые сценарии организовать.

Для автоматизации сборки на каждой платформе свое средство. Из более-менее универсальных можно назвать Ant и Gradle. Ant мы собирали Java, .Net, можно собирать C, C++. С помощью Gradle можно собирать Java, C, C++. Я на него посматриваю, но в бою использовать не приходилось, сказывается хорошее знание Ant.

Для документации удобно использовать Markdown/Pandoc. Есть проект ikiwiki с markdown в качестве языка страниц.

1000 одновременных соединений это и для питона не проблема. Лучше понять сколько сообщений и какого объема будет проходить в единицу времени.
Я бы на вашем месте выбрал Java, хотя бы исходя из того, что протокол можно реализовать в виде библиотеки и использовать на Android, а не реализовывать заново.
Во-вторых, я бы выбрал Java из-за развитой экосистемы этой платформы и огромного количества открытых библиотек и инструментов.

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

Чем непосредственно тестировать мне сказать сложно, вот народ пользует с cucumber какой-то Webrat.

Для начала посмотри что тебе интересней: работа в команде или в одиночку. От этого будет зависеть размер проектов. На уровне железа (программирование микроконтроллеров и т.п.) очень много проектов, которыми занимается один человек, начинаешь подниматься выше и размер команды начинает расти. Программирование - это всегда про общение с другими людьми, про создание общего, понятного всем образа разрабатываемой системы. Если нравится общаться с людьми, далекими от IT, иди во front-end. Если хочешь общаться с админами разных мастей, иди в back-end. По мне front-end или desktop скучнее серверного back-end, так как в них очень много однообразия из-за работы с пользователем. Но это мое субъективное мнение, тебе нужно самому попробовать и составить свое собственное мнение.

Ответы на твои вопросы:
1. Развивать лобные доли мозга, они отвечают за целеполагание и достижение целей. Медитация говорят очень помогает в этом.
2. Принять простой принцип: сомневаться и размышлять до того как начал действовать, начав действовать не сомневаться.
3. Больше общаться с другими людьми, рассказывать им про свои "грабли".
4. Больше пробовать! Участвуй в открытых проектах, например. Можно кучу всего перепробовать.

Универсальным решением будет использование сервера непрерывной интегации (Continuous Integration), например Jenkins.
Сделайте на нем 2 задания, одно для ветки master, второе для вертки test. В этих заданиях в ответ на появление коммитов в ветке сделайте публикацию на сайт по SSH, FTP или простым копированием.
Преимуществом подхода является то, что вся информация о deployment сосредоточена в одном месте - заданиях Jenkins, для разных проектов можно по разному организовать выкладку файлов на сервер, но принципиально задания будут одинаковыми.
Если пойти дальше, то в этих же заданиям можно запускать автоматическое тестирование.

Со стороны выглядит как смена коня на переправе.

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

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