Что такое Git и Subversion?
Надеюсь, вы найдете это полезным.
HTML:
<html>
<head>
<link rel = "stylesheet" href = "test.css">
<body>
</body>
<script src = "test.js"></script>
</head>
</html>
JAVASCRIPT:
var tableString = "<table>",
body = document.getElementsByTagName('body')[0],
div = document.createElement('div');
for (row = 1; row < 101; row += 1) {
tableString += "<tr>";
for (col = 1; col < 11; col += 1) {
tableString += "<td>" + "row [" + row + "]" + "col [" + col + "]" + "</td>";
}
tableString += "</tr>";
}
tableString += "</table>";
div.innerHTML = tableString;
body.appendChild(div);
7 ответов
Контроль версий (также известный как контроль версий).
Рассмотрим следующую задачу. Вы работаете над проектом с кем-то другим и делитесь файлами. Вам обоим нужно поработать, скажем, над «WhateverController.java». Это огромный файл, и вам обоим нужно его отредактировать.
Самый примитивный способ справиться с этим - не редактировать файл одновременно, но тогда вы оба должны находиться на одной странице. Когда у вас есть команда, особенно если в нее входят десятки, сотни или тысячи (типично для проектов с открытым исходным кодом), это становится совершенно невозможным.
Старым примитивным «решением» этой проблемы было создание механизма проверки / регистрации. Когда вам нужно отредактировать файл, вы «проверяете его», и файл блокируется, чтобы никто другой не мог его редактировать, пока вы не разблокируете его, «проверив». Это делается с помощью соответствующего программного обеспечения, например невероятно глупой хрени от Microsoft SourceSafe. Но когда люди забывают «зарегистрировать файл», никто другой не может редактировать этот файл, пока он используется. Затем кто-то уходит в отпуск или покидает проект по какой-то другой причине, и в результате возникает бесконечный хаос, путаница и, как правило, довольно много потерянного кода. Это добавляет колоссальной управленческой работы.
Затем пришла CVS, а затем Subversion, которую авторы называют «CVS сделано правильно», так что 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) и подобные, обычно показывают вам оба файла и конфликты, поэтому вы можете выбрать, какие строки вы хотите сохранить, а какие выбросить ... а затем вы также можете редактировать файл вручную, если вы хотите вручную слить конфликт.
Таким образом, по сути, контроль версий - это решение проблемы, когда несколько человек работают над одними и теми же файлами. Вот и все.
Надеюсь, это объясняет.
РЕДАКТИРОВАТЬ: Есть много других преимуществ с хорошими системами управления версиями, такими как Subversion и, предположительно, Git. Если есть проблема, вы можете вернуться к другим версиям, чтобы не создавать резервные копии всего вручную. Фактически, по крайней мере, с Subversion, если я что-то напутаю или хочу взглянуть на старую версию кода, я могу сделать это, не мешая чьей-либо работе.
Git и Subversion (также известные как svn) являются системами контроля версий, версий или версий. Они помогают управлять исходным кодом и отслеживать историю изменений каждого файла, управляемого системой. Ссылки на статьи в Википедии о метизме могут быть полезны.
github - это служба для размещения и управления репозиториями git. По сути, он помещает репозиторий в оперативный режим, чтобы несколько человек могли легко взаимодействовать с репозиторием.
Команда фиксации обычно сохраняет набор изменений в репозитории системы управления версиями. Это создает новую ревизию в репозитории.
Команда push применяется только к распределенным системам контроля версий, таким как git или mercurial (также известные как hg). Push позволяет перемещать изменения из одного репозитория в другой. Идея распределенных систем контроля версий заключается в том, что у каждого пользователя есть собственное хранилище. Когда пользователь завершает изменения, он отправляет их в другие репозитории (возможно, в центральный репозиторий проекта или в качестве патча для репозитория другого пользователя).
Смысл этих систем состоит в том, чтобы
- хранить историю процесса разработки
- улучшить сотрудничество между несколькими разработчиками
- позволить восстанавливать старые версии кода и исправлять
- связывать изменения исходного кода с конкретными функции или ошибки (см. fogbugz и kiln)
- создают варианты кода (ветки) для экспериментов или параллельной разработки
Взгляните на первую главу книги (бесплатно, онлайн) подрывной деятельности . Он описывает, что такое системы контроля версий (например, Subversion).
GIT, Subversion и им подобные - это все о контроле версий. Если вы используете такие технологии для проекта, все ваши исходные файлы хранятся в так называемом репозитории (он же "repo") - за исключением файлов, которые не нуждаются в версионировании (большие файлы, файлы, специфичные для пользователя, ...).
Некоторые преимущества контроля версий:
- Ветви. Вы можете создать новую ветку для каждой ошибки, над которой вы работаете, например, не вмешиваясь в код других разработчиков. Большинство систем контроля версий делают дешевые копии, т.е. новая ветвь не занимает (почти) никакого дополнительного места.
- Версионность. Вы всегда можете вернуться к старым версиям, обновить их до новых или посмотреть журнал фиксации, чтобы увидеть, что произошло с кодом. GUI-инструменты, такие как TortoiseSVN, даже предоставляют утилиты diff, которые показывают разницу графически. Термин "фиксация" в основном означает размещение новых версий файлов в хранилище (или добавление/удаление файлов). Системы контроля версий также поддерживают "слияние", то есть автоматическое объединение изменений в файле, который был изменен несколькими людьми (часто на основе строк).
- Одновременная разработка. Несколько разработчиков могут иметь свою собственную "рабочую копию" (также называемую "checkout"). Это означает, что - даже если вы не используете ветвления - ваша локальная копия кода будет компилироваться, даже если в данный момент над проектом работают другие (потому что у них есть собственные рабочие копии). Когда вы почувствуете, что текущий код может быть полезен другим, вы можете зафиксировать свои изменения, а другие смогут обновить свою копию.
- Центральное хранилище и резервное копирование. Это относится к CVS/Subversion/..., а не к GIT. Это преимущество, потому что есть центральное место для фиксации изменений и для получения изменений от других разработчиков.
- Распространение. Но это справедливо для GIT (не для Subversion). Это означает, что для проекта может существовать несколько репозиториев, независимых друг от друга. В ядре Linux, например, это есть. Люди могут "тянуть" вниз свой собственный репозиторий, над которым они работают - он действует как полноценный репозиторий, т.е. коммиты делаются локально, а не на сервер. Если вы хотите включить исправления из чужих репозиториев (или из публичных репозиториев, таких как kernel.org), вы просто "стягиваете" эти изменения в свой локальный репозиторий. Если вы хотите передать кому-то другому свой патч, вы "проталкиваете" свои изменения в удаленный репозиторий (если у вас есть права).
Надеюсь, это объяснило упомянутые вами термины. Я думаю, что хорошим началом для работы с контролем версий является Subversion, используя TortoiseSVN для Windows, если это возможно. Есть даже бесплатная книга об этом - Version Control with Subversion.
Вы печатаете неподписанное значение как подписанное? При дополнении двумя значение с самым значительным битовым набором будет напечатано как отрицательное. Попробуйте% u для неподписанных
-121--4577915-% ld или% lu в зависимости от требуемой длины.
-121--4577916-Репозитории исходного кода.
В основном способ обмена кодом между командой, с возможностью видеть, кто "совершил" (добавлен) какой код в то время, и кто изменил что в то время и т.д.
"The Git Parable" Тома Престона-Уорнера (mojombo), одного из тех, кто стоит за GitHub, описывает, как система контроля версий, такая как Git, могла быть создана... в то же время описывая, почему человек хочет и нуждается в (распределенной) системе контроля версий.
См. также статью "A Visual Guide to Version Control" на Better Explained.
Существует множество преимуществ использования системы контроля версий. Перечислим их примерно в порядке возрастания сложности: увеличение числа разработчиков, увеличение размера проекта / размера истории проекта, более сложные рабочие процессы и т.д.
Один разработчик, одна ветка
Даже если вы единственный (единственный) разработчик вашего проекта, и (по крайней мере, пока) вы не планируете его менять, система контроля версий все равно полезна. Она позволяет:
Вернуться к некоторой рабочей версии. Если вы работаете над своим проектом и понимаете, что полностью облажались, подход, который вы пробовали, не работает, и вы не знаете, как заставить его работать, приятно иметь возможность просто вернуться к последней рабочей версии и начать все заново.
Это означает, что вы должны фиксировать, т.е. делать снимок своих изменений, когда у вас есть рабочая версия (ну, есть исключения, см. ниже). Чтобы не потерять много работы, вы должны фиксировать изменения довольно часто, лучше всего (см. ниже), когда вы завершили одну функцию, один вопрос, или одну часть функции или вопроса.
Вы также хотите знать, что вы сделали, и над чем вы работали в последнее время. Это означает, что вы должны описать каждый набор изменений (каждый коммит).
Аннотировать файл / просматривать историю. Если у вас не идеальная память, иногда вы захотите узнать, почему (и когда, а в случае, когда разработчиков несколько, еще и кто) вы написали данный набор строк. Комментарии не всегда достаточны. Для этого вы можете использовать (если ваша система контроля версий предоставляет такую возможность) построчные аннотации истории файлов (
scm annotateилиscm blame), или другие подобные инструменты, например, так называемый "pickaxe" поиск в Git, где вы ищете/просматриваете историю коммитов, которые ввели или удалили заданную строку.Чтобы это было полезно, вам нужно писать хорошие сообщения о коммите, описывающие изменение и намерение изменения, чтобы вы знали, почему было сделано изменение.
Биссектриса истории для поиска ошибок. Современные системы контроля версий предлагают альтернативный (по сравнению со вставкой операторов печати или отладчиком) способ поиска ошибок... по крайней мере, в некоторых случаях. Когда вы замечаете ошибку или получаете сообщение об ошибке, и ошибка не является результатом последнего изменения, вы можете использовать систему контроля версий (
csm bisect) для автоматического поиска коммита, в котором появилась ошибка (первый коммит, в котором появилась ошибка). Система контроля версий находит такой коммит, используя биссекцию по истории проекта, извлекая (проверяя) версии, которые вы отметили как хорошие (без ошибки) или плохие, пока не найдёт коммит, который ввёл ошибку.Для этого вы всегда должны убедиться, что версия работает (или хотя бы компилируется) перед коммитом, иначе вы не сможете определить, есть ли в коммите ошибка или нет. Вы должны сохранять коммиты небольшими (с небольшим количеством изменений), так что когда вы найдёте коммит, который внёс ошибку, вам придётся проверить только небольшое количество строк, затронутых изменением. Вам также нужны хорошие сообщения о фиксации, чтобы вы знали, почему было сделано изменение (и могли решить, правильно ли оно или нет).
Множественные ветви
Позже вам понадобится еще одна особенность системы контроля версий: возможность параллельно работать над разными линиями разработки (flavors) вашего проекта, так называемыми ветвями. Это включает, но не ограничивается:
Taging releases. Когда вы выпускаете новую версию вашего проекта для широкой публики, вы хотите пометить (маркировать) выпущенную версию. Таким образом, когда кто-то скажет вам, что версия X.Y вашего проекта содержит ошибку, вы сможете проверить эту версию и проверить, можете ли вы воспроизвести эту ошибку (и, возможно, найти ошибку с помощью бисекции, см. выше). Это может быть полезно, даже если вы не выпускаете свой проект, если вы используете, возможно, разные версии, развернутые в разных местах.
Для этого теги должны быть неизменяемыми (разумеется).
Long-lived branches. Предположим, что вы выпустили свой проект, и кто-то нашел ошибку. Вы, вероятно, хотели бы иметь возможность выложить (выпустить) исправленную версию, не останавливая работу над новыми возможностями, и не отправляя версию из разработки, которая может быть нестабильной и содержать множество других ошибок. Также вы бы хотели, чтобы исправление было и в версии, над которой вы работаете (если оно не было исправлено самостоятельно).
Для этого вы должны использовать долгоживущие ветки: maintenance ветвь, где вы будете писать только исправления, и development ветвь (или trunk), где вы будете делать новую работу, внедрять новые возможности и т.д. Ветвей с различной стабильностью может быть больше. Например, проект Git имеет четыре таких ветви: 'maint' для исправлений, 'master' для изменений, которые достаточно стабильны, 'next; для разработки, и 'pu' или ветка "предлагаемые обновления". В других рабочих процессах у вас есть отдельная ветка сопровождения (исправлений) для каждого релиза.
Цитируя Джоэла Спольски: "Разделение стабильного и рабочего кода - это именно то, что контроль исходного кода должен позволить вам делать."
Тематические (функциональные) ветки. Когда вы хотите работать над несколькими проблемами параллельно, где каждая функция требует нескольких коммитов для завершения, вы, вероятно, захотите разрабатывать каждую функцию (каждую тему) в отдельной ветке. Таким образом, вы сможете переключаться с работы над одной функцией на работу над другой функцией (над другой темой).
Этот рабочий процесс особенно важен, если вы работаете с несколькими разработчиками, см. ниже.
Несколько разработчиков
Одной из самых важных особенностей системы контроля версий является возможность сотрудничества между различными разработчиками, позволяющая нескольким людям работать над одним проектом, не затаптывая изменения друг друга. Эта возможность хорошо описана в других ответах, поэтому я не буду останавливаться на ней подробно.
См. также "Понимание контроля версий", незавершенную работу Эрика С. Реймонда (автора, среди прочего, "The Catedral and the Bazaar" и "The Art of Unix Programming") для описания различных методов, которые системы контроля версий используют для обеспечения совместной работы.