Git проти GitHub - що таке контроль версій і як це працює?

Вас коли-небудь бентежило, як працюють Git і GitHub? Не турбуйтеся - ви не самотні. Git та GitHub іноді можуть бути складними, але до кінця цього допису ви добре зрозумієте ці два.

Спочатку може виникнути спокуса повірити, що Git і GitHub - це одне і те ж. Але насправді це не так. Дійсно, можна використовувати Git без GitHub! І зрештою, ці два існують для різних цілей.

Цей пост розпочнеться з гарного вивчення цілей Git та GitHub. Потім ми дізнаємось про основні відмінності між цими двома життєво важливими технологіями.

Без зайвих сумнівів, давайте почнемо з Git.

Що таке Git?

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

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

Але якщо Git - розподілена система контролю версій, що саме означають ці терміни?

Що означає «розподілений»?

Термін "розподілений" означає, що кожного разу, коли ви вказуєте Git спільно використовувати каталог проекту, Git не надає доступ лише до останньої версії файлу. Натомість він розповсюджує кожну версію, яку записав для цього проекту.

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

Гаразд, отже, «розподілений» означає поширювати всі - а не лише декілька вибраних - версій файлів проекту, які записав Git. Але що саме таке система контролю версій?

Що таке система контролю версій?

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

Наочно, багато людей вже контроль версій своїх проектів шляхом перейменування різних версій одного і того ж файлу різними способами , як blogScript.js, blogScript_v2.js, blogScript_v3.js, blogScript_final.js, blogScript_definite_final.js, і так далі. Але такий підхід схильний до помилок і неефективний для спільних проектів.

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

Однак, щоб отримати найкращі результати від Git, важливо зрозуміти, як Git обробляє ваші файли.

Файли штатів у Git

У Git існує три основних стани (умови), в яких файл може знаходитись: змінений стан , поетапний стан або зафіксований стан .

Модифікований стан

Файл у зміненому стані є переглянутим, але незафіксованим (незаписаним) файлом.

Іншими словами, файли у зміненому стані - це файли, які ви змінили, але явно не наказали Git контролювати.

Поетапний стан

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

Як тільки файл стає інсценованим, це означає, що ви прямо дозволили Git контролювати версію цього файлу.

Зобов'язаний стан

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

Таким чином, фіксований файл - це файл, в якому ви записали його поетапну версію в каталог (папку) Git.

Примітка: Стан файлу визначає місце, куди його розмістить Git.

Розташування файлів

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

Робочий каталог

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

Примітка:

  • Файли у зміненому стані знаходяться в робочому каталозі.
  • Робочий каталог відрізняється від .gitкаталогу. Тобто ви створюєте робочий каталог, тоді як Git створює .gitкаталог.
  • Перегляньте цю статтю порівняння, щоб дізнатись більше про відмінності між двома сховищами.

Площа постановки

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

Примітка:

  • Файли в інсценізованому стані знаходяться в інсценізаційній зоні.

Каталог Git

.gitКаталог є папка (також називається «сховище») , що Git створює в робочій директорії , ви проінструктовані його відстежувати.

Також у цій .gitпапці Git зберігає бази даних об’єктів та метадані файлу (файлів), який ви доручили йому контролювати.

Примітка:

  • .gitКаталог життя Git - це елемент копіюється при клонувати репозиторій з іншого комп'ютера (або з інтернет - платформи , як GitHub).
  • Файли у зафіксованому стані знаходяться в каталозі Git.

Основний робочий процес Git

Робота з системою контролю версій Git виглядає приблизно так:

Схема робочого процесу Git
  1. Змінення файлів у робочому каталозі.

    Зверніть увагу, що будь-який файл, який ви змінюєте, стає файлом у зміненому стані .

  2. Вибірковий етап файлів, які потрібно записати в .gitкаталог.

    Зверніть увагу, що будь-який файл, який ви вводите (додаєте) в інтерактивну область, стає файлом у режимі індексу .

    Також пам’ятайте, що індексованих файлів ще немає в .gitбазі даних.

    Постановка означає, що інформація про інсценований файл потрапляє у файл (який називається "індексом") у .gitсховищі.

  3. Зафіксуйте файл (файли), який ви індексували, в .gitкаталог. Тобто постійно зберігати знімок індексованих файлів у .gitбазі даних.

    Зверніть увагу, що будь-яка версія файлу, яку ви прив'язуєте до .gitкаталогу, стає файлом у стані фіксації .

