Контроль источника - если, почему, с чего начать?

Ответ 1

• Да, конечно.
• Начните с Subversion и клиента TortoiseSVN. Он получил отличную поддержку, отличные инструменты и, как правило, гораздо более сложный для настройки и использования, чем Git.

Отличное Руководство по Subversion доступно бесплатно.

Ответ 2

Я собираюсь пойти против текущего зерна и сказать, пошли с Git. Это то, что я сделал, а не изучение SVN. Прочитайте первый бит git book.

Как только у вас это получилось, это очень просто использовать. Хотите запустить новый репозиторий в текущем каталоге?

git init

Хотите передать все с коротким сообщением фиксации?

git commit -am 'My commit message here'

Это действительно не ракетостроение, так как некоторые из вас могли бы поверить.

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

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

Зачем использовать github? Если ваш компьютер взрывается, там есть копия в облаке. Если вы хотите сотрудничать с другом, отправьте им ссылку, и они могут перейти от github-v. Прямо.

Edit2:

4: Это не вызовет никаких проблем.

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

Ответ 3

• Да, вам нужно иметь контроль над версиями.

• Я предлагаю вам установить Subversion на ваш компьютер (независимо от того, что вы установили). Если вы работаете с окнами, также получаете TortoiseSVN, это лучший клиент для Subversion. Сервер Subversion отлично работает на ПК.

• Загрузите и прочитайте руководство Subversion. Одна из ранних глав дает ответы на многие ваши вопросы, но не все они слишком предвзяты в пользу Subversion.

Да, есть другие системы VC, но для одинокого ученика я настоятельно рекомендую Subversion + TortoiseSVN.

НТН

Марк

Ответ 4

Ответ на ваши изменения, пункты 4 и 5 (отметив, что мой голос за GIT), мы используем его здесь (среда многопользовательских окон), и это действительно очень эффективно:

4., что, если я решит полностью изменить структуру моей программы?

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

Ваша система управления версиями - это просто "простой" способ сделать снимок ваших файлов в определенный момент времени.

5., Из других вопросов, как я могу это сделать?

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

Ответ 5

Что касается управления версиями, вы можете посмотреть на это "Как использовать SVN, Branch? Tag? Trunk?" .

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

Ответ 6

Другие ответы на них. Тем не менее, я бы также упомянул, что существуют два разных стиля управления версиями:
1) centralized = вы сохраняете свой код на сервере, хотя это может быть ваша локальная машина (например, CVS, SVN)
2) distributed = вы сохраняете свой код в локальной базе данных (например, Git, Mercurial)

SVN - это в значительной степени стандартная централизованная программа управления версиями defacto, хотя вам нужно настроить ее сервер, чтобы использовать его. Не слишком сложно, но вы можете попробовать распределенную систему, например Mercurial, чтобы вырезать дополнительный шаг.

Ответ 7

По новым вопросам:

4: Реорганизация вашего приложения не будет проблемой. Они просто видят, что некоторые файлы удалены, а другие добавлены.

5: Как часто вам нравится. Чем чаще вы совершаете, тем легче исправлять небольшие ошибки.

Ответ 8

В одиночной части хобби, контроль источника решает три проблемы для меня.

• Резервное копирование в случае сбоя оборудования/программного обеспечения /wetware
• Простая синхронизация между различными компьютерами (ноутбук, рабочий стол, компьютер для друзей)
• Но для меня был сменой игры Git сильная поддержка ветвления.

Позвольте мне перейти на # 1. Помимо случаев неконтролируемого отказа, я могу уйти и сделать спекулятивную разработку, и если/когда спекуляция не вернется к стабильной базе, это будет легко.

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

В разработке я использовал SourceSafe, ClearCase, CVS, SVN, SCCS, RCS и Git, и для меня инструмент, который регулярно менял контроль версий на хобби, был для меня Git. Он не только ушел с моего пути, но и облегчил выполнение вышеупомянутых задач.

Ответ 9

Решение о том, следует ли использовать контроль источника, действительно зависит от ваших потребностей. Для единой архитектуры типа разработчика и небольших проектов вы, скорее всего, будете использовать его для управления версиями; что позволяет вносить изменения в ваш код, не беспокоясь о потере того, что вы уже делали. Такие звуки звучат так, как будто вы находитесь, поэтому я не стал бы обернутым во всех аспектах контроля источника. Если вы не заботитесь о сохранении этих версий и готовы рисковать потерять вещи, то контроль источника может быть накладными расходами, которые вам не нужны.

