Локальный гит
В продолжение темы про сохранение и бэкапы.
Грамотная работа с документами или кодом — залог спокойной и успешной работы. Даже если вы регулярно сохраняетесь в процессе работы и делаете бэкапы, то у вас может возникнуть другаие серьёзные проблемы.
Начнём с документов. Представим, что вы очень долго работали над документом в Ворде: набрали текст, всё аккуратно отформатировали, вставили сноски, сделали разные таблички, расположили красивенько иллюстрации с подписями. И вот, при очередном сохранении вашего прекрасного и достаточно объёмного и сложного файла, Ворд говорит, что он не смог осилить данную операцию и будет закрыт. Конечно же, он отправит письмо разработчикам из Майкрософта, которые потом будут проливать горячие слёзы над вашей бедой — ведь предыдущая ваша забэкапленная копия датировпна вчерашним днём. Или если вы работали в облаке, то файл в облако сегодня так и не смог загрузиться из-за плохого интернета и очень частого сохранения. Или ещё какая-либо объективная причина была у того, что самая сложная часть работы не успела попасть в последний бэкап.
При важной работе со сложным и тяжёлыми файлами в Ворде или Фотошопе, я использовал следующий подход. И так как подобные задачи возникали нечасто, я обходился вручную: периодически делал копию файла в той же папке, что и оригинал. Сделать это легко — просто перетащить файл и бросить его рядом, с зажатым при этом контролом. Если делать это в облаке, то в итоге все эти копии попадут ещё и в облако.
Таким образом, я брал процесс контроля за резервным копированием промежуточных состояний файла в свои руки. Теперь сохранность логически законченных частей работы была моей заботой, а не стохастическим процессом. Например, я делал сложную табличку и периодически сохранялся. Как только доделал — создал копию файла и продолжил работать дальше. Тогда если текущий файл испортится при очередном сохранении, я смогу взять его копию, сделанную при завершении предыдущего этапа работы. Заодно, если я работаю в папке облачного хранилища, эти копии смогут без проблем загрузиться друг за другом — им не будет мешать постоянное пересохранение.
Другая ситуация, когда мы работаем не с одним файлом, а с кодом. Предположилм, что мы это делаем в одиночку и на одном компьютере. При написании кода невозможно постоянно делать копии файлов — это совершенно бессмысленное занятие — каша из кучи копий множества файлов никакую проблему нам не решит. Отсюда возникает вопрос согласованности изменений. Получается, что логически законченная часть работы у нас распределяется по нескольким файлам. И сделанные изменения нам нужны только все сразу и именно в этом состоянии.
Очевидно, в таких ситуациях нам поможет система контроля версий. Раньше можно было установить локальный SVN и коммитить завершённые части работы в него. Сейчас у нас есть более удобный Git. Для его использования не нужно ставить отдельный сервер, заходить в оснастку сервера для создания репозиториев и пр. А если вам надо перенести проект с одного компьютера на другой, то нет нужды переносить репозитории и подключать их на другом компьютере — можно просто перенести папку с кодом, ведь репозиторий гита находится непосредственно в ней.
Таким же образом можно работать и с современными офисными форматами документов. Вместо описанного выше способа ручного копирования документа можно просто коммитить файл в репозиторий.
Так как репозиторий локальный и нет других членов команды, можно работать не по столь строгим правилам, как в командной разработке. Но очень рекомендую всё же соблюдать аккуратность: писать комментарии к коммитам, разделять изменения на логические части, коммитить только завершённые этапы работы.
Напомню, репозиторий и всякие копии файлов вам нужны не потому что про них кто-то написал в интернете или потому что всё так делают. Вся эта морока — забота о вас самих. Когда вы столкнётесь со сложной проблемой необходимости откатить часть изменений назад, вы поймёте важность этих накладных расходов. К тому же, когда процесс работы более продуман и структурирован, то работа идёт проще, результат получается более качественным.
Пример другой проблемы, с которой вы можете столкнуться при работе с кодом: вы занялись сложной переделкой какой-то части проекта. Она потянула за собой вмешательство в другие части системы. В какой-то момент у вас всё сломалось. Что делать в таком случае? Сидеть и копаться в отладчике? Искать где вы чего в коде поменяли? На всё это могут уйти часы. А если вы всё аккуратно и логично заливаете в репозиторий, то вы можете увидеть каждую изменённую строчку, и тогда гораздо легче найти ошибку.
У меня частенько возникали задачи, когда есть большой проект, например на PHP. Код имеется только на продакшене на хостинге. Стоит задача поправить какую-то мелочь. Есть такая примета: отсутствие кода проекта в системе контроля версий — к многочасовой отладке. Соответсвенно, лучше потратить 15 минут на создание репозитория с кодом и получить супер-силу — видеть каждое отдельное изменение в коде.
А самое главное преимущество системы контроля версий в данной ситуации — список изменённых файлов, которые потом нужно выложить на тестовый сервер или продакшн.
Ещё часто бывает так, что вы для отладки кода меняете что-то в конфиге проекта или вставляете код для дампа значений переменных — классический var_dump(). Чтобы убедиться, что эти отладочные изменения не попадут на боевой сервер, нужно посмотреть каждую изменённую строчку после того, как вы закончили работу над кодом. Сделать это проще простого.
При работе не забывайте фиксировать промежуточные результаты. И главное помните — методика работы должна максимально способствовать простоте восстановления и порядку вцелом, а не просто быть бесполезной нагрузкой.