Почему коммит git на файлы, а не файл?
От: velkin Удмуртия http://blogs.rsdn.org/effective/
Дата: 16.03.21 17:34
Оценка: -2
Как известно git немного извращённая система хранения версий файлов, но не директорий, последних попросту нет. Размышлял про синхронизацию файлов и мне в голову пришла мысль, что git то ведь ставит коммит на файлы, а не файл.

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

Логичнее применять принцип CRUD именно к файлу, а не файлам, тогда жизненный цикл каждого файла будет выглядеть как:
---------------
Create
---------------
Read или Update
---------------
Delete
---------------

И я не утверждаю, что git не может показывать как изменялся каждый файл в отдельности, здесь дело именно в изначальном подходе. Почему ориентированность именно на файлы? Значит подразумевается, что все файлы в хранилище это некая единая сущность, хотя на самом деле это может быть не так.

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

Собственно откуда такая мысль. Для проекта могут быть важны теги завершённости программы и всё в таком роде. Но как никто не мешает делать коммиты под изменения каждого файла, так никто не мешает выстроить изменения файлов в единую цепочку и привязывать тег к изменению последнего файла.

Другое дело для синхронизации привязка ко множеству изменений файлов практически ничего не даёт. Выгоднее отслеживать каждый файл в отдельности, это и для контроля повреждений полезнее. А самое главное в системе изменения версий для некоторых это вовсе не комментарий в стиле "ля ля ля", а просто сохранение новых версий файлов.

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

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

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

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

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