Я занимаюсь разработкой веб-сайта на php в localhost и, когда его модули завершаются, я загружаю его в облачное хранилище, чтобы мои друзья могли провести альфа-тестирование.

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

Итак, мой вопрос: есть ли простой способ / услуга / приложение, доступное для меня, чтобы отслеживать все изменения / изменения / новые файлы и управлять файлами при разработке веб-сайта. Как только я закончу с модулем, я хочу загрузить его в облако (я использую Amazon Cloud Service). Если что-то случится с новыми файлами, я могу вернуться к старому файлу. И, может быть, одним или двумя щелчками мыши я вижу файлы, которые я редактировал или изменял с момента последней загрузки?

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

Для начала выберите один из Mercurial, GIT или Bazaar в указанном порядке и установите его вместе с инструментами для вашей IDE и операционной системы (я предпочитаю Mercurial с HGE для Eclipse).

1. Инициализируйте репозиторий из вашего рабочего каталога ( hg init с Mercurial).
2. Решите, какие файлы и каталоги вы хотите отслеживать, а какие нет. Общее правило - не отслеживать файлы, сгенерированные компиляторами и другими инструментами.
3. Используйте команду для добавления файлов и каталогов в хранилище ( hg add для Mercurial).
4. Расскажите инструменту о шаблонах файлов, которые вы не хотите отслеживать (отредактируйте .hgignore для Mercurial).
5. Выполните коммит, чтобы отследить оригинальные версии ( hg ci ).
6. Выполняйте коммит после каждого логического этапа, даже если он маленький.
7. Добавляйте новые файлы по мере их создания.
8. Повторите последние два.
9. Резервное копирование вашего рабочего каталога и хранилища так часто, как это разумно.

С вашими файлами в хранилище вы можете узнать различия между любыми двумя версиями файла или каталога или всего проекта ( hg diff ), просмотреть историю изменений ( hg hist ) и откатить изменения ( hg up -r ).

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

Если вы хотите поэкспериментировать с другой линией разработки, сделайте это в простой ветке, клонируя основной репозиторий ( hg clone ) и не отталкивая его до тех пор, пока эксперимент не будет окончательным. Это так же просто, как иметь другой рабочий каталог для эксперимента.

Если эксперимент предназначен для новой, обновленной версии, то клонируйте, а затем разветвите ( hg branch ), чтобы вы могли сохранять все копии репозиториев обновленными, не мешая одному эксперименту взаимодействовать с другим.

Линус Торвальдс (который имеет дело с десятками тысяч файлов и миллионами строк кода в своих проектах) выступил с докладом в Google о том, почему этот инструмент не может быть CVS, SVN или каким-либо из множества бесплатных и коммерческих приложений в мире. ; это очень стоит посмотреть.

Я очень рекомендую Git. Узнайте об этом здесь: https://lab.github.com/

Если вам не нравится Git, есть другие решения для контроля версий. Вы можете проверить SVN.

Это только вы ?, используйте DVCS

Как бы нелогично это ни звучало, распределенную систему контроля версий (mercurial, git, bazaar) лучше начинать с централизованной системы (svn, cvs). Почему ?, вы устанавливаете его на свой компьютер и запускаете свой репозиторий локально, и все. В централизованной системе, такой как svn, вам нужно настроить свой клиент и сервер ... и затем вам необходимо подключиться к серверу для хранения ваших изменений.

С DVCS это вы, локальный репозиторий, и, если хотите, вы можете использовать такой сервис, как bitbucket.org или github.com.

ИМХО, mercurial - более дружественный и в равной степени способный DVCS для начала.

Есть другие? Используйте DVCS!

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

В конечном итоге вы получите что-то вроде этого, где все просто совершают специальные действия:

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

Удачи

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

Они оба отличаются. SVN проще, но Git не требует наличия сервера для запуска - вы можете контролировать версию локально.

Предполагая, что у вас Linux и вы хотите начать использовать Git:

1. Установить Git
2. Перейдите в каталог и выполните команду 'git init'
3. Узнайте, как добавлять файлы, просматривать изменения, фиксировать их ...
4. ... и делать более сложные вещи (просмотр журналов, возврат изменений, игнорирование файлов, создание веток, их объединение, создание и использование удаленных модулей, использование субмодулей, поддержка SVN и т. д.).

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

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

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

Несколько хранилищ? Я уверен, что есть некоторые законные применения для них, но я никогда не сталкивался с ними.

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

Git облегчает работу с ветвлением и слиянием. Но для команды из одного человека это не так уж важно.

Для чего-то в масштабе ядра Linux - да, используйте Git. Для остальных из нас Subversion достаточно хорош.

Я думаю, что распределенная система контроля версий преуспеет . Обычно предлагаются варианты Git и Mercurial (Hg). Графические инструменты могут быть полезны, для Mercurial я рекомендую TortoiseHg .