Управление исходным кодом - Если, Да ведь Как запустить? [дубликат]

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

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

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

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

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

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

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

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

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

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

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

git init

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

git add yourfiles

Чтобы добавить файлы, которые вы хотите управлять, и

git commit -ma "commit message"

для получения изменений.

Гиды GitHub являются отличным ресурсом для запуска с использованием GIT на большинстве платформ и содержит много полезных ссылок.

        Dim aDate As DateTime = #3/1/2008# 'sample date
    Dim StartDate As DateTime = aDate.AddMonths(-1).AddDays(-(aDate.Day - 1))
    Dim EndDate As DateTime = StartDate.AddDays(DateTime.DaysInMonth(StartDate.Year, StartDate.Month) - 1)

    'to access just the date portion
    ' StartDate.Date
    ' EndDate.Date

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

Превосходное руководство Subversion manual доступно бесплатно.

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

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

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

1. Резервное копирование в случае сбоя аппаратного обеспечения / программного обеспечения / SETWARE
2. Легкая синхронизация между различными машинами (ноутбук, рабочий стол, компьютер друг)
3. Но, чейнджер игры для меня был сильной поддержкой Git для разветвления.

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

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

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

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

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

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

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

5., Из других вопросов, как часто я совершаю?

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

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

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

git init

Хотите совершить все с небольшим сообщением Commitse?

git commit -am 'My commit message here'

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

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

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

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

Редактировать2:

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

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

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

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

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

4. Полностью изменение структуры вашей программы не проблема вообще. Официально до того, как вы внесите изменения, совершите снова после того, как вы внесите изменения, вы сможете удалить все обратно, если вы держите вещи. Еще одно преимущество в том, что Git будет отслеживать текст по нескольким файлам. Так, например, если Alice пишет 20 строк кода в файле AM , и BOB перемещает эти 20 строк кода в файл BM , Git позволит вам отследить источник этого кода Алису.

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

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

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

1. Да, вам нужно иметь контроль версий.

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

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

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

HTH

Марка

Для ваших новых вопросов:

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

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

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

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

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

Существует отличное ручное пособие .

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

Если у вас нет проблем с выполнением вашего кода открытым исходным кодом. Есть несколько сайтов, которые могут провести ваш проект бесплатно, например Google и SourceForge . В противном случае вы можете запустить Subversion, CVS и ETC Server на своем компьютере.

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

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

для вопроса 4: большинство VCS поддерживает для перемещения / переименования файлов, и это также пойдет в историю, так что это не должно привести к какой-либо путанице Отказ

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

Потому что тогда вы узнаете новый язык, что означает более широкий набор навыков и другой способ рассмотрения проблем. Но поскольку Groovy и Scala работают на JVM и вы знаете Java, вы можете интегрировать существующие библиотеки и код, если вы хотите или нужно.

Вы пытались аннотировать исключение с помощью @ WebFault ? Кроме того, реализуется getFureInfo () ?

EDIT: Я понимаю, что мой ответ был недостаточно подробным. Как напоминается в , этот поток (например):

Спецификация JAX-WS 2.0 требует что исключение аннотировано с помощью @ WebFault должен иметь два конструктора и один метод [получения для получения информации об ошибке]:

 WrapperException (строковое сообщение, FureBean fureInfo)
WrapperException (строковое сообщение, FureBean fiveInfo, причина, допускающая изменение)
FureBean getFureInfo ()

Исключение оболочки заменено на имя исключения, и FureBean заменяется классом имя, реализующее компонент отказа. Компонент отказа - это компонент Java, который содержит информацию об ошибке и используется клиентом веб-службы знать причину ошибки.

Это подробно описано в разделе 2.5 Отказ спецификации JAX-WS. Соответствует ли этому ваше исключение? Можете ли вы опубликовать код?

OP прав. В соответствии со спецификацией 2,1, раздел 3,7 Исключение для конкретной услуги, не требуется использовать аннотацию @ WebFault , JAX-WS может динамически генерировать фасоль обертки для исключений, которые не соответствуют образцам, описанным в разделе 2,5 (просто предоставьте получатель информации, которая должна присутствовать в сбое). Для исключений, соответствующих образцов, описанным в разделе 2,5 (т.е. исключений, имеющих метод getFureInfo и аннотацию @ WebFault ), при сопоставлении исключения со схемой XML в качестве входных данных для JAXB используется FureBean .

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

Да! Да! пожалуйста, начните с Джит.

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

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

Ветвление в Гите заставило меня упасть с ним головой над пятками. Попробуйте

Другие ответы на месте. Однако я также упомянул, что есть два разных «стиля» контроля источника:
1) централизованные = Вы храните свой код на сервере, хотя это может быть вашим локальным компьютером (E.g. CVS, SVN)
2) Распределение = Вы храните свой код в локальной базе данных (например, GIT, Mercurial)

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

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

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