Суть досі

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

Але, зачекайте секунду, якщо Git допомагає ефективно керувати та розповсюджувати різні версії файлу проекту, яка мета GitHub?

Демістифіковано GitHub

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

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

Щоб розмістити (або поділитися) сховищем Git на GitHub, виконайте наведені нижче дії:

Крок 1: Реєстрація облікового запису GitHub

Першим кроком для початку розміщення на GitHub є створення особистого облікового запису. Відвідайте офіційну сторінку реєстрації, щоб зареєструватися.

Крок 2: Створіть віддалене сховище в GitHub

Після реєстрації в обліковому записі створіть у GitHub дім (сховище) для сховища Git, яким ви хочете поділитися.

Крок 3: Підключіть каталог Git проекту до віддаленого сховища

Після створення віддаленого сховища для вашого проекту зв’яжіть .gitкаталог проекту, який знаходиться локально у вашій системі, з віддаленим сховищем на GitHub.

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

git remote add origin //github.com/yourusername/yourreponame.git

Примітка:

  • Замініть yourusernameу наведеному вище коді своє ім’я користувача GitHub.

    Аналогічно, замініть yourreponameна ім'я віддаленого сховища, до якого потрібно підключитися.

  • Наведена вище команда передбачає, що git повинен додати вказану URL-адресу до локального проекту як віддалене посилання, з яким .gitможе взаємодіяти локальний каталог.
  • originОпція в команді вище це ім'я за замовчуванням (коротку назву) Git надає сервер хостинг свій віддалений репозиторій.

    Тобто замість URL-адреси сервера Git використовує коротку назву origin.

  • Не обов’язково дотримуватися імені сервера за замовчуванням. Якщо ви віддаєте перевагу іншому імені, а не originпросто, просто підставте originім’я в git remote addкоманді вище будь-яким назвою, яке вам більше подобається.
  • Завжди пам’ятайте, що коротка назва сервера (наприклад,   origin) не є нічим особливим! Він існує лише локально, щоб допомогти вам легко посилатися на URL-адресу сервера. Тож відчуйте, щоб змінити його на коротку назву, на яку ви можете легко посилатися.
  • Щоб перейменувати будь-яку існуючу віддалену URL-адресу, використовуйте git remote renameкоманду приблизно так:
git remote rename theCurrentURLName yourNewURLName
  • Щоразу, коли ви клонуєте (завантажуєте) будь-яке віддалене репо, Git автоматично називає URL-адресу цього репо origin. Однак ви можете вказати інше ім'я за допомогою git clone -o yourPreferredNameкоманди.
  • Щоб побачити точну URL-адресу, збережену для таких псевдонімів, як origin, запустіть git remote -vкоманду.

Крок 4: Підтвердьте підключення

Після підключення каталогу Git до віддаленого сховища перевірте, чи вдалося з’єднання, запустивши git remote -vкомандний рядок.

Після цього перевірте вихідні дані, щоб підтвердити, що відображена URL-адреса збігається з віддаленою URL-адресою, до якої ви маєте намір підключитися.

Примітка:

  • Дивіться статтю „Підключення за допомогою SSH”, якщо ви хочете під’єднатися за допомогою URL-адреси SSH замість URL-адреси HTTPS.
  • Однак, якщо ви не впевнені у використанні віддаленої URL-адреси, перевірте “Яку віддалену URL-адресу слід використовувати?” статті.
  • Ви хочете змінити свою віддалену URL-адресу? Зміна URL-адреси пульта дистанційного керування - відмінне керівництво.

Крок 5: Надайте локальне репозиторій Git на віддалений репо

Після успішного підключення локального каталогу до віддаленого сховища ви зможете почати надсилати (завантажувати) свій локальний проект вгору.

Всякий раз, коли ви готові поділитися своїм проектом деінде, на будь-якому віддаленому репо, просто доручіть Git перенести всі ваші коміти, гілки та файли у вашому локальному .gitкаталозі у віддалене сховище.

