Git и другие системы управления версиями

Настройки отображения темы Показывать по сообщений с сортировкой .
Выводить , отправленные .
Страницы:
  • 1
  • 2
Распечатать

К данной теме присоединены сообщения из темы «CSS-фреймворк Tailwind»

MadTechGuy
Единомышленник
Всего сообщений: 430
Зарегистрирован: 29 июн. 2018 г., 09:36
Рейтинг пользователя: 71

0
#2
Julia написал(а):
Более хорошая альтернатива Git в качестве VCS?

Я некоторое время пользовался Git так, как это изначально задумано: каждое изменение в отдельном коммите, с описанием каждого внесённого изменения. Но через какое-то время я этим откровенно замучился — на всё это уходило неоправданно много времени, и в итоге минусы перевесили плюсы. Вполне возможно, что для кого-то преимущества такого сценария использования окажутся весомее, и я не берусь судить, кому какой подход ближе. То, что я напишу ниже — это не более, чем предложение (как и положено: «критикуешь — предлагай»), и ни в коем случае не универсальное правило для всех и на все случаи жизни.

Для себя я пришёл к выводу, что оптимальнее всего придерживаться принципа KISS: выкладывать архивы с релизами и вести changelog, где фиксировать, в какой версии какие изменения были внесены. А уже какая VCS или какой хостинг open source проектов будет использоваться при этом — вопрос второстепенный. Здесь, на мой взгляд, стоит отталкиваться не от моды или «правильности», а от реальной целесообразности.

Julia
Участник
Нет Всего сообщений: 120
Зарегистрирован: 16 апр. 2024 г., 18:46
Рейтинг пользователя: 7

0
. Редактировалось 2 раза, последний — #3
MadTechGuy написал(а):
Для себя я пришёл к выводу, что оптимальнее всего придерживаться принципа KISS: выкладывать архивы с релизами и вести changelog, где фиксировать, в какой версии какие изменения были внесены. А уже какая VCS или какой хостинг open source проектов будет использоваться при этом — вопрос второстепенный. Здесь, на мой взгляд, стоит отталкиваться не от моды или «правильности», а от реальной целесообразности.


Ну если для тебя это хорошо работает, то ок. А так в целом такой подход разбивается обо всё, что сложнее одного скрипта и пишется не на один раз, а поддерживается в несколько итераций. Помимо сложной логики и зависимостей нужно держать еще в голове что где изменено и не потерять это. Я как-то пробовала делать аркадную игру без всяких VCS, чисто на архивах...

Julia
Участник
Нет Всего сообщений: 120
Зарегистрирован: 16 апр. 2024 г., 18:46
Рейтинг пользователя: 7

0
#4

MadTechGuy написал(а):
Я некоторое время пользовался Git так, как это изначально задумано: каждое изменение в отдельном коммите, с описанием каждого внесённого изменения. Но через какое-то время я этим откровенно замучился — на всё это уходило неоправданно много времени, и в итоге минусы перевесили плюсы. Вполне возможно, что для кого-то преимущества такого сценария использования окажутся весомее, и я не берусь судить, кому какой подход ближе. То, что я напишу ниже — это не более, чем предложение (как и положено: «критикуешь — предлагай»), и ни в коем случае не универсальное правило для всех и на все случаи жизни.


Просто ты неправильно пользовался Git-ом и потом рационализировал это постфактум.

4X_Pro
Создатель сайта
Всего сообщений: 4469
Зарегистрирован: 9 дек. 2015 г., 19:20
Рейтинг пользователя: 2413

2
. Редактировалось 4 раза, последний — #5

У меня позиция такая: git — это must have для командной разработки, но разработчик-одиночка с хорошей памятью вполне может обходиться и без него. Хотя наличие git, на мой взгляд, несколько дисциплинирует плюс даёт визуализацию своей деятельности в виде списка дней с commitами на том же GitHub (правда, как выяснилось, там считаются только commitы в основную ветку), что для меня является дополнительным источником мотивации.
Что касается комментариев для коммитов, то тут нужно найти для себя приемлемый уровень детализации, насколько подробно расписывать. Я для себя пришёл к тому, что описание commitа должно быть из одной строчки, чтобы было удобно писать в командной строке через git commit -m (что-то вроде "Blog ratings added" или "Category routes fixed").
Основная сложность, на мой взгляд, бывает с мелкими множественными изменениями (как, например, в том же IntB я уходил от использования app->load_lib('что_то_там') на new Library_что_то_там), которые перемешиваются с крупными доделками. Или настолько мелкими, что их просто не замечаешь (типа исправления опечаток в сообщениях для пользователя). Но тут приходится просто смириться с тем, что часть таких переделок попадает в другие коммиты, да и всё.
Но вообще, бывают ситуации, когда системы контроля версий — это реальное спасение. У меня так с инсталлятором IntB было. Я два дня его писал, оттсестировал, уже почти было собрался релиз собирать. И тут вспомнил, что нужно добавить автоматическое удаление install.php после окончания установки в целях безопасности. Добавляю, прогоняю ещё раз инсталляцию, всё прекрасно отрабатывает, включая удаление. Переключаюсь во вкладку в IDE, и тут появляется сообщение, что этого файла на диске больше нет. Сначала — лёгкий ступор, а потом понимаю, что он только что удалил сам себя, как и было задумано. Только вот это была единственная копия! Тут у меня чуть было не случилась истерика, но потом сообразил восстановить его из local history в Netbeans, которым я тогда пользовался, и всё обошлось.


