Який найкращий спосіб для мене почати використовувати контроль версій у проекті з відкритими джерелами?


10

Запропонували мені взяти проект з відкритим кодом через його розмір та відсутність навичок, тому я перевірив код Google і почав робити проект, і тепер він запитує, чи хочу я, щоб проект мав Git, Mercurial або Subversion хостинг коду.

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

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

Редагувати На ці три версії хостингу коду було багато чудових відповідей, але я думаю, що мені не вдалося донести справжнє питання: В основному я не знаю, як працює цей матеріал з відкритим кодом, чому я хотів би розмістити код десь так ? І це означає, що я маю зняти сайт з мого поточного хостингу, чи це зовсім інший тип хостингу? Що відбувається, коли я роблю свій сайт відкритим кодом, які права у мене є, які права я надаю. Як це працює, чи просто люди приходять і безкоштовно кидають на мене код? Можливо, це дурні питання, і якщо це так, то я думаю, що мені потрібні дурні відповіді, я серйозно не маю уявлення, що таке відкритий код, крім концепції коду обміну ...



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

1
Це дійсно 2 питання, і обидва, ймовірно, дублікати. stackoverflow.com/questions/2303136 / ... і stackoverflow.com/questions/3859 / ...
Сільванаар

2
"Відсутність навичок" звучить як жахлива причина зробити щось відкритим. Якщо у вас чудова ідея, але вам не вистачає технічних навичок, то, можливо. Я б не пішов з відкритим кодом, поки не знайшов технічно кваліфікованого партнера, який готовий взяти на себе зобов'язання створити перший розріз коду і який хотів би піти з відкритим кодом.
tripleee

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

Відповіді:


7

чому я хотів би розмістити код десь так?

Ключовим моментом розробки програмного забезпечення з відкритим кодом є обмін вихідним кодом. Існує кілька способів зробити це, як розміщення tar / zip-файлів на веб-або ftp-сервері. Такі сервіси, як код Google (або sourceforge.net, gitorious.org, bitbucket.org та багато інших) позбавляють необхідності запускати власні сервери для цього.

І це означає, що я маю зняти сайт з мого поточного хостингу, чи це зовсім інший тип хостингу?

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

З кодом google, який ви отримуєте

  • вікі
  • клопітка
  • звичайний простір для завантаження файлів
  • сервер управління версіями

Звичайно, ви можете налаштувати це програмне забезпечення на звичайному веб-сервері (матеріали контролю версій можуть бути складними, але це залежить від деталей), але головна перевага використання хостеру розробки полягає в тому, що вам не потрібно дбати цих систем для себе. Основний недолік полягає в тому, що ви не маєте контролю над тим, яке програмне забезпечення використовується на сервері, ви повинні жити з тим, що доступно на цьому хості. Вам також потрібно врахувати, що станеться, якщо сервіс не працює (нормально, Google ніколи не виходить з ладу), і якщо ви можете перенести дані з поточного хоста на інший або власний сервер (подумайте про резервні копії).

Що відбувається, коли я роблю свій сайт відкритим кодом, які права я маю,

Це складне питання, оскільки це залежить від законодавства країни, де ви живете.

які права я віддаю.

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

Як це працює, чи просто люди приходять і безкоштовно кидають на мене код?

Це навряд чи станеться, оскільки ваш продукт потребує достатньої популярності, щоб залучити інших розробників.

[...] і тепер мене запитують, чи хочу я, щоб проект мав розміщення коду Git, Mercurial або Subversion.

Це три різні системи управління версіями, де Subversion є централізованою, а Git та Mercurial розподілені.

Існують релігійні війни, щодо яких можна скористатися, але головний - використовувати. Докладнішу інформацію див. У розділі http://martinfowler.com/bliki/VersionControlTools.html .

Коли вибрати Subversion:

  • У вас є бінарні файли, які неможливо легко з’єднати, і вам потрібен замок-> модифікувати-> здійснити-> розблокувати робочий процес, який підтримує субверсія¹
  • Потрібно перевірити лише частину структури каталогу.

¹ Існує розширення блокування для mercurial, але я не маю досвіду роботи з цим, і не можу сказати, чи він є корисним.

