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

84

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

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

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

Анто
источник
61
Нет, я использую git и hg для личных проектов. Наличие локального контроля версий - находка.
WKL
7
Git во многих отношениях лучше для всех проектов, независимо от того, имеют ли они большое количество участников или нет: git сжимает вещи намного, гораздо эффективнее, чем svn (и на порядок быстрее!), Git делает резервные копии тривиальными, а git не будет быть препятствием, если кто-то еще хочет внести свой вклад.
Артефакт2
4
Я использую контроль версий, чтобы отправить свой код в github или bitbucket, он служит для меня резервной копией, и, возможно, когда-нибудь я напишу что-то, что будет действительно интересно людям.
Махмуд Хоссам,
8
«Мне не нужна возможность создавать собственную ветку, главная ветвь - моя». Многие люди говорили то же самое о том, undoкогда это была относительно новая функция в приложениях. Теперь все понимают, что им это было нужно все время. Вам нужно ветвиться, вы просто этого не знаете.
Дэн Розенстарк
1
@ rtperson да, вы можете сделать это, но мне больше нравится Mercurial, хотя мне больше нравится github, чем bitbucket.
Махмуд Хоссам

Ответы:

155

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

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

> git init

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

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

Spoike
источник
24
Принято. Я не мог доказать, что был более неправ в том, что мерзавец излишний, чем этот;)
Anto
7
Steve341: Я обычно храню все проекты с исходным кодом в папке с именем «projects». Здесь я храню все репозитории, по одному для каждого проекта с исходным кодом. У меня никогда не было необходимости отслеживать несколько проектов вместе в одном и том же хранилище VCS; для этого нужны системы управления зависимостями, такие как Ivy или Maven.
Спойк
3
@ Steve341 Как сложно отслеживать эти вещи? У вас есть только одна папка, которая содержит все ваши репозитории. Он ничем не отличается от вашей системы, за исключением того факта, что ваша система является крайне плохой практикой при использовании git ...
альтернатива
2
@ Steve314:echo 'for dir in projects/*; do cd "$dir"; git push; cd ..; done' > update_all; chmod +x update_all
Андре Парамес,
2
git initи бац! Ах, да, а потом, cp ../the-other-project/.gitignore .до первоначального коммита. Бам!
Дэн Розенстарк
46

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

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

greyfade
источник
Я думаю, я должен был использовать «мощный» вместо «сложный»
Anto
3
@ Анто: не имеет значения. Я бы сказал, в основном то же самое: превосходное ветвление в Git просто не имеет недостатков по сравнению с SVN.
Greyfade
3
Также Git не будет "загрязнять" ваше дерево исходников файлами отслеживания в каждом подкаталоге.
WarrenT
4
@WarrenT «загрязнение» исходного дерева не происходит в SVN версии 1.7 и выше.
pleee
4
Создание хранилища файловой системы в Subversion - это одна команда ( svnadmin createплюс одна для первоначальной проверки или импорта), не нужно устанавливать разрешения и так далее. Я не отрицаю, что Git часто лучший инструмент, но неточности в Subversion не помогают.
Джош Келли
34

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

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

Берин Лорич
источник
2
Да, я считаю, что это точка ветвей, экспериментов. Это была моя первая оговорка при чтении вопроса Опа. Если вы не разветвляетесь в своем хранилище, вы «разветвляетесь» в своей голове, и это просто бессмысленно, если у вас есть контроль версий.
Крис
3
Вы можете ветвиться с подрывной деятельностью. И слить. Вроде, как бы, что-то вроде. На самом деле, единственный раз, когда я пытался это сделать, у меня получилось поврежденное хранилище, с которым я больше не мог работать, и восстановление из резервной копии (с уже примененной веткой) не помогло, поэтому я потерял всю свою историю и запуск нового репозитория ... но я обвинял это в переходе с 1.4. до 1,5 (я думаю - это было несколько лет назад). Возможно, разветвление и слияние работают, правда. Если вы достаточно смелы, чтобы попробовать это. Если бы я тогда знал о svn dump, то, конечно, мог бы решить проблему с некоторыми усилиями.
Steve314
@ Крис, мне нравится иметь рабочую версию, к которой я могу вернуться в любое время. Конечно, вы можете сделать это с помощью тегов, но бывают моменты, когда ветка имеет смысл. Не забывайте и о других преимуществах git / mercurial.
Берин Лорич
9

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

