Что такое Git и Subversion?

Ответ 1

Контроль версий (контроль версий a.k.a.).

Рассмотрим следующую задачу. Вы работаете над проектом с кем-то еще, и вы делите файлы. Вам обоим нужно работать, скажем, "WhateverController.java". Это огромный файл, и вы оба должны его отредактировать.

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

Старое примитивное "решение" этой проблемы состояло в том, чтобы иметь механизм checkout/checkin. Когда вам нужно отредактировать файл, вы "проверите его", и файл заблокирован, поэтому никто другой не может его редактировать, пока вы не разблокируете его, "проверив его". Это делается через соответствующее программное обеспечение, например, Microsoft, потрясающе тупой кусок дерьма SourceSafe. Но когда люди забывают "проверить файл в", тогда никто другой не может редактировать этот файл во время его использования. Затем кто-то отправляется в отпуск или покидает проект по какой-то другой причине, и результатом является бесконечный хаос, путаница и, как правило, совсем немного потерянного кода. Это добавляет огромную управленческую работу.

Затем появились CVS, а затем Subversion, которые авторы называют "CVS done right", поэтому CVS и Subversion - по сути одна и та же идея. С ними нет фактической проверки. Вы просто редактируете нужные файлы и проверяете их. Обратите внимание, что фактические файлы хранятся на центральном сервере, и каждый пользователь запускает программное обеспечение на своих собственных рабочих станциях. Это место на сервере называется репозиторием.

Теперь, что произойдет, если два человека работают над одним и тем же файлом в CVS/Subversion? Они объединяются, как правило, с использованием GNU diff и patch. "diff" - это утилита, которая извлекает разницу между двумя файлами. "patch" использует такие файлы "diff" для исправления других файлов.

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

Позвоните в исходный файл WhateverController.java, файл A. Вы редактируете файл, а результат - файл B. Я редактирую тот же файл в другом месте, без ваших изменений, и этот файл является файлом C.

Теперь у нас есть проблема. Изменения в файлах B и C являются как изменениями в файле A. Таким образом, в смехотворном обратном барахле, как SourceSafe или Dreamweaver, как правило, в конечном итоге отменяет изменение файла B (потому что сначала он был проверен).

CVS/Subversion и предположительно Git (о котором я почти ничего не знаю) создают патчи вместо просто переопределяющих файлов.

Разница между файлом A и C производится и становится патчем X. Разница между A и B производится и становится патчем Y.

Затем патчи X и Y применяются к файлу A, поэтому конечным результатом является файл A + изменения, внесенные в B и C на наших соответствующих рабочих станциях.

Обычно это работает безупречно. Иногда мы можем работать над одной и той же функцией в том же коде, и в этом случае CVS/Subversion уведомит программиста о проблеме и представит проблему в самом файле. Эти проблемы обычно легко исправляются, по крайней мере, у меня никогда не было проблем с их решением. Графические утилиты, такие как Visual Studio, Project Builder (Mac OS X) и такие, как правило, показывают вам как файлы, так и конфликты, поэтому вы можете выбрать, какие строки вы хотите сохранить, а какие выбросить... и затем вы также можете редактировать файл вручную, если вы хотите объединить конфликт вручную.

Итак, по сути, контроль источника - это решение проблемы нескольких людей, работающих с одними и теми же файлами. Это в основном это.

Надеюсь, это объяснит.

EDIT: Есть много других преимуществ с достойными системами управления версиями, такими как Subversion и предположительно Git. Если есть проблема, вы можете вернуться к другим версиям, поэтому вам не нужно сохранять резервные копии вручную. Фактически, по крайней мере, с Subversion, если я что-то испортил или хочу взглянуть на старую версию кода, я могу сделать это, не мешая кому-либо работать.

Ответ 2

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

Некоторые преимущества контроля версий:

• Филиалы.. Вы можете создать новую ветку для каждой ошибки, с которой работаете, например, без вмешательства другого кода разработчика. Большинство систем управления версиями будут делать дешевые копии, т.е. Новый филиал будет занимать (почти) лишнее пространство.
• Версии. Вы всегда можете вернуться к старым версиям, обновить до новых версий или просмотреть журнал фиксации, чтобы узнать, что произошло в коде. Инструменты GUI, такие как TortoiseSVN, даже предоставляют утилиты diff, которые показывают вашу разницу графически. Термин "фиксация" в основном означает размещение новых версий файлов в репозитории (или добавление/удаление файлов). Системы контроля версий также поддерживают "слияние", то есть автоматически слияние изменений в файле, который был изменен несколькими людьми (часто на основе строк).
• Одновременная разработка. У нескольких разработчиков может быть своя собственная "рабочая копия" (также называемая "checkout" ). Это означает, что даже если вы не используете ветки - ваша локальная кодовая копия будет компилироваться, даже если другие в настоящее время работают над проектом (потому что у них есть собственные рабочие копии). Когда вы чувствуете, что текущий код может быть полезен другим, вы можете зафиксировать свои изменения, а другие могут обновить их копию.
• Центральное хранилище и резервное копирование. Это действует для CVS/Subversion/..., а не для GIT. Это преимущество, потому что есть центральное место для фиксации изменений и вытягивания изменений от других разработчиков.
• Распространение. Но это справедливо для GIT (а не для Subversion). Это означает, что для проекта могут быть несколько репозиториев, независимо друг от друга. Ядро Linux, например, имеет это. Люди могут "вытащить" свой собственный репозиторий, на котором они работают, - он действует как полный репозиторий, т.е. Совершается локально, а не на сервере. Если вы хотите включить патчи из репозиториев других людей (или из публичных репозиториев, таких как kernel.org), вы просто "потянете" эти изменения на свое местное репо. Если вы хотите дать кому-то еще свой патч, вы "нажимаете" свои изменения на дистанционное репо (если у вас есть права).