Ребята, давайте жить спокойно!


Julia
Участник
Нет Всего сообщений: 120
Зарегистрирован: 16 апр. 2024 г., 18:46
Рейтинг пользователя: 7

0
#6
4X_Pro написал(а):
У меня позиция такая: git — это must have для командной разработки, но разработчик-одиночка с хорошей памятью вполне может обходиться и без него.


Может. Зависит от сложности логики, архитектуры, версионирования и частоты обновления проекта. Еще git бывает полезен для интеграции с GitHub/GitLab для статических сайтов.


4X_Pro написал(а):
Основная сложность, на мой взгляд, бывает с мелкими множественными изменениями (как, например, в том же IntB я уходил от использования app->load_lib('что_то_там') на new Library_что_то_там), которые перемешиваются с крупными доделками. Или настолько мелкими, что их просто не замечаешь (типа исправления опечаток в сообщениях для пользователя). Но тут приходится просто смириться с тем, что часть таких переделок попадает в другие коммиты, да и всё.


Пишется общий коммит типа "Fix typos".


MadTechGuy
Единомышленник
Всего сообщений: 430
Зарегистрирован: 29 июн. 2018 г., 09:36
Рейтинг пользователя: 71

2
#7
Julia написал(а):
Ну если для тебя это хорошо работает, то ок. А так в целом такой подход разбивается обо всё, что сложнее одного скрипта и пишется не на один раз, а поддерживается в несколько итераций. Помимо сложной логики и зависимостей нужно держать еще в голове что где изменено и не потерять это. Я как-то пробовала делать аркадную игру без всяких VCS, чисто на архивах...

Ну не знаю… Я пишу огромные проекты, некоторые из которых длятся около года и в которых местами в плане сложности чёрт ногу сломит, и у меня ничего не «разбивается», при этом я не использую никакие VCS и не испытываю в них никакой потребности, скорее возня с ними представляет для меня только дополнительную работу, которая никак не окупается (мелких изменений так много, что в итоге доходило до абсурда, когда на возню с написанием комментариев к коммитам уходило примерно 20-40% времени от написания кода). Я просто периодически делаю резервные копии, и всё. А насчёт «держать в голове что где изменено» — а зачем это постоянно держать в голове? Это нужно держать только в рамках текущей небольшой подзадачи, которую доделал — и всё, и не нужно больше держать ничего в голове. А вот помнить, какие ещё доработки нужно внести — это нужно, но для этого есть TODO-список. Такое впечатление, что у нас то ли мозг работает по-разному, то ли слишком различаются подходы/потребности/use cases/etc, то ли ещё что…
Julia написал(а):
Просто ты неправильно пользовался Git-ом и потом рационализировал это постфактум.

Только, пожалуйста, не надо по умолчанию подразумевать в людях что-то негативное — я видел несчётное количество срачей в онлайне и оффлайне, которые именно с этого начинались, так что не хочу и не буду наступать на эти грабли, на которые сотни раз до меня наступали (да и я сам не раз, когда меня с подобного триггерило)… Если по существу, то я (как и 4X_Pro) уже написал выше: у нас слишком разные сценарии использования, и дело тут явно не в сложности проекта, а в чем-то другом. Скорее всего, в том, что мои разработки, как правило, не коллективные, а исключительно мои личные, где всё пишу я сам, и не очень соответствуют современным модным тенденциям в разработке, а скорее в духе KISS и проектов конца нулевых и начала 2010-х. Лучше напиши, как ты видишь правильное использование Git, и это, думаю, будет действительно полезно для многих, и, возможно, для меня тоже.

Julia
Участник
Нет Всего сообщений: 120
Зарегистрирован: 16 апр. 2024 г., 18:46
Рейтинг пользователя: 7

