Знадобилося мені нещодавно навчити азам Git кількох моїх співробітників, які тільки вивчають програмування і пробують працювати. Пошукавши в інтернеті статті для новачків, я зіткнувся з тим, що більшість з них про те як використовувати консольний Git або ж про його необхідність і перевага перед іншими подібними системами. Новачок зазвичай не дуже сильний у всіх цих справах. Я вважаю, що йому, для початку, і знати це все не обов'язково. Адже можна використовувати Git для своїх проектів і вчитися всім його принад паралельно з вивченням програмування. але,настійно рекомендую сприймати цю статтю як ознайомчу і в майбутньому вивчити Git докладніше.
Вам було цікаво дізнатися, як працює цей інструмент управління версіями? Якщо ви працюєте з розробкою і не реєструєте зміни в своєму проекті, ви практично втрачені. Що робити, якщо внесення змін для виробництва і дає деяку помилку?
Але як Гіт знає порядок здійснення? Кожен ресурс має тенденцію вимагати більше одного фіксації, всі зміни в кожному ресурсі повинні бути «об'єднані» в кінці, щоб бути частиною проекту. Щоб вирішити ці дві проблеми, Гіт працює з концепцією «гілок». Таким чином, ви можете мати кілька гілок і в кожному з них працювати над функцією або виправляти код, наприклад. Але що станеться, якщо ті ж рядки були змінені на обох гілках? Простий, відбувається конфлікт. Але зазвичай це не проблема, яка дуже складна для вирішення, і ми будемо розглядати її краще в майбутньому пості тут, в блозі.
Загалом, під катом стаття, як використовуючи SmartGit і BitBucket можна поліпшити своє життя початківця розробника.
М аленький план того, що ми будемо робити:
- Створення сховища на Bitbucket.
- Клонування сховища (додавання його в SmartGit).
- Створення комита.
- Скасування змін.
- Створення гілок.
- Проштовхування гілок на віддалений репозиторій(Аплоад гілок на віддалений сервер).
- Злиття гілок.
Поїхали. Створення сховища дуже просте завдання. Ми будемо для цього користуватися BitBucket, тому вам потрібно мати там акаунт. Після реєстрації тиснемо кнопку «Create» і заповнюємо необхідні поля. Склоніруем репозиторій використовуючи SmartGit. Візьмемо посилання на наш репозиторій.
Повертаючись до теми, це коли ви «приєднаєтеся» до двом гілкам, що є можливість появи цього «злиття», згаданого вище. І створіть папку «проекти» де-небудь, як ми будемо використовувати її у всьому підручнику. Тепер ваша перша фіксація буде зареєстрована!
Процедуру записи нижче. Ви побачите, що початковий вміст першої фіксації було відновлено. Використовуючи цю команду, буде показаний екран із зазначенням відмінностей, як показано в наведеній вище елементів. Для цього нам потрібно об'єднати дві гілки. Зверніть увагу, що фіксація «Третя фіксація» з'являється над «Четвертої фіксацією».
Тепер запустимо SmartGit, виберемо «Project» - «Clone» (або Ctrl + Alt + O) і заповнимо необхідні поля:
Система запросить ваш логін і пароль від Bitbucket:
У наступному вікні доступні дві опції клонування «Include Submodules» і «Fetch all Heads and Tags». Git дозволяє окремі модулі програми зберігати в різних репозиторіях. Якщо ви відзначите опцію «Include Submodules» - SmartGit автоматично довантажити всі модулі. Якщо відзначити опцію «Fetch all Heads and Tags», то SmartGit після створення папки проекту завантажить всі гілки і теги для даного сховища:
Резюме практичних команд
Якщо ви зробили підручник вище, ви повинні були залишити хоча б трохи сумнівів в своїх командах. Проте, якщо ви вже хочете продовжити навчання, у вас є два варіанти. «У цій статті ви познайомитеся з основними централізованими і розподіленими системами управління та управління випуском і основними системами, використовуваними сьогодні для управління версіями».
Ви з області технологій вже брали участь в проекті розробки групи, і ви знаєте, наскільки важким є постійний обмін файлами між командою. Електронна пошта, Хмарна завантаження, ручка, використовуються для обміну та обміну кодами. Система контролю версій - це система, яка реєструє зміни, внесені в групу файлів, і її основною функцією є управління проектом і створення його різних версій. Він пропонує більш простий і ефективний спосібдля команди розробників модифікувати одну і ту ж кодову базу без конфліктів.
Наступне вікно - ім'я проекту в SmartGit:
Якщо ви клонували порожній репозиторій (як в цій статті), то побачите наступне вікно:
Йдемо далі. Створимо комит. Що таке комит? Це фіксація змін. Кожен комит «запам'ятовує» що саме ви змінили і в будь-який момент часу можна повернути колишній стан файлів. Раджу вам після кожного значимого зміни, наприклад, виправлення бага в функції, робити комит. Що б створити комит, потрібно щось змінити в проекті. Додайте парочку файлів в папку з проектом:
З його допомогою ви можете переглянути історію всіх змін, зроблених командою, створити нові версії і відновити старі версії проекту. Слід пам'ятати, що система управління може працювати для будь-якого файлу на комп'ютері, навіть якщо він зосереджений на розробці.
Першими типами таких систем, які з'являлися, були централізовані системи управління версіями, і вони працюють таким чином: у них є один сервер на основі архітектури клієнт-сервер, де сервер, в свою чергу, також званий репозиторієм, містить всі файли проекту, Тому розробники повинні завантажити версію, яку вони хочуть змінити, на свій локальний робочий стіл, коли вони будуть завершені, і завантажити її на сервер. За допомогою цієї системи було легко керувати проектом, тому що команда знає, що кожен з них модифікує і підтримує історію версій проекту.
Тепер можна побачити зміни нашого проекту в SmartGit:
Виберемо обидва файли і натиснемо спочатку «Stage», а потім «Commit». Навіщо потрібно натискати «Stage»? Кнопка «Stage» додає в поточний індекс вибрані файли. Якщо ви хочете створити комит для двох файлів, а змінили, припустимо цілих 5, досить вибрати ці два файли, натиснути «Stage», що додасть їх в індекс, а після «Commit». Таким чином тільки обрані два файли потраплять в комит.
Однак в цій системі є тільки одна гілка розвитку, немає можливості того, щоб різні команди працювали паралельно в одному проекті в різних галузях. Іншим недоліком є те, що, оскільки в структурі цієї системи є тільки один сервер, якщо він залишається в повітрі, під час простою працювати в групі буде неможливо.
І потім з'являються розподілені системи управління версіями, в цій системі клієнти більше не копіюють останні версії, А витягують весь репозиторій. Який найкращий інструмент для використання? Тепер, коли ми знаємо, як працюють ці системи, перерахуємо основні програмні продукти, Які відповідають за роботу цієї системи. Сьогодні існує безліч систем і інструментів для контролю версій, кожен з яких використовує інший метод. Таким чином, перераховані програми - це безкоштовне програмне забезпечення, працюють на більшості операційних системі користуються популярністю у розробників.
Після чого з'явиться віконце, де потрібно буде ввести коментар коміта. Зазвичай туди пишуть те, що було змінено, додано, видалено і так далі:
Після чого слід натиснути кнопку «Commit». Кнопка «Commit & Push» робить те ж саме, але ще і проштовхує (заливає) зміни в віддалений репозиторій (в нашій випадку це Bitbucket). Поки не варто цього робити. Проштовхуванням ми займемося далі. Внизу, в списку гілок, з'явиться локальна гілка «master». Це основна гілка коду програми. Що таке гілки, розповім трохи пізніше. А зараз зробимо що-небудь з нашим проектом, а потім відкинути редагування. Я видалю файл readme.txt, відредагую файл index.php і додам новий файл confic.cfg:
Це допомагає вам керувати різними версіямиваших проектів. Послуги з управління версіями коду. Ця стаття призначена для компаній і груп, які ще не вибрали або не розглядають можливість зміни інструментів управління версіями. Існує кілька критеріїв вибору інструменту управління версіями.
Простота використання. . Критерії вибору інструменту для особистого проекту відрізняються від критеріїв вибору команди або організації. Для команди або організації вибір, заснований тільки на популярності, може привести до неадекватного вирішення. Важливо дослідити, чи підходять причини популярності варіанти для вашого вибору.
А тепер відкинути редагування після коміта. Зайдемо в Log:
Виберемо комит, до якого хочемо відкотитися і натиснемо «Reset»:
У наступному вікні нам пропонують вибрати який саме «Reset» ми хочемо зробити:
Поясню. Згадайте, що при створенні коміта, ви спочатку додаєте файли в індекс (stage). Це дозволяє закомітіть тільки проіндексовані файли. Soft reset скидає тільки Коміто. Індекс і фізичні зміни в файлах залишаються. Mixed reset працює так само, як і софт, але ще видаляє індекс файлів. Hard reset видаляє Коміто, індекс і фізичні зміни в файлах. Акуратно використовуйте hard reset, що б випадково не видалити зайвого.
- Реєстрація змін проекту.
- Включення спільної роботи.
- Створення та підтримка змін проекту.
Це проміжний етап підготовки до підготовки огляду. Індекс - це елемент інфраструктури. Особливо для початківців і проміжних користувачів, кілька випадків, коли корисне управління прямим індексом корисно, чи не переважують всі додаткові зусилля і складність, а також ризики консолідації конфігурації, відмінною від тієї, яка була проаналізована і протестована в робочому каталозі. Якби Гіт був автомобілем, щоб дізнатися, як його водити, вам потрібно зрозуміти, як працює двигун внутрішнього згоряння.
Я зробив hard reset для наочності:
Як бачите все зміни в файлах пропали, а точніше все повернулося до стану першого коміта.
Тепер трохи про створення гілок. Навіщо вони взагалі потрібні? Гілка дозволяє зберегти поточний стан коду, і експериментувати. Наприклад, ви пишіть новий модуль. Логічно робити це в окремій гілці. Дзвонить начальство і каже, що в проекті баг і терміново потрібно пофиксить, а у вас модуль не дописані. Як же заливати неробочі файли? Просто перейдіть на робочу гілку без модуля, Виправлено баг і заливайте файли на сервер. А коли «небезпека» минула - продовжите роботу над модулем. І це один з багатьох прикладів користі гілок.
Ці команди часто називаються «сантехнічними» командами, а найпростіші у використанні команди називаються «фарфоровими» командами. Навіть ці команди страждають від низького зручності використання. Деякі з них працюють не так, як очікувалося, в порівнянні з класичними концепціями управління версіями. Однак створений репозиторій безпосередньо не використовується, оскільки він не має відповідного робочого каталогу. Крім того, ваша документація вважається більш важкою для розуміння. Неправильна команда, яка виконується недбалим або непідготовленим розробником, може легко призвести до дуже складних ситуацій, які можуть піти.
Спробуємо створити свою гілку. У нас вже одна є, це master. Вона створюється автоматично (якщо відсутня) коли ви робите перший комит. Створимо ще одну гілку і назвемо її «new_future1». Натисніть F7 або правим кліком внизу у вкладці «Branches» на напис «Local Branches» і в випадаючому списку виберіть «Add branch»:
Натисніть «Add branch & Switch» що б відразу переключитися на створену гілку. Тепер ви можете створювати нові Коміто, змінювати файли і не турбуватися. Так як у вас завжди є гілка майстер, в яку можна повернутися. Коли ви переключаєте гілку, Git змінює локальні файлина ті, які є в цій гілці. Тобто, якщо ви створите нову гілку поміняєте щось у файлі index.php, а потім перейдіть на гілку master то всі зміни, вироблені вами будуть видалені. Якщо ж переключитися назад в створену гілку - зміни повернуться.
Хоча втрата коду зустрічається рідко, для усунення безладу потрібно багато технічних знань, особливо після того, як збиток був переданий іншим розробникам. Важливо відзначити, що надлишок складності і детальна експозиція не приносять ніякого поліпшення продуктивності і не роблять більш ефективним управління версіями.
Гіт досить складно вчитися і використовувати. Лиха для зловживання службовим становищем є загальними, особливо з непідготовленими розробниками. Найбільш важливим критерієм при виборі інструменту управління версіями є простота, оскільки інші критерії не мають значення або еквівалентні. Простим інструментом є те, що він зробить управління версіями швидким і прозорим.
До сих пір ми працювали локально. Спробуємо залити праці нашої роботи на сервер. Створимо який-небудь комит в гілці new_future1. У разі якщо репозитарій порожній, а він порожній, так як ми створили його деякий час назад і на сервер нічого не залили, Bitbucket основний призначає ту гілку, яку залили першої. Тому перемкнемося на гілку «master» і натиснемо кнопку «Push»:
Якщо ваша команда ще не прийняла інструмент управління версіями, почніть з самого простого рішення, яке вирішить проблему. Потім, якщо вам це дійсно потрібно, ви можете перейти від одного інструменту до іншого, повторно використовуючи історію. У світі розробки програмного забезпеченнябагато проблем і бої відбуваються через відсутність контролю версій будь-якого продукту, що розробляється. Більшість з цих проблем виникають, коли ми працюємо як команда, і причини.
Деякі програмісти в кінцевому підсумку модифікують вихідний код інших, не запрошуючи нічого, і ці зміни замінюють попередній код. З цим починаються аргументи і дискусії в команді, тому що кожен закінчує думку, що його попередній код більш корисний, ніж поточний, і т.д.
Далі SmartGit запитає налаштувати чи відстеження гілки (cofigure tracking). Відстеження дозволяє автоматично оновлювати відповідні гілки, коли ви завантажуєте або завантажуєте оновлення коду. Тому сміливо тисніть «Configure»:
Тепер перейдіть на іншу гілку і виконайте те ж саме. Зайдемо на Bitbucket і подивимося, що змінилося в розділі «Commits»:
Оскільки всі ці проблеми виникли, було б непогано, якби було місце, де кожен міг би розробити свій вихідний код, і була зроблена оцінка де: який з них краще підходить для проекту? Щоб вирішити ці та інші проблеми, згадані вище в світі розробки, з'явилися системи контролю версій, ми приймемо тут невеликий підхід.
Іншими словами, його мета - управляти різними версіями документа, який змінюється з плином часу. Оскільки багато з них використовуються в області розробки технологій і програмного забезпечення, багато людей вважають, що система контролю версій використовується тільки для запису змін в вихідних кодах, Але вона може використовуватися для управління файлами будь-якого типу на комп'ютері.
Як бачите все потрапило на віддалений сервер.
Тепер сольем гілки. Навіщо це потрібно? Візьмемо той же приклад з модулем. Рано чи пізно ви допишіть його і вам потрібно буде додати код модуля в основний код програми. Досить просто злити гілки. Для цього перейдіть на гілку, в яку хочете злити код. У нашому випадку це майстер. Після чого натисніть правим кліком на гілку, з якої хочете злити код і виберіть «Merge»:
Система управління локальною версією
У всякому разі, використання контролю версій - дуже розумне і корисне рішення в нашій області. Це вважається одним з найпростіших методів використання контролю версій, тобто тут ми робимо зміни, які ми можемо вказати вручну і як це працює: копіювання і розміщення файлів в інших каталогах на локальному комп'ютері, Багато разів поміщаючи їх в ці каталоги.
Цей метод дуже поширений, тому що він простий, але ми часто можемо забути, в якому каталозі ми зберегли копію попереднього файлу, І ми можемо поспішати або через відсутність уваги замінити один каталог іншим. Зіткнувшись з цими труднощами, деякі програмісти мали ідею розробки першої системи контролю версій, що працювала локально, контролюючи зміни файлів під контролем версій.
А тепер залишилося проштовхнути зміни гілки master на сервер. Заливаємо зміна на сервер так само, як ми робили це раніше і отримуємо:
Ось і все на цей раз. Через картинок стаття вийшла великий. Задавайте свої відповіді. Пишіть питання.
Всі ви знаєте систему Git. Хоча б чули - це напевно. Розробники, які користуються системою, її або люблять, або лають за складний інтерфейс і баги. Система управління версіями Git де-факто є стандартом в індустрії. У розробника можуть бути думки про переваги Mercurial, але найчастіше доводиться миритися з вимогою вміти користуватися Git. Як у будь-якої складної системи, у неї безліч корисних і необхідних функцій. Однак, до геніальної простоти добираються не всі, тому існуюча реалізаціязалишала простір для вдосконалення.
Тиші, це система, яка все ще широко використовується в наші дні. Як цитувалася раніше в статті, розробникам важко було працювати разом. Ці системи були розроблені з упором на полегшення життя для розробників, які хотіли працювати в команді. Ця система стабільна і вже багато років стала стандартом для контролю версій. Одна з великих проблем, з якими розробники стикалися з цим типом системи, полягала в тому, що кожне літо вони були централізовані на одній машині, і якщо ця машина стала непрацездатною, ніхто не міг нічого зробити, поки не повернеться до нормальної роботи, тобто відмінна залежність між розробником і сервером.
Простими словами- хитромудрою додатком було важко користуватися. Тому в лабораторії Массачусетського Технологічного Інституту взялися за поліпшення і відсікли все «проблемні елементи» (адже те, що для одного проблема, для іншого легко може бути перевагою). Поліпшену і спрощену версію назвали Gitless. Її розробляли з урахуванням 2400 питань, пов'язаних з Git і взятих з сайту розробників StackOverflow.
Що не так з Git
Багато користувачів скаржилися, що Git потребує новому інтерфейсі. Фахівці навіть склали документ Що не так з Git? Концептуальний аналіз дизайну. Автори: S. Perez De Rosso і D. Jackson.приклад
git checkout< file >// відкинути всі зміни в одному файлі з останньої вивантаження в систему git reset --hard // відкинути всі зміни у всіх файлах з останньої вивантаження в системуЦі два рядки - одна з ілюстрацій того, як сильно Git потребував вдосконаленому інтерфейсі. Дві різні команди для однієї функції з однією різницею в тому, що одна для одиночного файлу, а друга - для безлічі файлів. Частина проблеми також в тому, що ці дві команди насправді не роблять в точності одне й те саме.
Більшість користувачів Git застосовують його для невеликого числа команд, а решта одиниці знають платформу на більш глибокому рівні. Виходить, що в основному платформа потрібна для базових функцій, а великий пласт можливостей залишається для надто вузького кола. Це говорить про неправильну роботу Git.
Коротке порівняння базових функцій з попередньою версією
Однією з яскравих характеристик Gitless є те, що версія ігнорує функцію під назвою staging. Вона дозволяє зберігати окремі частини файлу. Зручно, але може створювати проблемні ситуації. Ключова відмінність між цією і функцією stashing полягає в тому, що друга приховує зміни з робочої області.Функція stashing ховає чорнову роботу в робочому каталозі - відслідковують файли, які були змінені і зберігає всі в стек з незавершеними змінами. Всі зміни можна застосувати пізніше, коли буде зручно. Це потрібно, коли ви працюєте в одній гілці і в ній все в безладному стані, а потрібно терміново переключитися на іншу гілку. Ви не хочете вивантажувати код з частково зробленої роботою в першій гілці на час паузи.
Функція staging індексує зміни, внесені в файл. Якщо ви позначили файли staged, Git розуміє, що ви підготували їх до вивантаження.
У Gitless немає концепції stashing. Уявіть таку ситуацію. Ви перебуваєте в розпалі розробки проекту і повинні переключитися в іншу його гілку, але ви ще не вивантажили в систему свою наполовину виконану роботу. Функція stashing бере зроблені вами зміни і зберігає їх в стек з незакінченими змінами, які ви можете відновити пізніше.
Автор керівництва по Gitless повідомляє, що проблема з'являється при перемиканні між гілками. Може бути складно запам'ятовувати який з stashes де знаходиться. Ну і вершиною всього цього стало те, що функція не допомагає в разі коли ви в процесі мерджа, що включає в себе конфліктні файли. Така думка Переза де Россо.
Завдяки Gitless ця проблема вирішується. Гілки стали повністю автономними по відношенню один до одного. Це робить роботу набагато простіше і дозволяє розробникам уникати плутанини, коли потрібно постійно перемикатися між завданнями.
збереження змін
Gitless ховає область стадій в цілому, що робить процес більш прозорим і менш складним для користувача. Для вирішення завдань є набагато більш гнучкі команди «commit». Причому вони дозволять робити такі дії, як виділення сегментів коду для коммітов.
Крім цього ви можете змінити класифікацію будь-якого файлу на значення: відстежується, що не відстежується або ігнорований. Не має ніякого значення, чи існує цей файл в заголовку чи ні.
Розгалуження процесів розробки
Основна, необхідна для розуміння нової версії, Ідея: гілки в Gitless стали абсолютно незалежними лініями розробки. Кожна з них залишається при своїй робочою версією файлів окремо від інших. Перетинів і проблем немає. В який момент ви б не переключалися в іншу гілку, вміст вашого робочої області зберігається і файли, які мають відношення до гілки призначення, відновлюються. Класифікація файлів також зберігається. Якщо файл класифікований по-різному в двох окремих гілках, то Gitless буде враховувати це.
Простіше кажучи, в версії Gitless вам не потрібно пам'ятати про незавантажених в систему зміни, які знаходяться в конфлікті зі змінами в гілці призначення.
Також ви зможете відкласти рішення конфліктної ситуації, якщо у вас середина мержда або fuse. Конфлікт залишиться поки ви не переключіться назад.
Робота з віддаленими репозиторіями
Ось синхронізація з іншими репозиторіями відбувається в обох програмах однаково.
Ще одна перевага нової версії - можливість перемикатися до старої без втрати коду. При цьому ваші колеги можуть бути навіть не в курсі, що ви користуєтеся іншим ПО.
Керівництво по роботі з Gitless ви можете вивчити на офіційному сайті програми. У документації описано наступне: як створювати репозиторій, зберігати зміни; як працювати з гілками; як користуватися тегами, працювати з віддаленими репозиторіями.
Що в підсумку
Вийшло додаток, яке зберігає функціонал Git, але в той же час стало простішим у вивченні і використанні командами розробки. Насправді і до Gitless вже були спроби поліпшити Git. Але за словами Філіпа Гуо (він асистент професора когнітивної науки в Каліфорнійському університеті Сан-Дієго) ця версія вперше досягла цілей по перетворенню інтерфейсу і дійсному рішенню головних проблем.Проект використовував суворі методи по створенню програмного забезпечення. Це необхідно для виокремлення недоліків в одному з найбільш широко застосовуваних у всьому світі програмних проектів. У минулому безліч користувачів приводили смішні аргументи як за, так і проти Git, але всі вони не були засновані на науковому підході.
На прикладі Gitless стає очевидно, що підхід спрощення можливо застосовувати і до інших складних систем. Наприклад, Google Inbox і Dropbox.