Неверные ответы вам дают и вы тоже неверно мыслите.
Гит как раз и создан был для сохранения состояния, то есть каждый коммит - это снапшот кода. Некий аналог ctrl+s, если хотите. Коммиты не должны быть привязаны ни к задачам, ни к фичам, ни к багам, ни к чему остальному. Можно хоть каждые 5 секунд коммитить по букве, и ладно. Для управления фичами/багами/etc. есть ветки (не даром они очень легкие). Одна фича - одна ветка. Внутри ветки хоть 500 коммитов, но как только работа завершена - делается pull request и фича мерджится.
На историю коммитов никто не смотрит, смотрите на дерево коммитов.
Что значит доверять? Вы не знаете что происходит на серверах телеграма, а значит уже доверить информацию о месте следующего теракта в метро - нельзя. А если теракт не планируете, то доверять можно всему чему хош.
Ну а так, очевидно, чтобы избежать слива сообщений еще и с клиента, то нужно смотреть их исходный код и компилить самому.
Снова вы :)
Запомните - единица, с которой работает git - это коммит. Любое изменение в репозитории либо закомиченно, либо висит в активных изменениях. Поэтому git не мог удалить у вас файл, не сделав коммит :) Поищите по истории в каком из коммитов (в том числе и merge-коммитах) он мог удалиться.
А вообще вы явно что-то путаете, потому что checkout приводит вашу рабочую папку в состояние этой ветки, поэтому как вы могли понять что файл удалился из ветки test1, когда находитесь в ветке development - непонятно. После git co dev && git merge test1 сделайте git co test1 и скажите что происходит.
Да, и merge не удаляет изменения, а просто применяет все коммиты из одной ветки в другую.
$('.delShelving').on('click', function() {
// меняем на
$(document).on('click', '.delShelving', function() {
и пробуем. Должно теперь заработать.
А дальше идём в гугл, оттуда попадаем на сайт jQuery на странику метода .on() и читаем что такое Direct and delegated events и как они баблятся (bubble) наверх по DOM дереву.
Вы неверно мыслите. Git - не система иерархий, а система контроля версий. Не важно что где лежит, а важно как с этим работают.
Если это три независимых сайта - делайте 3 репозитория. Если у них есть что-то общее (используют одни стили, например), то общие изменения делайте в master (origin-ом обычно называют основной репозиторий для синхронизации, а не ветку) и потом вливайте этот master во все три ветки для каждой части сайта, а изменения которые НИКОГДА НЕ БУДУТ ПЕРЕНЕСЕНЫ в другие ветки - в ветке для соответствующей части сайта.
Спросите себя - зачем? Кому надо, тот код всё равно посмотрит. И так ли нужны ваши скрипты и картинки кому-нибудь?
А по вашему вопросу - идите в гугл, там по любому релевантному запросу куча вопросов на StackOverflow.
Собственно, для этой задачи есть gitignore.
В корне репозитория создаете файл .gitignore, в него просто записываете путь к файлу, который нужно игнорировать (относительно корня репозитория).
Далее нужно исключить его из кеша, т.к. гит не уберет его из трекинга, если он уже там был. Команда: git rm --cached имяфайла
Не совсем верный подход к решению. У разработчиков будет анальная боль постоянно из-за таких хитрожопных дел. Почему-бы вам не сделать наложение конфигов. Типа сначала грузится дефолтный, например persistence.xml, а потом, если имеется на диске файл с таким именем, то поверх стандартного подгружается и он, например, persistence.user.xml
Родитель признал бессилие перед ребенком и обманным путем хочет выйграть эту битву. Ну что за дела. Вы наверное и в магазине запрещаете ребенку хватать все шоколадки подряд под предлогами "зубы выпадут"?
Преждевременная оптимизация - зло.
При разработке системы следует уделить внимание её архитектуре, а не замене одних методов на других. Ну и, конечно, оптимизировать надо там, где надо. А то понапишут кривых запросов к БД, зато вложенные циклы на PHP соптимизированы.