Як команди запобігають перезапису роботи у вихідних файлах? [зачинено]

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

Скажімо, розробник працює над іншим , Audio.cppа також розробник два працює над тим Audio.cpp, як це, як правило, у великих командах для боротьби з перезаписом? (Іншими словами, зупинити розробника два від відкриття файлу до тих пір, поки не буде завершено розробник )

Більшість команд з розробки програмного забезпечення (не тільки в розробці ігор) вирішують цю проблему за допомогою програмного забезпечення для управління версіями . Приклади є

• Підрив
• Git
• Меркуріал
• Сервер фундації Microsoft Team
• Перфорс

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

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

Розробники не використовують один і той же файл.

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

Це просте пояснення частини інакше не настільки простої концепції управління версіями .

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

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

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

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

  Звичайно, завжди буде якесь перекриття, яким треба керувати іншим чином.