Як професійні розробники додатків використовують системи управління версіями, як-от GIT та Subversion?


10

Я початківець розробник, і мені було цікаво з самого початку, як професійні інструменти, такі як GIT та Subversion (я не дуже добре розумію ці інструменти), щоб задовольнити потреби свого проекту. Якщо вони все-таки користуються ним, як би я створив щось подібне?

Мої заявки не такі великі, і я ще не працюю в команді, вони могли б мені допомогти?

На цьому сайті є питання про те, як користуватися інструментами, але мені потрібна підтримка для початківців.


5
Git і Subversion поставляються з інструкціями; вони в основному є сховищем, яке зберігає код розробки структуровано. Окремі розробники виграють від повного запису змін коду та надійного резервного копіювання. Команди проектів користуються можливістю спільного використання одного сховища вихідного коду, зберігаючи зміни синхронізації між робочими станціями.
Роберт Харві

Відповіді:


13

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

Однак, робочі процеси, навіть у такій системі управління джерелами, як Subversion або Git, сильно відрізняються від команди до команди. Найкраще почати - це, мабуть, вибрати систему управління джерелом та ознайомитись із її стандартними робочими процесами (маючи на увазі, що вам доведеться перемикати робочі процеси протягом усього свого професійного життя).

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

Ось хороший огляд деяких хороших правил керування джерелами загалом: http://scottonwriting.net/sowblog/archive/2008/11/13/163320.aspx

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


1
Хороша відповідь, окрім одного пункту. Я б точно не вибрав підривний сервер, оскільки це найбільший недолік, почасти тому, що я його фактично використовую без одного досить часто; сховище може жити в локальному каталозі, і ніж налаштування - це одна команда. Основна відмінність між Git і Subversion полягає в тому, що розподілені системи типу Git набагато гнучкіші, ніж централізовані, такі як Subversion.
Ян Худек

5

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

Як тільки ви працюєте з іншими людьми в команді, вигоди ще більше збільшуються, оскільки кілька людей можуть змінювати один і той же файл, і якщо зміни не конфліктують (наприклад, 2 людини змінюють різні розділи файлу), зміни будуть об'єднані. автоматично. Якщо є якісь конфлікти, ви зможете побачити свої зміни поруч із колегами та обговорити з ними, як об’єднати зміни.

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

Ось кілька корисних ресурсів:

Підготовка та запуск програми Subversion і Tortoise SVN за допомогою Visual Studio та .NET

Управління версіями із підривом


1
Не даючи +1, тому що вивчення Subversion як першої системи є на зразок контрапродуктивним в ці дні, коли всі переходять на розподілені системи.
Ян Худек

3

Підручники для початківців

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

SVN

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

Професійний контроль над джерелами відповідає професійним потребам

Ваше запитання "Як професійні інструменти використання, такі як GIT та Subversion, щоб задовольнити потреби свого проекту?" тісно пов'язане з питанням "Як працюють команди разом, не ставлячись один до одного, поки все ще працюють якомога швидше?"

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

Об’єднання речей, об'єднання роботи багатьох членів команди - справа, яка в SVN та старих системах була централізованою і складною. Для команд, які використовують Git, злиття стає простішим та доступнішим для впливу всієї команди замість кількох експертів. У SVN розгалуження може бути особистою справою, але об'єднання часто мало болісний вплив на команду, і переміщення коду назад в основну лінію може бути болісним з точки зору отримання дозволу, уникнення поломки та рівня зусиль, необхідних для виконання завдання .

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

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


0

Моя команда використовує домашню систему управління версіями команд. (На жаль, Git, здається, ще не працює над IBM i "рідними" вихідними файлами) Але особисто, як тільки я витягнув джерело з цієї системи, я використовую Git під час моєї розробки, поки проект не буде виконаний, і я перевіряю його знову в команда VCS.

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

Git покращив спосіб підходу до розвитку.


'Git, здається, ще не працює в IBM i "рідних" вихідних файлах) "- Git повинен працювати над будь-яким файлом. У чому тут питання?
Marnen Laibow-Koser

@ MarnenLaibow-Koser Більшість розробників IBM i працюють з вихідними файлами з тим, що ми можемо назвати рідною (застарілою) файловою системою QSYS, де вихідні файли мають вбудований формат фіксованої довжини. Кожен рядок починається з шестизначного порядкового номера, шестизначної дати зміни, а потім рядка тексту тексту вихідного коду. Послідовність і дата зміни можуть змінюватися, навіть якщо вихідний код у рядку не змінився. Рішення, можливо, були розроблені останнім часом. IBM та інші тепер підтримують git на IBM i. І це не повинно бути проблемою з джерелом у "нормальних" потокових файлах в інших файлових системах IFS в IBM i.
WarrenT

О Боже, я смутно пам'ятаю це від розвитку AS / 400 розвитку 20 років тому. Але немає жодної причини, я думаю, що Git не працюватиме з такими файлами. Можливо, вам доведеться написати драйвер злиття, який знижує номери рядків, але це зробити просто. (Цікаво, чи це зробив IBM ...)
Marnen Laibow-Koser

Але якщо ви знімете номери рядків та дату зміни рядка, ви втратили їх, перевіривши щось із Git. Нелегко переконати деяких людей, що вони більше не потребують цих дат, покладаючись на них, можливо, 3 десятиліття. Так, я знаю, що звинувачення в Git - це те саме, але люди неохоче відмовляються від того, від чого так довго залежали, навіть якщо це не обов'язково є логічним аргументом.
WarrenT

Насправді ви можете зробити фільтр Git clean / mrd для відновлення дати з вини Git. :)
Marnen Laibow-Koser
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.