Как профессиональные разработчики приложений используют системы контроля версий, такие как GIT и Subversion?

Я начинающий разработчик, и с самого начала мне было интересно, как профессиональные инструменты используют такие, как GIT и Subversion (я не очень хорошо разбираюсь в этих инструментах), для удовлетворения потребностей своего проекта. Если они это используют, как бы я настроил что-то подобное?

Мои приложения не такие большие, и я еще не работаю в команде, они мне очень помогут?

На этом сайте есть вопросы о том, как использовать инструменты, но мне нужна поддержка начинающих.

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

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

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

Вот хороший обзор некоторых хороших практических правил для управления источниками в целом: http://scottonwriting.net/sowblog/archive/2008/11/13/163320.aspx

Работая самостоятельно, вам не нужно много рабочего процесса. Фиксируйте рано, совершайте часто. Если вы начинаете выпускать версии, пометьте свои версии. Создавайте ветки для экспериментов или длительной расходящейся работы (Git делает это дешевле и проще, чем Subversion).

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

Как только вы работаете с другими людьми в команде, преимущества увеличиваются еще больше, поскольку несколько человек могут изменять один и тот же файл, и если изменения не конфликтуют (например, 2 человека изменяют разные разделы файла), изменения будут объединены автоматически. Если возникнут какие-либо конфликты, вы сможете увидеть свои изменения рядом со своими коллегами и обсудить с ними, как объединить изменения.

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

Вот несколько полезных ресурсов:

Начало работы с Subversion и Tornise SVN с помощью Visual Studio и .NET

Контроль версий с Subversion

Учебники для начинающих

Есть отличные учебники (видео и текст), которые могут помочь вам начать с самого базового уровня. Похоже, у Git отличный подход к представлению этой темы для новичков, который сначала объясняет, почему, и использует повторение, определение и графику, чтобы помочь вам вспомнить имена и функции ключевых команд.

SVN

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

Профессиональный контроль источников встречает профессиональные потребности

Ваш вопрос "Как профессиональные инструменты, такие как GIT и Subversion, используют для удовлетворения потребностей своего проекта?" тесно связан с вопросом «Как команды работают вместе, не взаимодействуя друг с другом, и при этом работают максимально быстро?»

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

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

Из созданного репозитория контроля версий профессионалы могут выполнять другие задачи, такие как диагностика проблем до их первопричины. Если были версии кода, которые раньше работали, и недавно обнаруженные проблемы, возникающие в текущей версии, можно шагать вперед и назад по истории, чтобы точно определить, когда возникла проблема. В SVN эта возможность незрелая, но в Git поиск последней рабочей / первой ошибочной версии поддерживается командой git bisect. Проблема будет вызвана одним из исходных изменений между двумя версиями, что может оказаться намного более легкой диагностикой, чем поиск по всей базе кода.

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

Моя команда использует собственную систему управления версиями. (К сожалению, Git, похоже, еще не работает с «родными» исходными файлами IBM i). Но лично, когда я извлек источник из этой системы, я использую Git во время своей разработки, пока проект не будет завершен, и я проверю его обратно в Команда VCS.

Как говорится при голосовании ... совершайте досрочно, совершайте часто. Поскольку я работаю над новыми функциями, я фиксирую. Я фиксирую между компиляциями, и при каждой попытке исправить ошибки компилятора, каждый раз, когда я делаю изменения во время тестирования и отладки. Это позволяет упростить использование нескольких вариантов темы и, при необходимости, легко отказаться от нее, особенно если изменение согласовано между несколькими файлами.

Git улучшил мой подход к разработке.