Коли вам не потрібні попередні функції, краще використовувати Mercurial або Git. Обидва мають наступні переваги перед Subversion:

  • швидко (а з швидким я справді маю на увазі швидкий )
  • просте розгалуження та об'єднання (це стало краще після Subversion> = 1,5, але це не те саме)
  • виконувати передачу та публікувати нерозривно, тож ви можете без особливих порушень працювати над функцією та публікувати роботу, коли вона виконана
  • вони відстежують стан каталогу продукту в цілому
  • Ви отримуєте повну копію всієї історії версій, коли клонуєте віддалений сховище
  • криптографічно захищені номери версій, це означає, що навіть коли хтось перерветься на сервері, він не може поставити код на місці, не змінюючи історію редагування

    • але оскільки ніхто не перевіряє ці зміни, ця функція практично не є ефективною

9

Хостинг коду саме такий - десь розмістити (або зберегти) ваш код.

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

Погляньте на Вікіпедію чи якусь подібну та подивіться, які саме вам подобаються. Особисто ми використовуємо Mercurial, і це працює дуже добре для нас.


6

Жоель Спольський написав чудовий підручник про Hg (Mercurial), і я вважаю, що вступний розділ охоплює Subversion, включаючи причини, чому ви переходите на Mercurial. Почитайте, що це дійсно допомогло мені зрозуміти багато про Mercurial та DVCS взагалі.

Ну, і коли ви будете готові приймати хостинг, ви можете використовувати Google Code, BitBucket , Github (за допомогою цього відмінного розширення ) або інші.


Mercurial - це відмінна система, яка перемогла мене від підриву лише за кілька хвилин використання.
Джим у Техасі

3

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

Відкритий код в основному означає, що ви даєте комусь можливість використовувати вашу роботу та будувати на ній. Ви можете встановити межі цього використання: GPL означає, що користувач повинен зробити свою додану роботу відкритим кодом, LGPL означає, що він цього не робить.


2

Субверсія була б найпростішим варіантом, оскільки це VCS. Git і Mercurial - це системи DVCS. Вони більш сучасні та потужніші, але складніші для розуміння. Використання фронтального типу, такого як TortoiseSVN або TortoiseHG (для Mercurial aka HG), також дуже допомагає.

Якщо ваше програмне забезпечення є автономною програмою, ви можете використовувати GPL або реально відкрити його з ліцензією BSD. Якщо ваш проект - бібліотека, яку хтось інший зв’яже з використанням LGPL або знову BSD; але не використовуйте GPL

[редагувати]

Що стосується вашої оригінальної мотивації для програмного забезпечення з відкритим джерелом: На жаль, просто зробити програмне забезпечення відкритим кодом не означає, що ви збираєтесь отримати приплив талановитої вільної робочої сили. Є сотні тисяч проектів з відкритим кодом. Лише невеликий відсоток з них має активних членів. Причини, які роблять ці проекти успішними чи ні, настільки ж різноманітні, як і те, чому бізнес досягає успіху та невдачі. Якщо ви хочете стати хорошим програмістом і виробляти гарне програмне забезпечення, вам доведеться витратити багато часу на навчання, написання коду та спілкування з іншими людьми на таких сайтах, як StackOverflow.


1
Чому ти кажеш, що svn найпростіший? Будь ласка, обґрунтуйте це твердження.

1
@Richard: Я думаю, що він означає, що налаштувати та використовувати для базового використання трохи простіше, принаймні, я згоден з цим прийомом. Я не згоден з думкою, що ваша бібліотека не повинна використовувати GPL, це справді політична позиція.
Хелдар

Використовуйте GPL для бібліотеки, якщо ви хочете встановити певні обмеження щодо її використання. Використовуйте LGPL, якщо хочете ввести менше обмежень.
Кіт Томпсон

0

Мені здається, що в той час як більшість людей тут відповідають на те , як ніхто, насправді ніхто не відповів чому у вашому запитанні.

Один з перших проектів з відкритим кодом, який я пережив, - це казковий проект Fractint , який був розроблений групою Stone Soup, які були натхненні старовинною народною історією з кам’яного супу .

Для мене це інкапсулює дух відкритого коду краще, ніж будь-який рент Шталмана або навіть оригінальний маніфест GNU . Це свідчить про силу цієї громади, що Fractint все ще розробляється через 23 роки після того, як пожежа була запалена під цим котлом з кодом .


