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

Поки я постійно розвиваюся, у мене багато файлів, і я втрачаю інформацію про те, який файл я редагував чи змінював і т. Д. Я чув щось таке, як "контроль версій" для управління всіма цими, але не впевнений, як це працює.

Отже, моє запитання: чи доступний мені простий спосіб / послуга / додаток для відстеження всіх редагувань / змін / нових файлів та управління файлами під час розробки веб-сайту. Як тільки я закінчу з модулем, я хочу завантажити його в хмару (я використовую Amazon Cloud Service). Якщо з новими файлами щось трапиться, я, можливо, захочу повернутися до старого файлу. І, можливо, за клік-два я побачу файли, які я редагував чи змінював після останнього завантаженого?

Управління конфігурацією програмного забезпечення , до складу якого входить версія Control , є дещо складнішим, ніж відстеження змін у файлах, хоча ви, звичайно, можете почати з цього. Але читайте статті, пов’язані вище у Вікіпедії, разом із підручником Джоела Сполкі про Меркуріал .

Для початку виберіть один із 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 розл. ), Переглянути історію змін ( hg hist ) та відкатати зміни ( hg up -r ).

Добре заздалегідь позначити ( hg тег ) сховище перед публікацією коду, тому існує простий спосіб повернутися до того, що ви опублікували для поправок чи порівнянь.

Якщо ви хочете поекспериментувати з іншою лінією розвитку, зробіть це в простій гілці, клонувавши основне сховище ( hg клон ) і не відштовхуючись, поки експеримент не буде остаточним. Це так само просто, як мати інший робочий каталог для експерименту.

Якщо експеримент призначений для нової, оновленої версії, то клонуйте, а потім розгалужуйте ( hg гілку ), щоб ви могли постійно оновлювати всі копії сховищ без того, щоб один експеримент заважав іншому.

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

Я б дуже рекомендував Git. Дізнайтеся про це тут: https://lab.github.com/

Якщо вам не подобається Git, є й інші рішення контролю версій. Ви можете перевірити SVN.

Це тільки ви ?, використовуйте DVCS

Як не інтуїтивно зрозуміло, дистрибутивована система управління версіями (mercurial, git, базар) краще починати з централізованої системи (svn, cvs). Чому ?, Ви встановлюєте його на свою машину і запускаєте своє сховище локально, і все. У такій централізованій системі, як svn, вам потрібно налаштувати клієнта та сервера ... а потім вам потрібно підключитися до сервера, щоб зберігати свої зміни.

За допомогою DVCS - це ви, локальний сховище, і якщо хочете, ви можете скористатися службою, на зразок bitbucket.org або github.com.

IMHO, mercurial - це дружніший і настільки ж здатний DVCS для початку.

Є інші ?, використовуйте DVCS!

При використанні DVCS для роботи з командою є численні переваги , найважливішим на відміну від централізованої системи є те, що немає перегонів на фіксацію, і це тому, що, технічно, сховище кожного користувача є філією, і коли ви ділитесь своїми зміни цих гілок об’єднуються для вас, і ви навіть не помічаєте, це означає, що замість такої історії версій, де у вас є люди, які направляють свою роботу на пряму:

У вас з’являється щось подібне, коли всі просто здійснюють спеціальні дії:

Кожен просто переживає за свою власну роботу під час версій (тобто не бігаючи на фіксацію) та не переживаючи про підключення до сервера просто для здійснення.

Удачі

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

Вони обидва відрізняються. SVN простіший, але Git не вимагає від вас сервера для початку - ви можете керувати версією локально.

Припустимо, що у вас є Linux і хочете почати використовувати Git:

1. Встановити Git
2. Перейдіть до каталогу та виконайте команду 'git init'
3. Дізнайтеся, як додати файли, перегляньте зміни, введіть їх ...
4. ... і робити більш досконалі речі (перегляд журналів, відновлення змін, ігнорування файлів, створення гілок, об'єднання їх, створення та використання віддалених програм, використання підмодулів, використання підтримки SVN тощо).

Сподіваюся, це допоможе вам почати.

Як підказує Апалала, я рекомендую замовити hginit . Оскільки ви новачок у контролі версій, ви можете пропустити першу сторінку. Це повинно дати вам гарне інтро, після чого ви можете розмістити на SO , якщо у вас є конкретні питання.

Я буду суперечити думці більшості і рекомендую Subversion. Subversion проста у використанні, і це все, що потрібно людям та невеликим командам. Це зрілий продукт, тому кожен ІДЕ там має гарну підтримку. Так, він не має всіх особливостей Git. (Я ніколи не використовував Mercurial, тому не говорю про це.) Але більшості розробників насправді не потрібні додаткові функції.

Кілька сховищ? Я впевнений, що для них є законне використання, але я ніколи не стикався з ними.

Можливість приймати місцеві послуги без доступу до мережі? Це приємно: якщо вам трапляються кілька дискретних змін, і ви не можете отримати доступ до сервера сховища - але, чесно кажучи, як часто це відбувається?

Git полегшує справу з розгалуженням і злиттям. Але для одноосібної команди це не така вже й велика справа.

Щось у масштабі ядра Linux - так, використовуйте Git. Для решти нас Subversion є досить хорошою.

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