Большинство людей здесь скажут, что Subversion (SVN) - это путь, и они, вероятно, правы. Не обязательно, потому что это лучший инструмент, но потому, что он свободен и довольно легко понять и использовать. Он также широко распространен сообществом с открытым исходным кодом, что означает, что в Интернете есть много информации об этом. TortoiseSVN даже работает в основном из контекстного меню (щелкните правой кнопкой мыши) в Windows, чтобы вы могли избежать любых дополнительных "редакторов".

Ответ 10

Даже в качестве одного разработчика существует ряд преимуществ при использовании некоторой формы контроля версий. Для меня самая важная причина в том, что если вы испортите исходный код (если вы, например, сделаете ряд больших изменений и ваша программа перестанет работать), вы можете вернуться к предыдущей рабочей версии. Поэтому по первому вопросу я бы сказал: "Да, определенно!".

Если у вас нет проблем с созданием вашего открытого кода с кодом, есть несколько сайтов, которые могут бесплатно разместить ваш проект, например google и sourceforge. В противном случае вы можете запустить сервер subversion, cvs и т.д. На своем собственном компьютере.

Что касается рабочего процесса, большинство программ для управления версиями (VCS) работают примерно так:

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

Для вопроса 4: Большинство VCS поддерживает перемещение/переименование файлов, и это также войдет в историю, поэтому это не должно приводить к путанице.

Вопрос 5: Как можно чаще. На работе я фиксирую, как только я сделал какое-либо изменение, которое я проверил, работает. В многопользовательском сценарии он считал, что кардинальный грех нарушает сборку, т.е. Фиксирует не компилируемую/нерабочую версию, так как это приводит к тому, что другие разработчики могут перестать останавливаться, если обновление их кода. Если вы единственный разработчик, вы можете быть несколько более слабым, я думаю.

Ответ 11

Вы говорите, что ищете "мертвый простой удар", и в этом случае я бы рекомендовал Git. После установки инструмента

git init

инициализирует репозиторий в текущем каталоге.

git add yourfiles

чтобы добавить файлы, которые вы хотите контролировать, и

git commit -ma "commit message"

для фиксации изменений.

Github Guides - отличный ресурс для начала использования Git на большинстве платформ и содержит много полезных ссылок.

Ответ 12

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

Системы управления версиями поставляются в различных вариантах. Возможно, вы сталкивались с такими терминами, как централизованные, распределенные, локальные и т.д., Которые могут смущать непосвященных. Самые хорошие книги по любой системе контроля версий (Книга Subversion для Subversion и Pro git book для git) даст вам некоторое представление о самом управлении версиями (в разводе с фактическим инструментом, который они охватывают). Я также рекомендую страницу Википедии и эту страницу для быстрое введение.

Как только вы закончите, возьмите систему. Есть много вариантов, но их философии разные. SVN, CVS и т.д. Централизованы и потеряли почву для более новых, таких как git и mercurial, которые распределены. Я бы порекомендовал вам сначала попробовать и использовать subversion (поскольку он все еще широко используется, и умение будет полезно), а затем любой распределенный (мой личный фаворит - git).

Окончательный акт обучения придет только с практикой и опытом, а не с чтения книги. Удачи.:)

Ответ 13

Почему? Я много работаю самостоятельно и коммерчески, я никогда бы не стал, никогда не начинал полусерьезный проект без контроля источника. За эти годы я потерял слишком много демоверсий (я много занимаюсь преподаванием) и другого кода, который, по моему мнению, имеет важное значение для обеспечения безопасности источника. Я также запускаю несколько машин (по крайней мере, ноутбук и рабочий стол), это означает, что я могу совершать коммиты и проверки из нескольких мест.

Как? Для моей настройки у меня есть subversion, размещенная на Apache, работающая в Windows. Это было на Linux, но я переместил его по различным нетехническим причинам. Он работает на виртуальной машине VMWare. Я не знаю точно, но я не удивлюсь, если для этого есть устройство VMWare - я уверен, что для Apache есть устройство VMWare. Настройка проста и требует практически никакого администрирования, кроме того, когда я хочу добавить новый проект в управление версиями. Мой сервер подвергается внешнему миру, поэтому я могу получить доступ к нему из любого места, при необходимости вы можете просто иметь сервер в своей домашней сети.

Как я уже сказал, я использую подрывную деятельность. У меня также есть git, установленный на сервере, но не переключенный на git, частично из-за инерции с моей стороны и частично из-за инструментов. Сегодня я работаю в основном в .net и Visual Studio в Windows, поэтому мне нравятся инструменты, интегрированные в Visual Studio, а не то, что я не прочь запустить инструменты командной строки, это просто проще, если они интегрированы.

