Мне кажется, что Git был разработан для крупномасштабных проектов с открытым исходным кодом с большим количеством разработчиков и команд.
Мне интересно, стоит ли Git для небольшой команды (< 10) и внутренних проектов (внутри организации). Я понимаю, что есть явное преимущество в производительности при наличии локальной копии репозитория (хотя это не так важно, когда ваш репозиторий внутри вашей организации...).
Вы по-прежнему рекомендуете Git (и сложность, которая приходит с ним) и почему?
Git на самом деле не такой сложный. И это фантастически мощный и точный. Я бы не использовал ничего другого, для проекта из одного человека или проекта на 100 000 человек. Я действительно это имею в виду.
Я понимаю, почему люди говорят, что это сложно, но все это переоценено. Чтобы сделать все, что вам нужно сделать, возможно, вам потребуется 10 команд max, с которыми вам нужно работать. И вам не нужно понимать каждый вариант этих 10... всего несколько рецептов в стиле поваренной книги.
Что вам нужно понять, это немного о том, как Git отличается под капотом. Но это не потому, что Git является сложным, потому что Git отличается. Вы можете потратить некоторое время в течение дня или двух, копаясь в этой информации, и вам будет хорошо идти.
Извините мою грубость, но Git делает файловую систему своей b * tch. Вы можете переключаться между "альтернативными реальностями" вашего программного проекта по своему усмотрению. Как только вы поймете, откуда идет инструмент, у вас будет полный, почти богоподобный контроль над битами и символами, составляющими ваше программное обеспечение. Существует несколько инструментов такой мощности, доступных разработчикам программного обеспечения, период.
Да, мужчина, рекомендую Git. Сделай это. Вы будете так рады, что сделали. Удачи.
Git имеет смысл как для больших, так и для небольших команд. Да, git является сложным, но это не означает, что вам всегда приходится иметь дело с этой сложностью. Я использую git каждый день, и я редко выдаю ничего, кроме:
git branch # To remind myself what features I'm working on.
git checkout <name_of_branch> # To switch to whatever I want to work on.
git checkout -b <name_of_new_feature> # To start work on a new branch
git add <name_of_file> # To add it to the list of tracked files.
git commit -m <commit_message> # To checkpoint my work.
git merge <name_of_branch> # To integrate changes back to trunk.
git branch -d <name_of_branch> # To delete a branch after it has been merged.
На самом деле есть только несколько команд, которые вам нужно помнить ежедневно. Для чего-то более сложного, вы всегда можете найти его в документации.
Одна из вещей, которые мне очень нравятся в отношении git и почему я настоятельно рекомендую использовать ее, заключается в том, что вы можете контролировать свою работу и контролироваться версией, даже если она еще не готова к передаче в репозиторий. Например, я могу использовать "git commit" много раз, локально, прежде чем показывать его другим разработчикам. Это значительно увеличило мою уверенность в внесении изменений в код; Я могу экспериментировать и не беспокоиться о том, что моя текущая работа будет потеряна - я всегда могу вернуться к безопасной версии, если что-то пойдет не так. Это нельзя сказать о SVN, например, когда в основном репозитории будут обнаружены какие-либо коммиты.
Я использую Git для проекта, который я запускаю сам (размер команды = 1), а для другого проекта с 5 членами.
Причины, по которым мне лично это нравится:
Преимущества для умной команды еще более очевидны:
Однако , если ваша команда немой (иногда это может быть правдой) или предвзято против Git, я настоятельно рекомендую против, потому что она требует определенных усилий и любопытство программиста, чтобы узнать, и не все в мире хотят разветвляться, объединять, использовать распределенный рабочий процесс или что-либо еще, что Git может предложить вообще.
Это довольно просто: он делает то, что он должен делать довольно красиво: контроль версий.
Больше, не меньше.
Он работает с моей IDE, он отлично сменяет групповые изменения, и я могу в любой момент вытащить старый код.
Да, из-за того, как отслеживание изменений работает по сравнению с svn. (В больших многоэтапных слияниях просто меньше конфликтов.)
Да, потому что вы можете делать небольшие локальные коммиты во время работы, а затем вносить полные рабочие изменения в основной репозиторий. Когда вы нажимаете все ваши крошечные коммиты, толкаются.
Да, потому что, когда вы вытаскиваете из основного репозитория, он не сливается сразу, а помещает вытащенный материал в ветки. Идеально подходит, когда вы делаете большие изменения и хотите отложить обновление несколько дней на некоторых компьютерах.
Я предпочитаю git по svn для проектов с одним человеком. Легче использовать одни и те же инструменты по всей линии, и поддерживать как ресурсы git, так и svn кажутся мне бесплодными.
Я бы сказал, да.
Даже сам по себе я обычно использую git, потому что все это полезные функции. Невозможность попадания в сеть (даже внутренняя) для всех, кроме двух операций (нажатие и вытягивание) - это огромная экономия времени в долгосрочной перспективе. Такие вещи, как проверка разных ветвей, происходят локально, точно так же, как чтение журнала.
Обратите внимание, что даже когда git распространяется, вы все равно можете иметь центральные хранилища, в которые все нажимают и вытягивают. Но это только центральный репозиторий по соглашению.
И дешевое создание ветвей также является преимуществом. Вы можете легко создать ветвь темы, где вы реализуете небольшую функцию, которую вы позже объедините снова в ветке разработки.
См. успешную стратегию ветвления git поток