Надеюсь, что объяснили термины, которые вы упомянули. Я думаю, что хорошим началом для контроля версий является Subversion, используя TortoiseSVN для Windows, если это возможно. Там даже бесплатная книга об этом - Управление версиями с Subversion.

Ответ 3

Это все разные версии управления версиями:

http://en.wikipedia.org/wiki/Revision_control

Ответ 4

" Git Parable" Тома Престона-Уорнера (mojombo), одного из людей за GitHub, описывает, как система управления версиями, такие как Git, возможно, были сделаны... в то же время описывая, почему нужно и нужно (распределенная) система контроля версий.

См. также " Визуальное руководство по контролю версий" в статье "Лучшее объяснение".

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

Одиночный разработчик, единственная ветвь

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

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

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

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

• Аннотировать файл/просмотр истории. Если у вас нет идеальной памяти, иногда вам нужно знать, почему (и когда, и в случае, когда есть несколько разработчиков, и кто), вы написали заданный набор строк. Комментарии не всегда достаточно. Для этого вы можете использовать (если ваша система управления версиями предоставляет) линейные аннотации истории файлов (scm annotate или scm blame) или другие аналогичные инструменты, такие как так называемый поиск "pickaxe" в Git, где вы выполняете поиск/просмотреть историю для коммитов, которые ввели или удалили заданную строку.

  Чтобы это было полезно, вам нужно написать хорошие сообщения о совершении, описать изменение и намерение изменения, чтобы вы знали, почему было сделано изменение.

• История поиска, чтобы найти ошибки. Современные системы управления версиями предлагают альтернативные (для вставки инструкций печати или отладчика) способ поиска ошибок... в некоторых случаях. Когда вы замечаете ошибку или получаете ошибку, и ошибка не является результатом последнего изменения, вы можете использовать систему управления версиями (csm bisect), чтобы автоматически найти фиксацию, введшую ошибку (первая фиксация, которая дала ошибку), Система контроля версий находит такую ​​фиксацию, используя биссектную историю проекта, извлекая (проверяя) версии, которые вы отмечаете как хорошие (без ошибок) или плохие, пока не найдет коммиты, которые ввели ошибку.

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

Несколько ветвей

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

• Отключить релизы. Когда вы выпускаете новую версию своего проекта более широкой публике, вы хотели бы пометить (отметить) выпущенную версию. Таким образом, когда кто-то скажет вам, что версия X.Y вашего проекта имеет ошибку, вы сможете проверить эту версию и проверить, можете ли вы воспроизвести эту ошибку (и, возможно, найти ошибку через bisection, см. Выше). Это может быть полезно, даже если вы не выпускаете свой проект, если используете разные версии, развернутые в разных местах.

  Для этого теги должны быть неизменными (конечно).

• Долгоживущие ветки, Предположим, что вы выпустили свой проект, а кто-то нашел ошибку. Вы, вероятно, захотите быть ebale, чтобы поставить (освободить) исправленную версию, не останавливая работу над новыми функциями, и не отправляя версию от разработки, которая может быть нестабильной и содержать несколько других ошибок. Также вы хотите, чтобы исправление было также в версии, над которой вы работаете (если она не была установлена ​​независимо).

  Для этого вы будете использовать долгоживущие ветки: ветвь обслуживание, в которой вы будете использовать только исправления и ветвь разработка (или trunk). где вы будете делать новую работу, внедрять новые функции и т.д. Может быть больше ветвей с изменяющейся стабильностью. Например, проект Git имеет четыре таких ветки: "maint" для исправлений, "мастер" для изменений, которые достаточно стабильны; "next; для работ по развитию, а также для ветки" pu "или" предлагаемых обновлений". В других рабочих процессах у вас есть отдельная ветвь обслуживания (исправления ошибок) для каждой версии.

  Процитировать Joel Spolsky: "Сохранение стабильного и dev-кода в отдельности - это именно то, что позволяет вам контролировать исходный код".

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

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

Несколько разработчиков

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

См. также " Понимание контроля версий", работа над которым работает Эрик С. Раймонд (автор, среди прочего, "The Catedral and the Bazaar" и "Искусство программирования Unix" ) для описания различных методов, используемых системой управления версиями для совместной работы.

Ответ 5

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

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

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

Команда push применима только к системам управления распределенной версией, например git или mercurial (также известный как hg). Push позволяет перемещать изменения из одного репозитория в другой. Понятие распределенных систем управления версиями состоит в том, что каждый пользователь имеет свой собственный репозиторий. По мере того, как пользователь завершает изменения, пользователь выталкивает их в другие репозитории (возможно, центральный репозиторий проекта или как патч для другого репозитория пользователя).

Точка этих систем -

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

Ответ 6

Репозитории исходного кода.

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

Ответ 7

Взгляните на первую главу (бесплатно, онлайн) книгу подрывников. В нем описываются системы управления версиями (например, подрывная деятельность).