Что касается изменения структуры программы - главное преимущество управления версиями в этом случае состоит в том, что если вы плохо испортите, вы можете вернуться назад. Вы даже можете попробовать и выбросить изменения, если они не работают, например, разветвляя текущую основную линию разработки. Если бы я пытался перестроить структуру, я бы, вероятно, разветкил мою базу кода, переструктурировал, чтобы все работало, а затем переместил эту ветвь по "туловищу" (в терминах svn). Вам не нужно так поступать, но это дает вам сеть безопасности.

Как часто я должен совершать транзакции? Это зависит! Для кода, вероятно, на единице работы (которая может быть всего лишь добавлением одного теста или столько же, сколько добавление функции), проверять код всегда следует. Для документов реже. У вас также могут быть политики компании на этом, а также такие механизмы, как стеллажи (в VSTS), где вы можете хранить код в репозитории без проверки. Помните, что репозиторий существует: a) держит ваш код в безопасности b) для хранения последней копии код и c), чтобы разрешить совместное использование кода. Для выполнения b) и c) код должен быть построен и проходить все тесты, поэтому не произвольно проверяйте код.

Надеюсь, что это поможет

Ответ 14

Да! Да! начните с Git.

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

Но с Git у меня нет проблем с попыткой новых трюков в моем коде, что я делаю, это просто ветвь моего хозяина (основное стабильное приложение), и мои попытки, и если я не могу выполнить то, что я пытаюсь, я просто отбрасываю и быстро вернитесь к моему Учителю, который все еще остается нетронутым, безопасным и стабильным. И если успешно (что большую часть времени нет), я просто объединить ветвь к хозяину, а затем отбросить ветвь. Как хорошо.

Ветвление в Git было тем, что заставило меня упасть с ног на голову. Попробуйте

Ответ 15

• Хорошая идея начать с контроля версий. За очень немногими исключениями, каждый программный бизнес там будет использовать какую-то форму контроля версий, поэтому чем больше у вас опыта, тем лучше. Плюс, контроль источника - это просто хорошая идея, и я использую его практически для всего, что я делаю. Пример: каждый раз, когда я отправляю свое резюме потенциальному работодателю, я помещаю эту версию. Теперь у меня есть постоянный снимок того, что было похоже на какое-то время.

• Как: Как зависит от того, с какой системой вы решили пойти. Я собираюсь добавить свои 2 цента к обсуждениям и поставить голосование за Git. После установки Git, ветвления, фиксации, создания репозитория; все это очень просто и очень быстро. Для одиноких разработчиков отсутствие центрального репозитория упрощает настройку. Я не соглашусь со всеми, кто сказал, что обучение Git было легким. Некоторые из команд настолько эзотеричны, что вы никогда не сможете отучить себя от частых взглядов на документацию. (git push origin :some-branch кто-нибудь?)

• У вас не было вопроса № 3, поэтому я предоставляю ссылку: http://gitready.com/

• Полностью изменить структуру вашей программы совсем не проблема. Зафиксируйте, прежде чем вносить изменения, совершите повторный ввод после внесения изменений, вы сможете отбросить все обратно, если вы закроете вещи. Еще одно преимущество перехода с Git заключается в том, что Git будет отслеживать текст в нескольких файлах. Например, если Алиса пишет 20 строк кода в файле A.m, а Боб перемещает эти 20 строк кода в файл B.m, Git позволит вам отследить исходный код этого кода до Алисы.

• Я фиксирую постоянно, почти каждое изменение, которое я делаю, получает фиксацию и описание. Не забудьте сообщение фиксации! Имея список из 100 коммитов с ничего, кроме отметки времени, вы почти ничего не добьетесь. Когда я делаю много настроек и/или рефакторинга графического интерфейса, я часто трачу больше времени на запись сообщений о фиксации, тогда я пишу код... но тот раз, когда 2 символа, редактируемое 17, завершает мои тестовые примеры, Я буду рад, что был настолько либеральным и многословным с моими коммитами.

• Да. Иногда требуется некоторое усилие, чтобы разобраться в деталях, но если вы умеренно осторожны, ваши данные редко уходят навсегда.

• Если никто не хочет этого, я возьму его.; -)

Ответ 16

Мне нужно добавить свой голос для mercurial. Нельзя оставить объект всеобщего освещения до git.; -)

Но что бы вы ни выбрали в конце, начните использовать его. Я откровенно поражен тем, что вы работали со всеми этими языками/инструментами и никогда не начинались с каких-либо VCS. Я начал RCS в тот момент, когда узнал об этом (вернемся к почтенной Amiga 1000, без HD, только 176 КБ гибких дисков:)). Не мог себе представить, чтобы не использовать какой-либо VCS. Я на самом деле все еще использую RCS для одиночных файлов, которые не нуждаются в чем-либо.