Синтаксис код , який використовується для завантаження (натисніть) локальний каталог Git на віддалений репозиторій git push -u remoteName branchName.

Тобто, щоб підштовхнути свій локальний .gitкаталог і припустивши, що коротка назва віддаленої URL-адреси - “origin”, запустіть:

git push -u origin master

Примітка:

  • Наведена вище команда передбачає, що git повинен підштовхнути вашу локальну гілку ведучого до віддаленої гілки майстра, розташованого за URL-адресою з іменем origin .
  • Технічно ви можете замінити originпараметр URL-адресою віддаленого сховища. Пам'ятайте, що originпараметр - це лише псевдонім URL-адреси, яку ви зареєстрували у своєму локальному .gitкаталозі.
  • -uПрапор (вгору / стеження посилання прапора) автоматично пов'язує .gitмісцеве відділення каталогу файлів з віддаленим філією. Це дозволяє використовувати git pullбез будь-яких аргументів.

Крок 6: Підтвердьте завантаження

Нарешті, поверніться до сторінки вашого сховища GitHub, щоб підтвердити, що Git успішно перемістив ваш локальний каталог Git до віддаленого сховища.

Примітка:

  • Можливо, вам доведеться оновити сторінку віддаленого сховища, щоб відобразити зміни.
  • GitHub також має безкоштовний додатковий пристрій для перетворення віддаленого сховища у функціональний веб-сайт. Давайте подивимося "як" нижче.

Опублікуйте свій веб-сайт на сторінках GitHub

Після надсилання проекту до віддаленого сховища ви можете легко опублікувати його в Інтернеті приблизно так:

  1. Переконайтеся, що ім’я основного файлу HTML вашого проекту - index.html.
  2. На платформі веб-сайту GitHub перейдіть до сховища проекту, який ви хочете опублікувати, та натисніть вкладку налаштувань сховища .
  3. Прокрутіть вниз до розділу Сторінки GitHub і змініть гілку Source з none на master .
  4. Потім з’явиться сповіщення про те, що „Ваш сайт опубліковано за адресою //користувацьке ім’я.github.io/your-github-repo-name/ ”.
  5. Тепер ви можете переглянути та опублікувати свій проект за вказаною URL-адресою.

Цей розділ просто подряпав поверхню публікації вашого проекту за допомогою GitHub. Щоб дізнатись більше про сторінки GitHub, перегляньте цю документацію “Робота зі сторінками GitHub”.

Коротко

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

Все ще сумніваєтесь?

Вас все ще бентежить тонка грань між Git та GitHub? Не хвилюйтеся - я вас покрив. Нижче наведено п’ять ключових відмінностей між Git та GitHub.

Різниця 1: Git проти GitHub - основна функція

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

Однак GitHub - це в основному хостинг-платформа для розміщення сховищ Git в Інтернеті. Це дозволяє користувачам тримати віддалене сховище приватним або відкритим для спільних зусиль.

Різниця 2: Git проти GitHub - операційна платформа

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

Однак GitHub - це веб-служба, яка працює виключно в Інтернеті. Це означає, що вам потрібен Інтернет, щоб робити що-небудь на GitHub.

Різниця 3: Git проти GitHub - винахідники

Лінус Торвальдс розпочав розробку Git у квітні 2005 року.

Кріс Ванстрат, Пі Джей Х'єтт, Том Престон-Вернер та Скотт Чейкон заснували GitHub.com у лютому 2008 року.

Різниця 4: Git проти GitHub - Супровідники

У липні 2005 року Лінус Торвальдс передав обслуговування Git Хуніо К. Хамано, який з тих пір був головним обслуговуючим оператором.

А Microsoft придбала GitHub у жовтні 2018 року.

Різниця 5: Git проти GitHub - конкуренти

Популярними альтернативами Git є Mercurial, Team Foundation Version Control (TFVC), Perforce Helix Core, Apache Subversion та IBM Rational ClearCase.

Найближчими конкурентами GitHub є GitLab, Bitbucket, SourceForge, Cloud Source Repositories та AWS CodeCommit.

Загалом

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

Корисний ресурс

  • Як користуватися Git - приголомшливий путівник із приголомшливими порадами