881
Десять років Git: Інтерв'ю з Креатором Linus Torvalds
Цей тиждень буде відмічати десять років, оскільки розробники ядра Linux зіткнулися з перешкодою: вони більше не могли використовувати їх систему керування версією BitKeeper і не інші вимоги до регулювання коду джерела, що відповідають вимогам ресурсу. Лінус Торвальдс, творець Linux, прийняв виклик і зникнув у вихідні дні на наступний тиждень, щоб з'явитися з Git. Сьогодні Git використовується в тисяч проектах, і Git підштовхує програмування в командах розробки до нового рівня.
Щоб відмітити цю дату, ми попросили Лінуса поділитися прихованою історією Git, розкажіть, що він думає про проект і його вплив на розробку програмного забезпечення. Ви знайдете свої коментарі нижче в тексті. Цей інтерв'ю буде слідувати Git Week, в якому ми розглянемо індивідуальні проекти з використанням цієї системи керування версія щодня. Розвиваючі історії розвитку від KVM, Qt, Drupal, Puppet, Wine та багато іншого.
Чому ви створили Git?
Торвальдс: Я ніколи не хотів зробити версію системи управління (VCS) і відчував це лише найменше цікавого в комп'ютерному світі (за винятком баз даних), і я захоплю всі такі системи пристрасно. Але після того, як BitKiper (BK) пішов і дійсно змінив спосіб, який я переглядав вихідний код управління. BK зробив багато речей прямо. І змогла зберегти локальну репозиторійну копію та розподільну кодову злитку. Важлива особливість моделі розподіленого контролю версій полягає в тому, що він усуває одне з найсерйозніших проблем СКЛ: політика хто може внести зміни. BK показує, що ви можете уникнути цього просто, даючи кожному репозиторію. Але BK мав свої проблеми; кілька технічних рішень призвели до проблем (погано, але найгірше було те, що оскільки BK не був розподілений з відкритим вихідним джерелом, було багато людей, які не хочуть його використовувати. Таким чином, ми закінчилися кількома основними розробниками з використанням BK, які були вільні у використанні у відкритих вихідних проектах, але він ніколи не став основним Так що допомогло розвивати ядро, але ще було заспокійливих моментів.
Це сталося мені, коли Tridge (Andrew Tridgell) почав реверсувати досить простий протокол BK, який був порушенням правил BK. Я провів кілька тижнів (місячних)? Ось як я відчув, намагаючись медіатети між Tridge і Larry McVoy, але це стало зрозуміло, що це просто не працює. Я не можу зберегти використання BK, але я не хочу повернутися до найгірших днів до BK. На жаль, було інші інструменти SLE, які намагалися використовувати розподілену модель розвитку в певній мірі, але жоден з них добре працював у віддаленому використанні. Я володів власними експлуатаційними вимогами, які не могли навіть приблизно, що було доступно, і я був також стурбований цілісністю коду і процесом розробки, тому я вирішив писати шахту.
Як ви підходите? Ви пишете всі вихідні або просто в звичайному режимі?
Торвальдс: Е. Ви можете бачити, до речі, як все відбулося в репозиторію коду Git, крім першого дня або щось. Цей день був проведений на хостинг Git, щоб ви могли запустити комітацію Git за допомогою Git. Так, перший день або щось не в історії, але все інше тут. Основна робота виконана в основному протягом дня, але є пара нічних записів і пара після двох ранку. Найцікавіше, як швидко вона взяла форму. Найперший коміт у Git Tree не бувало коду, але він зробив основне - достатньо, щоб зробити себе. З’ясуйте, як Git повинен організувати дані.
Я хотів би підкреслити, що навіть якщо він був зібраний протягом десяти днів або щось, як це (при те, що я зробив мій перший Git Commite до репозиторію ядра Linux), це не так вже божевільний кодування. Обсяг цього ранного коду досить невеликий, все залежить від правильної реалізації базових ідей. І так я зробив шліфування перед усім проектом. Я бачив інші проблеми людей. Я бачив, що я хотів уникнути.
Чи вирощується на рівень ваших очікувань? Як правильно працювати за оцінками? Чи існують будь-які обмеження?
Торвальдс: Я дуже щасливий з Git. Працює виключно з кодом ядер і все ще слідує моїм очікуванням. Цікаво, що він бере на себе багато інших проектів. Зрозуміло швидко, після всього. Існує багато інерції в переході від одного SLE до іншого; просто подивіться на те, як довгі CVS і навіть RCS були у використанні, але в певній точці Git також забрав свої справи.
Чому ви думаєте, що це (Git) було так прийнято?
Торвальдс: Я думаю, що багато людей були обурені тими ж питаннями, які змусили мене покатати SLE. І тоді було багато проектів у зусиллях зафіксувати одну або дві дрібні проблеми, які отримали людей божевільні, було дійсно нічого подібного, що дійсно допомогли зберегти великі проблеми з головою. Навіть коли люди не розуміли, як важлива модель розподіленого розвитку (і багато людей, які борлися з ним), як тільки вони зрозуміли, що це дозволило полегшити і надійні резервні копії і дозволило людям зробити власні репозиторії без того, щоб думати про політику, що дозволяє записувати на конкретну репозиторію, вони ніколи не виглядали назад.
Чи завжди існують, або ви очікуєте відкликання SLE протягом наступних десяти років? Ви будете мати один з тих, хто пише це?
Торвальдс: Ні, я не буду той, хто пише його. І, можливо, ми побачимо щось нове в десять років, але я гадаю, що це буде щось схоже. Не в сенсі, що Git є правою, але в сенсі, що Git має основні можливості прямо всередині, що інші SLE ніколи не були раніше.
без помилкової скромності;
Чому Git працює так добре в Linux?
Торвальдс: На нашу роботу, тому він його частина. Я згадував розподілену модель багато разів, але це робить сенс думати про це знову. Але Git також був розроблений для того, щоб бути ефективним для великого проекту, як Linux, і написаний для того, щоб зробити те, що люди вважалися проблемою до Зійшла, бо ті, що я роблю щодня.
Просто подаруйте вам приклад: поняття фузії було видно як щось дуже болюче і складне в багатьох SLEs. Ви повинні планувати злиття, оскільки вони були серйозними. Це не турбувати мене, як я зазвичай робимо десятки об'єднувачів в день, коли я в часовому вікні злиття, і навіть так, робоче навантаження не повинно бути в об'єднанні, але в тестуванні коду. Сам об'єднувач займає пару секунд, набагато більше, ніж написання пояснення об'єднання.
Так Git був побудований і письмовий для моїх вимог. Що відбувається.
Люди сказали, що Git був просто для супер розумних людей. Андрій Мортон колись сказав: «Гіт призначений для того, щоб ви відчували себе навіть у дванадцятипалях, ніж раніше». Яка відповідь на це?
Торвальдс: Ну, я думаю, що це було спочатку, але це не більше. Ось кілька причин, чому люди відчувають себе таким чином, але я думаю, що є тільки одна причина зліва. Що залишилося дуже просто: «Це можна зробити так багато способів. й
Ви можете зробити багато речей з Git, і багато правил про те, що ви повинні зробити не приходять з технічних обмежень, але з того, що він добре працює, коли ви повинні взаємодіяти з іншими людьми. Git є дуже потужним інструментарієм, який може перевантажуватися спочатку, але це також означає, що ви можете часто ті самі або подібні речі різними способами і вони всі роботи. В цілому, найкращий спосіб дізнатися Git, ймовірно, просто робити прості речі і навіть шукати інші речі, поки ви не впевнені про основи.
Є кілька історичних причин для перегляду Git як складної речі. Одним з них є те, що це було дуже важко. Ті люди, які почали використовувати Git, перш ніж хтось інший, щоб працювати з ядром Linux, дійсно довелося дізнатися, як використовувати досить складний набір сценаріїв, щоб зробити все роботи. Всі зусилля були зроблені, щоб зробити основну технологію роботи, і дуже мало, щоб зробити це легко або зрозуміло. Яким чином ви робилися, Але це було переважно вірним тільки за перші шість місяців або рік.
Ще одна причина думки Ускладнено Git, що Git дуже своєрідний. Є люди, які використовували речі, такі як CVS за десятиріччя або два, і Git не CVS. Ні. Різні поняття. Команди відрізняються. Git ніколи не намагався виглядати як CVS, так і навпаки. І якщо ви використовуєте CVS-подібну систему протягом тривалого часу, ви отримаєте враження від складності Git і неприпустимої різниці. Люди відштовхували дивну версію системи. Чому Git номер версії "1.3.1" і не так красиво зроблено з збільшенням кількості в версіях CVS? Чому виникає дивний і страшний номер 40-character в шістнадцятковій системі?
Але Git не був Ці відмінності були необхідні. Ми можемо самі зателефонувати одержувачу і узгодити зручний час і місце вручення квітів, а якщо необхідно, то збережемо сюрприз. Відбувається фон CVS. Ми можемо самі зателефонувати одержувачу і узгодити зручний час і місце вручення квітів, а якщо необхідно, то збережемо сюрприз.
Чи може виростити розвиток ядра Linux за поточною швидкістю без Git? Чому?
Торвальдс: Ну, без git, звичайно. Але що б залучити кого-небудь пишу деякі еквівалентні Git: деякі розподілені SLE, які будуть як ефективні як Git. Ми обов'язково зробимо щось схоже на Git.
Що ви думаєте про GitHub?
Торвальдс: Github є винятковим ресурсом хостингу, я нічого не проти нього. Скарги, які я мав, що GitHub як платформа розвитку - комітує, Pull Запити, відстеження історії проблем і так далі - не було достатньо. Не близький, не схожий на те, що ядро Linux. Це занадто обмежений.
Це частково через те, як працює ядро Linux, але частково тому, що інтерфейси GitHub активно заохочують погану поведінку. GitHub містить коментарі з цих комітів і так далі, просто тому що веб-інтерфейс на GitHub активно заохочував погану поведінку. Вони фіксують деякі речі, тому це, ймовірно, працює краще, але це ніколи не буде підходить для чогось, як ядро Linux.
Що найцікавіше використання GitHub?
Торвальдс: Я дуже щасливий, що він зробив, щоб запустити нові проекти. Хостинг проекту, який використовується для того, щоб викликати багато болю, але з приходом Git і GitHub, що робить будь-який невеликий проект, був таким простим. Незалежно від того, що проект є, що ви можете зробити.
У вас є бічні проекти вгору вашого рукава? Будь-які великі проекти, які домінують розвиток програмного забезпечення в найближчі роки?
Торвальдс: Нічний план. Але я буду знати, якщо ці плани змінюються.
p.s.: Консультація та пропозиції для перекладу вітається з метою підвищення якості перекладу.
Джерело: geektimes.ru/post/248744/
Щоб відмітити цю дату, ми попросили Лінуса поділитися прихованою історією Git, розкажіть, що він думає про проект і його вплив на розробку програмного забезпечення. Ви знайдете свої коментарі нижче в тексті. Цей інтерв'ю буде слідувати Git Week, в якому ми розглянемо індивідуальні проекти з використанням цієї системи керування версія щодня. Розвиваючі історії розвитку від KVM, Qt, Drupal, Puppet, Wine та багато іншого.
Чому ви створили Git?
Торвальдс: Я ніколи не хотів зробити версію системи управління (VCS) і відчував це лише найменше цікавого в комп'ютерному світі (за винятком баз даних), і я захоплю всі такі системи пристрасно. Але після того, як BitKiper (BK) пішов і дійсно змінив спосіб, який я переглядав вихідний код управління. BK зробив багато речей прямо. І змогла зберегти локальну репозиторійну копію та розподільну кодову злитку. Важлива особливість моделі розподіленого контролю версій полягає в тому, що він усуває одне з найсерйозніших проблем СКЛ: політика хто може внести зміни. BK показує, що ви можете уникнути цього просто, даючи кожному репозиторію. Але BK мав свої проблеми; кілька технічних рішень призвели до проблем (погано, але найгірше було те, що оскільки BK не був розподілений з відкритим вихідним джерелом, було багато людей, які не хочуть його використовувати. Таким чином, ми закінчилися кількома основними розробниками з використанням BK, які були вільні у використанні у відкритих вихідних проектах, але він ніколи не став основним Так що допомогло розвивати ядро, але ще було заспокійливих моментів.
Це сталося мені, коли Tridge (Andrew Tridgell) почав реверсувати досить простий протокол BK, який був порушенням правил BK. Я провів кілька тижнів (місячних)? Ось як я відчув, намагаючись медіатети між Tridge і Larry McVoy, але це стало зрозуміло, що це просто не працює. Я не можу зберегти використання BK, але я не хочу повернутися до найгірших днів до BK. На жаль, було інші інструменти SLE, які намагалися використовувати розподілену модель розвитку в певній мірі, але жоден з них добре працював у віддаленому використанні. Я володів власними експлуатаційними вимогами, які не могли навіть приблизно, що було доступно, і я був також стурбований цілісністю коду і процесом розробки, тому я вирішив писати шахту.
Як ви підходите? Ви пишете всі вихідні або просто в звичайному режимі?
Торвальдс: Е. Ви можете бачити, до речі, як все відбулося в репозиторію коду Git, крім першого дня або щось. Цей день був проведений на хостинг Git, щоб ви могли запустити комітацію Git за допомогою Git. Так, перший день або щось не в історії, але все інше тут. Основна робота виконана в основному протягом дня, але є пара нічних записів і пара після двох ранку. Найцікавіше, як швидко вона взяла форму. Найперший коміт у Git Tree не бувало коду, але він зробив основне - достатньо, щоб зробити себе. З’ясуйте, як Git повинен організувати дані.
Я хотів би підкреслити, що навіть якщо він був зібраний протягом десяти днів або щось, як це (при те, що я зробив мій перший Git Commite до репозиторію ядра Linux), це не так вже божевільний кодування. Обсяг цього ранного коду досить невеликий, все залежить від правильної реалізації базових ідей. І так я зробив шліфування перед усім проектом. Я бачив інші проблеми людей. Я бачив, що я хотів уникнути.
Чи вирощується на рівень ваших очікувань? Як правильно працювати за оцінками? Чи існують будь-які обмеження?
Торвальдс: Я дуже щасливий з Git. Працює виключно з кодом ядер і все ще слідує моїм очікуванням. Цікаво, що він бере на себе багато інших проектів. Зрозуміло швидко, після всього. Існує багато інерції в переході від одного SLE до іншого; просто подивіться на те, як довгі CVS і навіть RCS були у використанні, але в певній точці Git також забрав свої справи.
Чому ви думаєте, що це (Git) було так прийнято?
Торвальдс: Я думаю, що багато людей були обурені тими ж питаннями, які змусили мене покатати SLE. І тоді було багато проектів у зусиллях зафіксувати одну або дві дрібні проблеми, які отримали людей божевільні, було дійсно нічого подібного, що дійсно допомогли зберегти великі проблеми з головою. Навіть коли люди не розуміли, як важлива модель розподіленого розвитку (і багато людей, які борлися з ним), як тільки вони зрозуміли, що це дозволило полегшити і надійні резервні копії і дозволило людям зробити власні репозиторії без того, щоб думати про політику, що дозволяє записувати на конкретну репозиторію, вони ніколи не виглядали назад.
Чи завжди існують, або ви очікуєте відкликання SLE протягом наступних десяти років? Ви будете мати один з тих, хто пише це?
Торвальдс: Ні, я не буду той, хто пише його. І, можливо, ми побачимо щось нове в десять років, але я гадаю, що це буде щось схоже. Не в сенсі, що Git є правою, але в сенсі, що Git має основні можливості прямо всередині, що інші SLE ніколи не були раніше.
без помилкової скромності;
Чому Git працює так добре в Linux?
Торвальдс: На нашу роботу, тому він його частина. Я згадував розподілену модель багато разів, але це робить сенс думати про це знову. Але Git також був розроблений для того, щоб бути ефективним для великого проекту, як Linux, і написаний для того, щоб зробити те, що люди вважалися проблемою до Зійшла, бо ті, що я роблю щодня.
Просто подаруйте вам приклад: поняття фузії було видно як щось дуже болюче і складне в багатьох SLEs. Ви повинні планувати злиття, оскільки вони були серйозними. Це не турбувати мене, як я зазвичай робимо десятки об'єднувачів в день, коли я в часовому вікні злиття, і навіть так, робоче навантаження не повинно бути в об'єднанні, але в тестуванні коду. Сам об'єднувач займає пару секунд, набагато більше, ніж написання пояснення об'єднання.
Так Git був побудований і письмовий для моїх вимог. Що відбувається.
Люди сказали, що Git був просто для супер розумних людей. Андрій Мортон колись сказав: «Гіт призначений для того, щоб ви відчували себе навіть у дванадцятипалях, ніж раніше». Яка відповідь на це?
Торвальдс: Ну, я думаю, що це було спочатку, але це не більше. Ось кілька причин, чому люди відчувають себе таким чином, але я думаю, що є тільки одна причина зліва. Що залишилося дуже просто: «Це можна зробити так багато способів. й
Ви можете зробити багато речей з Git, і багато правил про те, що ви повинні зробити не приходять з технічних обмежень, але з того, що він добре працює, коли ви повинні взаємодіяти з іншими людьми. Git є дуже потужним інструментарієм, який може перевантажуватися спочатку, але це також означає, що ви можете часто ті самі або подібні речі різними способами і вони всі роботи. В цілому, найкращий спосіб дізнатися Git, ймовірно, просто робити прості речі і навіть шукати інші речі, поки ви не впевнені про основи.
Є кілька історичних причин для перегляду Git як складної речі. Одним з них є те, що це було дуже важко. Ті люди, які почали використовувати Git, перш ніж хтось інший, щоб працювати з ядром Linux, дійсно довелося дізнатися, як використовувати досить складний набір сценаріїв, щоб зробити все роботи. Всі зусилля були зроблені, щоб зробити основну технологію роботи, і дуже мало, щоб зробити це легко або зрозуміло. Яким чином ви робилися, Але це було переважно вірним тільки за перші шість місяців або рік.
Ще одна причина думки Ускладнено Git, що Git дуже своєрідний. Є люди, які використовували речі, такі як CVS за десятиріччя або два, і Git не CVS. Ні. Різні поняття. Команди відрізняються. Git ніколи не намагався виглядати як CVS, так і навпаки. І якщо ви використовуєте CVS-подібну систему протягом тривалого часу, ви отримаєте враження від складності Git і неприпустимої різниці. Люди відштовхували дивну версію системи. Чому Git номер версії "1.3.1" і не так красиво зроблено з збільшенням кількості в версіях CVS? Чому виникає дивний і страшний номер 40-character в шістнадцятковій системі?
Але Git не був Ці відмінності були необхідні. Ми можемо самі зателефонувати одержувачу і узгодити зручний час і місце вручення квітів, а якщо необхідно, то збережемо сюрприз. Відбувається фон CVS. Ми можемо самі зателефонувати одержувачу і узгодити зручний час і місце вручення квітів, а якщо необхідно, то збережемо сюрприз.
Чи може виростити розвиток ядра Linux за поточною швидкістю без Git? Чому?
Торвальдс: Ну, без git, звичайно. Але що б залучити кого-небудь пишу деякі еквівалентні Git: деякі розподілені SLE, які будуть як ефективні як Git. Ми обов'язково зробимо щось схоже на Git.
Що ви думаєте про GitHub?
Торвальдс: Github є винятковим ресурсом хостингу, я нічого не проти нього. Скарги, які я мав, що GitHub як платформа розвитку - комітує, Pull Запити, відстеження історії проблем і так далі - не було достатньо. Не близький, не схожий на те, що ядро Linux. Це занадто обмежений.
Це частково через те, як працює ядро Linux, але частково тому, що інтерфейси GitHub активно заохочують погану поведінку. GitHub містить коментарі з цих комітів і так далі, просто тому що веб-інтерфейс на GitHub активно заохочував погану поведінку. Вони фіксують деякі речі, тому це, ймовірно, працює краще, але це ніколи не буде підходить для чогось, як ядро Linux.
Що найцікавіше використання GitHub?
Торвальдс: Я дуже щасливий, що він зробив, щоб запустити нові проекти. Хостинг проекту, який використовується для того, щоб викликати багато болю, але з приходом Git і GitHub, що робить будь-який невеликий проект, був таким простим. Незалежно від того, що проект є, що ви можете зробити.
У вас є бічні проекти вгору вашого рукава? Будь-які великі проекти, які домінують розвиток програмного забезпечення в найближчі роки?
Торвальдс: Нічний план. Але я буду знати, якщо ці плани змінюються.
p.s.: Консультація та пропозиції для перекладу вітається з метою підвищення якості перекладу.
Джерело: geektimes.ru/post/248744/