0
. Редактировалось 6 раз, последний — #8
MadTechGuy написал(а):
Я пишу огромные проекты, некоторые из которых длятся около года и в которых местами в плане сложности чёрт ногу сломит, и у меня ничего не «разбивается», при этом я не использую никакие VCS и не испытываю в них никакой потребности, скорее возня с ними представляет для меня только дополнительную работу, которая никак не окупается (мелких изменений так много, что в итоге доходило до абсурда, когда на возню с написанием комментариев к коммитам уходило примерно 20-40% времени от написания кода).


Что за тип проектов? На каком стеке?


MadTechGuy написал(а):
Скорее всего, в том, что мои разработки, как правило, не коллективные, а исключительно мои личные, где всё пишу я сам, и не очень соответствуют современным модным тенденциям в разработке, а скорее в духе KISS и проектов конца нулевых и начала 2010-х.


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


MadTechGuy написал(а):
при этом я не использую никакие VCS и не испытываю в них никакой потребности, скорее возня с ними представляет для меня только дополнительную работу, которая никак не окупается (мелких изменений так много, что в итоге доходило до абсурда, когда на возню с написанием комментариев к коммитам уходило примерно 20-40% времени от написания кода)


Так коммит описывает верхнеуровневое (доменное) техническое изменение, а не что конкретно в коде изменилось. Если правки относятся к конкретной фиче, то в коммите к фиксу указываешь название фичи. И всё. Если это новая фича, то что-нибудь вроде `Add featureX`. И т.д.


MadTechGuy написал(а):
Только, пожалуйста, не надо по умолчанию подразумевать в людях что-то негативное — я видел несчётное количество срачей в онлайне и оффлайне, которые именно с этого начинались, так что не хочу и не буду наступать на эти грабли, на которые сотни раз до меня наступали (да и я сам не раз, когда меня с подобного триггерило)…


[offtop]
Не подразумеваю. Но и расписывать всё подробно тоже не вижу смысла, потому что люди как правило это не ценят. Человеку либо неинтересен сабж, либо он пытается чуточку поискать в интернете и подумать, прежде чем взять это к применению и/или расписать новый аргумент.
[/offtop]

Julia
Участник
Нет Всего сообщений: 120
Зарегистрирован: 16 апр. 2024 г., 18:46
Рейтинг пользователя: 7

1
. Редактировалось 5 раз, последний — #9

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

MadTechGuy написал(а):
скорее в духе KISS и проектов конца нулевых и начала 2010-х


KISS - это же не про культуру, а про "не множить сущности/методы без реальной необходимости". Git нужен, особенно в командной/коллаборативной работе. Использовать коммиты для описания изменений в целом по смыслу - это по KISS. Использовать коммиты просто для каждого изменения в коде - нарушает KISS. Не использовать VCS для работы над коллаборативным проектом - нарушает KISS. Переходить на разработку без VCS привыкши к VCS, без реальной потребности (например написать один раз скрипт для парсинга сайта или для симуляции проще всего без VCS, даже если уже есть привычка к Git) - нарушает KISS.

MadTechGuy
Единомышленник
Всего сообщений: 430
Зарегистрирован: 29 июн. 2018 г., 09:36
Рейтинг пользователя: 71

1
. Редактировалось 1 раз, последний — #10
Julia написал(а):
Что за тип проектов? На каком стеке?

Из того, что на текущий момент я могу показать — этот CSS/JS микрофреймворк (что-то между микрофреймворком и библиотекой): sourceforge.net/projects/nativeui/. Но сразу оговорюсь, что это устаревшая версия, я потом доделаю и выложу обновлённую 2.0.0 версию с большим количеством изменений и нововведений, и с документацией (которая будет писаться с использованием нейронок). Вместе с веб-интерфейсом для llama-server (из состава llama.cpp), в котором используется этот микрофреймворк…

Julia написал(а):
Так коммит описывает верхнеуровневое (доменное) техническое изменение, а не что конкретно в коде изменилось. Если правки относятся к конкретной фиче, то в коммите к фиксу указываешь название фичи. И всё. Если это новая фича, то что-нибудь вроде `Add featureX`. И т.д.

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

Julia написал(а):
Но и расписывать всё подробно тоже не вижу смысла, потому что люди как правило это не ценят. Человеку либо неинтересен сабж, либо он пытается чуточку поискать в интернете и подумать, прежде чем взять это к применению и/или расписать новый аргумент.

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

Julia написал(а):
В общем я думаю VCS или без него - вопрос не только реальной целесообразности, но и привычки.

Это факт. Как и то, что с возрастом привычки менять сложнее — это же нужно перестроить весь привычный процесс разработки, который у тебя уже доведён до автоматизма за, возможно, не один десяток лет.

Следующие сообщения >>>
Страницы:
  • 1
  • 2
Распечатать

У вас нет прав для отправки сообщений в эту тему.