0

Відкритий код означає, що кожен може читати, копіювати, змінювати та поширювати ваш код. Ви повинні мати чітке розуміння наслідків цього, перш ніж продовжувати. Можливо, вам варто прочитати книгу або принаймні переглянути статті Вікіпедії на тему та / або http://opensource.org/, поки ви не відчуєте, що розумієте це поняття.

(Книга O'Reilly з відкритими джерелами http://oreilly.com/openbook/opensources/book/index.html корисна, але, можливо, не саме те, що ви шукаєте.)

Яка система управління вихідним кодом використовувати, є повністю другорядним. Ви можете скопіювати / вставити код на веб-сторінку і зробити це. Сказавши це, важливим є контроль версій, а розробники зможуть знизити планку. Будь-який із варіантів, запропонованих Google Code, чудово; займіться тим, хто вам подобається, або, можливо, відкладіть це питання, поки ви не зможете запитати своїх дописувачів, який би вони хотіли використовувати.


0

Здійснення коду чи проекту з відкритим кодом означає, що кожен може прийняти його та змінити так, як він хоче. Це залежить від того, який тип ліцензії ви вирішите використовувати, але загалом відкритий код означає, що вихідний код доступний кожному, щоб завантажити його, змінити та використовувати за своїм бажанням.

У будь-якому випадку цей код повинен бути доступний іншим людям, щоб отримати його.

Перенесення коду до загальнодоступного онлайн-сховища, наприклад, GitHub - найкращий спосіб зробити це. По-перше, ваш код тепер доступний для громадськості. Потім, оскільки такі сервіси також пропонують контроль версій, ваш код організовується за проектом. Ви можете відслідковувати зміни, які ви та інші люди вносите. Оскільки він також дозволяє розгалужувати (відокремлювати) проект на інші проекти, ви можете відслідковувати всі різні версії інших користувачів, зроблені з вашого коду.

Це також гарантує збереження вашого коду в безпечному місці, вам не доведеться турбуватися про втрату, наприклад, несправного жорсткого диска на вашому ПК. І коли ви хочете працювати над ним, ви можете працювати з будь-якого місця, оскільки ваш код в Інтернеті, його можна знайти в будь-якому місці.

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

Це як загальний стандарт ведення справ, звичайна практика.

Деякі посилання, які можуть бути корисними для подальшого пояснення відкритого коду:


-6

Щодо системи контролю версій, я б сказав, що вам слід дотримуватися найбільш вживаної та найновішої альтернативи: Це: "Git". Меркуріал менш популярний, а SVN - старий, повільний і централізований. Завдяки GIT ви скористаєтесь сучасною та популярною системою контролю версій. Практично нічого втрачати.

Джерела (реєструючи популярність DVCS):

/programming/tagged/git ~ 10k питань /programming/tagged/mercurial ~ 3k питання

http://www.googlefight.com/index.php?lang=en_GB&word1=git&word2=mercurial

11700000 результатів проти

1580000 результатів

Щодо ліцензії: Можливо, вам слід переглянути найпоширеніші з них: GLP, MIT, LGPL, BSD та вибрати ту, яка краще відповідає вашому проекту.


7
Mercurial не є власником ... це відкритий код точно так само, як Git!
Крістіан Шпехт

4
Фанбой відповідь частково неправильними аргументами.
Обен Сонне

1
"найбільш використовувані" - будь ласка, вкажіть посилання на своє джерело цієї інформації.
sylvanaar

Вибачте людей .. Це лише моє сприйняття речей: я здогадуюсь, що Git більше використовується, ніж Mercurial, і я знаю, що SVN старий, повільний і централізований ... Цікаво, чи ваші коментарі менш фан-коментарі, ніж моя т.зв. фан-відповідь. Давай, git hub використовує git, Linux ядро ​​використовує git, кожен проект у моєму відділі використовує git ...
Педро Роло

2
Можливо, велика кількість питань щодо Git також свідчить про те, що це складніше використовувати? Кілька людей використовували подібні дані, досліджуючи, які рамки веб-розробки були найбільш "популярними", де піднімалися ті ж самі питання (коментуючи неточності).
Тим Пост
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.