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

9

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

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

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

Wolfi
источник
5
Git и Subversion поставляются с инструкциями; в основном это репозиторий, который хранит код разработки в структурированном виде. Отдельным разработчикам выгодно иметь полную запись изменений кода и надежное средство резервного копирования. Проектные команды получают возможность использовать один и тот же репозиторий исходного кода, синхронизируя изменения между рабочими станциями.
Роберт Харви

Ответы:

13

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

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

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

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

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

Майкл
источник
1
Хороший ответ, кроме одного пункта. Я бы определенно не выбрал сервер Subversion, так как это самый большой недостаток, отчасти потому, что я использовал его довольно часто; репозиторий может находиться в локальном каталоге, а затем установка выполняется одной командой. Основное различие между Git и Subversion заключается в том, что распределенные системы, такие как Git, гораздо более гибкие, чем централизованные, такие как Subversion.
Ян Худек
5

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

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

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

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

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

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

Тревор Пилли
источник
1
Не давать +1, потому что изучение Subversion как первой системы является своего рода непродуктивным в наши дни, когда все переходят на распределенные системы.
Ян Худек
3

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

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

SVN

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

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

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

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

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

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

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

DeveloperDon
источник
0

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

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

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

WarrenT
источник
«Git, похоже, еще не работает с« родными »исходными файлами IBM i)» - Git должен работать с любым файлом. В чем здесь проблема?
Марнен Лайбоу-Козер
@ MarnenLaibow-Koser Большинство разработчиков IBM i работают с исходными файлами с помощью того, что мы могли бы назвать собственной (устаревшей) файловой системой QSYS, где исходные файлы имеют встроенный формат фиксированной длины. Каждая строка начинается с 6-значного порядкового номера, 6-значной даты изменения, затем текстовой строки исходного кода. Последовательность и дата изменения могут измениться, даже если исходный код в строке не изменился. Решения могут быть разработаны совсем недавно. IBM и другие теперь поддерживают git на IBM i. И это не должно быть проблемой с источником в «обычных» потоковых файлах в других файловых системах IFS в IBM i.
WarrenT
О Боже, я смутно помню, что 20 лет назад занимался разработкой AS / 400. Но я думаю, что нет причин, по которым Git не будет работать с такими файлами. Возможно, вам придется написать драйвер слияния, который не учитывает номера строк, но это должно быть легко сделать. (Интересно, так поступила IBM ...)
Марнен Лайбоу-Козер,
Но если вы уберете номера строк и дату смены строк, вы потеряете их, когда вернете что-то из Git. Нелегко убедить некоторых людей, что им больше не нужны эти даты, полагаясь на них, возможно, на 3 десятилетия. Да, я знаю, что Git обвиняет то же самое, но люди не хотят отказываться от того, от чего они зависели так долго, даже если это не обязательно логический аргумент.
WarrenT
Вы можете сделать фильтр Git clean / smudge, чтобы восстановить дату из-за Git. :)
Marnen Laibow-