stonemetal
источник
Это может быть излишним (да, с этим определением), если система встанет у вас на пути. Мне интересно, будет ли хорошей идеей использовать git для личных проектов. Не могли бы вы сказать мне, каковы конкретные преимущества? Этот ответ не относится к этому. Я вижу git как более мощную систему, слишком мощную для личных проектов. В этом не должно быть никакого вреда, если это не мешает вам. Не могли бы вы расширить свой ответ?
Anto
1
Overkill также используется, когда усилия, приложенные для применения решения, несоразмерны. Можно утверждать, что если вы уже используете subversion для локальных проектов, нужно приложить усилия для изучения Git или чего-то еще. Или, возможно, полезный урок, развивающий передаваемые навыки, конечно. Лично я до сих пор пользуюсь Subversion - она ​​меня кусала несколько раз, но оставляла только незначительные шрамы. Я заинтересован в изучении Git, но каждый раз, когда я смотрел, учебники, которые я находил, были загадочными, или я не мог получить стабильные инструменты для Windows, или был какой-то другой блокпост, который заставлял все это казаться, ну, в общем, излишним.
Steve314
7

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

dsimcha
источник
7

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

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

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

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


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


источник
2

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

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

Крис Москини
источник
1
Да, я использую DropBox для личных проектов. Управление версиями далеко не так сложно, как настоящая VCS, но оно подходит для небольших проектов, которыми я занимаюсь в свободное время, и вообще не требует внимания (например, нет коммитов, файлы просто обновляются по мере работы над ними)
jhocking
о, кстати, поскольку я разрабатываю игры, в моих проектах обычно много бинарных файлов (графических файлов, аудиоклипов и т. д.), и большинство систем контроля версий действительно предназначены только для исходного кода.
Джоккинг
Git отлично работает с бинарными файлами, различия просто менее интересны. К счастью, анализ в git не совсем заблокирован - если вы можете найти любимый бинарный инструмент сравнения, вы можете использовать его с git довольно легко (из командной строки)
Крис Москини,
Мне сказали, что Git тратит впустую много бинарных файлов с версионированием, но то, что мне сказали, может быть неверным. По сути, мне сказали, что большинство бинарных ресурсов (я полагаю, не все бинарные файлы, но изображения и звуки, которые входят в игру) должны быть полностью восстановлены в каждой версии, и поэтому Git заполняет ваш жесткий диск локальным хранилищем.
Джоккинг
Это только расточительно, если вы не хотели создавать бинарные файлы. Если вам нужно их версии, то история версий не пустая. Я думаю, что они случайно намекают, что git раздувает свою историю версий при отслеживании бинарных файлов - это неправильно. git.wiki.kernel.org/index.php/GitSvnComparsion
Крис Москини
2

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

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

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

perdian
источник
1

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

wlangstroth
источник
1
Это похоже на то, насколько хорошо ты знаешь дарков. Я никогда не использовал его, но много использовал git. Для меня мерзавец очень прямолинеен, но держу пари, что я бы почесал голову, если бы мне пришлось использовать дарки.
Сэм
1
Если вы уже освоили безумный пользовательский интерфейс git, darcs станет легкой прогулкой.
wlangstroth
1
не могли бы вы объяснить, почему darcs лучше для небольших проектов, чем git?
Шабун
0

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

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

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

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

WarrenT
источник
Чтобы
узнать