Git для личных (один человек) проектов. Overkill?

Я знаю и использую две системы контроля версий: Subversion и git. На данный момент Subversion используется для личных проектов, где я являюсь единственным разработчиком, а git используется для проектов с открытым исходным кодом и проектов, где, как я полагаю, другие также будут работать над проектом. Это главным образом из-за удивительных возможностей разветвления и слияния в git, где каждый может работать в своей собственной ветке; очень удобно.

Теперь я использую Subversion для личных проектов, так как я думаю, что в git нет особого смысла. Кажется, это немного излишне. Это нормально для меня, если он централизован (обычно на моем домашнем сервере), когда я единственный разработчик; В любом случае, я регулярно делаю резервные копии. Мне не нужна способность создавать свою собственную ветку, основная ветвь - это моя ветка. Да, SVN имеет простую поддержку ветвления, но я думаю, что гораздо более мощная поддержка для нее не имеет смысла. Слияние может быть болезненным с ним, или, по крайней мере, из моего небольшого опыта.

Есть ли для меня веская причина использовать git в личных проектах, или это просто перебор?

Это не перебор. Основная причина, по которой я начал использовать Git и Mercurial over Subversion для личных проектов, заключается в том, что запуск репозитория намного проще.

Хотите начать новый проект?

> git init

BAM! Не нужно ни настраивать сервер репозитория, ни проверять структуру папок для поддержки ветвления и тегов в репозитории subversion.

Совместное использование вашего проекта - это просто вопрос git push(кроме наличия удаленного хранилища). Попробуйте сделать это быстро с Subversion!

Я бы сказал, что использование Subversion для локальных личных проектов излишне, а Git - нет. Git будет занимать меньше места (из-за неэффективной концепции SVN «пересмотры» по сравнению со снимками объектов Git), требует меньше настроек (по git initсравнению с дюжиной svnadminкоманд и настройкой разрешений и т. Д.), Резервное копирование легче ( git clone --bare[или git push originесли вы используете Github) или аналогичный], и все готово), и имеет лучшие инструменты для управления вашим кодом (ветвление бесплатное, а объединение легче и чище). Тот факт, что клон вашего хранилища ни у кого больше не значит, не означает, что преимущества любого DVCS "чрезмерны".

Кроме того, я бы сказал, что поддержка ветвления в Git менее сложна, чем в SVN, с большим вознаграждением.

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

Это исходит от давнего пользователя Subversion. Консолидация на одном инструменте действительно может сделать вашу жизнь проще.

Overkill зарезервирован для случаев, когда существует «сопутствующий ущерб», вызванный «решением». Использование оружия, чтобы убить муху, означает, что есть повреждение, вызванное тем, что пуля куда-то улетела. Это излишне. Использование чего-то более мощного, чем необходимо, которое не вызывает проблем, не является излишним и может быть полезным, если оно поможет вам упростить процесс разработки. Это не причиняет вреда и позволяет обновлять только один комплект программного обеспечения вместо двух. Так зачем использовать две системы вместо одной?

Я использую Git для своих проектов с одним человеком, и мне это нравится. Ранее я использовал Subversion, но пока еще не видел недостатков в использовании Git. Это более мощный, но не способ сделать простые вещи более сложными. Создание простых вещей излишне сложно / дорого / медленно / и т. Д. ИМХО является необходимым условием для вызова чего-то излишнего. Кроме того, на Github я разветвлял ранее созданные одним человеком проекты, чтобы добавить нужную мне функцию, а затем отправлял им запросы на извлечение. Было бы неплохо, если бы кто-то заинтересовался моими проектами и сделал то же самое.

Я никогда не использовал управление исходным кодом в личных проектах до DVCS, поэтому немного странно представить, что кто-то придерживается противоположной точки зрения. Некоторые из моих причин:

• Легко установить и снести. Например, коллега дал мне на прошлой неделе программную загадку, которую я решил за несколько небольших шагов. Я сделал мерзавец-репо, который продлился все 45 минут, чтобы удержать мою работу, и затем это ушло. Я не знаю, насколько легко что-то подобное в подрывной деятельности, но я никогда не слышал, чтобы кто-то делал это.
• Отключен. Для меня возможность работать в автономном режиме гораздо больше пользы для хобби, чем для работы. Мне не нужно пробивать дыру в домашнем брандмауэре или публично размещать проект. Я могу временно поставить репо на флеш-накопитель или ноутбук, и при этом все синхронизировать.
• Все в одном месте. Совместное использование репозитория и рабочего дерева облегчает отслеживание небольших проектов в процессе обновления ОС.
• Мощные функции. Конечно, мне не нужна энергия все время, но она есть там, где она мне нужна, и не потребляет никаких ресурсов, когда я не нуждаюсь.

Мне сказали, что git-bisectочень удобно находить точный коммит, который вводит данное поведение, перемещаясь туда-сюда в коммитах в зависимости от вашего ввода.

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

РЕДАКТИРОВАТЬ: Кроме того, возможность ветвления очень важна, когда вы должны делать исправления в старых версиях, которые используют клиенты. Вы должны быть в состоянии управлять «просто исправить эту крошечную вещь, но я не хочу самую новую версию, потому что я не хочу проверять это снова и снова сейчас».

Это зависит от того, насколько серьезно вы хотите получить версионность своего собственного кода. Если то, что вы создаете, это, например, простая библиотека, которая будет иметь только текущую версию (или до тех пор, пока это правда), я бы лично использовал опцию резервного копирования, такую ​​как Dropbox. Если вы потеряете весь свой код, вы можете восстановить его из Интернета, и Dropbox предоставит 30-дневную резервную копию версии, если вы действительно делаете что-то глупое.

Однако, если вам, например, необходимо поддерживать ветки Production и Dev, то git - отличный инструмент - и намного быстрее, чем svn. Имейте в виду риск сбоя жесткого диска, если вы храните данные только локально.

Я всегда, всегда, всегда использовал систему контроля версий для любого проекта разработки. Большой или маленький действительно не имеет значения. Играю ли я дома с какой-то новой технологией, пишу небольшой помощник, чтобы облегчить мою жизнь, или профессионально развиваюсь в большой и распределенной команде - я всегда хотел бы, чтобы система контроля версий поддерживала меня.

Конечно, большую часть времени для небольших личных проектов вы не будете использовать большинство функций, но настройка git-репозитория (или даже локального Subversion-репозитория) не составляет большого труда, так что дерзайте! И прежде чем вы это узнаете, вы захотите узнать: «Черт, каково было содержимое файла X в прошлую пятницу?». Без контроля версий - удачи ;-)

Так что на самом деле не имеет значения, используете ли вы git или SVN - лично я начинаю переносить все больше и больше вещей из SVN в git, но главное - вообще использовать контроль версий - даже для мелочей.

Только потому, что никто не упомянул об этом: для личных проектов darcs действительно хорош и менее вовлечен, чем git, для простого контроля версий. Это не так быстро для крупных проектов, но и Subversion!

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

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

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

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