Дмитрий

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

Каждый начинающий git'er должен знать про команду git reflog, т.к. если что-то поломал, то reflog всегда спасет! :)

Если вы форкаете проект на GitHub, то и описание стоит поискать там же...
https://help.github.com/articles/fork-a-repo/
все давно расписано по шагам.
Ну или вот, частично переведено на русский:
https://git-scm.com/book/ru/v2/GitHub-%D0%92%D0%BD...

Кратко про GitHub:
1. Делаете fork и клонируете форкнутый репозиторий к себе на комп.
2. Чтобы обновить свой форк нужно локально сделать fetch с оригинального репозитория, а потом сделать push в свой форк.
3. Чтобы обновить оригинальный репозиторий, делаете локально новую ветку, в которую комитите все изменения. Пушите ее в свой форк, а затем на сайте создаете Pull Request. Хозяин оригинального репозитория должен принять ваши изменения.

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

Godot - реальный конкурент Unity.
Бесплатный. Поддерживает 2D и 3D. Скрипты можно писать на разных языках, в том числе C#. Язык по умолчанию GDScript - похож на Python.
Собственное IDE доступно для всех платформ.
Очень хорошо организован внутри.

Если кто хочет попробовать 2D в действии, вот моя головоломка: (начиная с версии 3.0 использован Godot). Можно скачать через Google Play.

В вашем вопросе есть два постулата:

мне кажется работа на windows+open server ограничивает меня как программиста.

На винде у меня стоят нужные графические программы, которых нет на ubuntu, это сдерживает.

Мне кажется что первое гораздо важнее второго, т.к. первое связано с профессиональной деятельностью, а второе - просто удобные программы (которые в linux, кстати, могут быть, но называться по-другому)
В связи с этим предлагаю вам перейти на linux, а винду поставить под VirtualBox.
Уверен, что скоро вы поймете что очень нужные вам программы не очень-то и нужны (как это понял и я)...

Если содержательность сообщений вас не устраивает, то вы можете всегда сделать git rebase -i и их переименовать, или даже слить что-то вместе. Естественно это нужно делать до git push

Сначала находите коммит, в котором файлы еще есть (в вашем случае можно использовать, upstream/master). Затем:
1. Визуализируете список измененных файлов (grep'ом фильтруем только удаленные)
2. Восстанавливаете нужные файлы из коммита
Далее делаете новый коммит, пушите в репозитарий и т.п.

git diff --name-status upstream/master | grep ^D
git checkout upstream/master <path/to/the/deleted/file>

Черипики - это, конечно, удобно, но может привести к неприятным последствиям. Это во-первых дублирование коммитов, а во-вторых, если забыть что-то черипикнуть, то ваш клиент перестанет работать и вы будете долго разбираться что к чему.

Решения два:
1. Если ваша ветка client - просто усовершенствование ветки master, то можно сделать rebase и переместить client на верх master'а. Это меняет историю, поэтому подходит не всем, но если вы работаете с репозиторием в одиночку, то вполне нормальное решение (история будет красивой).
2. Так вам и не нужно мержить client в master, а как-раз наоборот смержите master в client и будет именно то, что вам необходимо.

Хм... я бы попробовал так:
Назовем последний имеющийся коммит (0), а текущую ветку (а).
Поскольку сделана stash apply, то в стеше этот элемент сохранился (если pop, то нужно поколдовать с git reflog).
1. Сделаем коммит (1а).
2. Вернемся к коммиту 0 и создадим ветку "б"
3. Выполним git stash apply в ветку "б"
4. Сделаем коммит (1б)
5. Сделаем git revert предыдущего коммита (2б)
6. Перейдем в ветку "а" и сделаем git cherry-pick 2б (получим коммит 2а)
7. Если все нормально, то объединяем коммиты 1а и 2а (git rebase -i)
Все.
На словах довольно просто, но в реальности это может усложниться конфликтами, но они решаемы.

На мой взгляд, делать постоянно amend, как предлагает выше Борис, идеологически не верно. Главное предназначение git - возможность сделать быстрый откат или найти коммит на котором что-то сломалось.
Лучше делать много мелких коммитов, а после тестирования объединить их в один с помощью
git rebase -i

Вообще, делать пробы лучше в отдельной ветке - так гораздо меньше головняков...
Если пробы все-таки хочется сохранить (хотя бы временно), то можно сделать так:
Итак у вас есть коммит аааааа (последний - о котором вы пишите) и есть коммит сссссс. Пробные коммиты находятся как-раз между аааааа и сссссс. Ветка master, по вашему описанию, находится на самом верху, т.е. на аааааа.
1. Создаем тестовую ветку: git branch Tests (теперь на аааааа две ветки)
2. Переносим master на последний полезный коммит: git reset --hard cccccc
3. Копируем нужный коммит: git cherry-pick аааааа
4. Отправляем master: git push -f
Посмотреть ситуацию наглядно можно так: git log --oneline --decorate --all --graph
Все. Пробные коммиты остались в отдельной ветке. Ее можно удалить. А если они все-таки нужные и там предполагается продолжит работу, то нужно сделать rebase:
5. git checkout Tests
6. git rebase master
Тестовая ветка передвинется на топ master'а а коммит aaaaaa пропадет, т.к. он уже есть внизу.

ЗЫ: Чтобы не писать длинно git log (это очень частая команда), советую сделать alias.

Angular открывает прямую дорогу к ionic, а это мобильные приложения почти для всех платформ.

Обычная связь многие-ко-многим, просто и первая и вторая таблица - это одна и та же таблица Фильмы.

Родилась собственная идея: а может использовать механизм комментариев для построения дерева секций у конференции?