Skip to content

Latest commit

 

History

History
148 lines (91 loc) · 13.3 KB

01-git-and-github-test-answers.md

File metadata and controls

148 lines (91 loc) · 13.3 KB
title
Git & GitHub Quiz Answers

Git & Github Quiz Answers

Git платний?

Ні. Git – це безкоштовна програма, є абсолютно вільною.

https://uk.wikipedia.org/wiki/Git

Про коротку історію Git можна почитати тут.

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

https://github.com/pricing

Окрім GitHub, є ще інші аналоги - BitBucket, GitLab, etc.

Git можна встановити лише на MacOS та Linux

Ні, Git - це програма яка можна встановити на любій OS. У unix based систем (Ubuntu, MacOS, etc) у більшості випадків він вже буде встановлений.

Завантажити Git можна ось тут – https://git-scm.com/downloads.

Про процес інсталяції Git можна прочитати тут або https://www.atlassian.com/git/tutorials/install-git.

Одразу після встановлення, потрібно буде налаштувати Git.

Як виглядає Distributed version control diagram?

Важливо відмінністю на діаграмах, є те, що декілька Repository (репозиторіїв), які склоновані на кожен хост.

.

Додатково детальніше можна прочитати тут.

Які мінуси при роботі із розподіленими системами контролю версій? (DVCS)

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

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

Які команди існують в Git?

Ось тут можна знайти список із дуже багатьох команд.

Базові необхідні команди:

  • add – підготувати файли до коміту
  • commit – закомітити підготовлені файли у локальний репозиторій
  • push – надіслати усі локальні коміти у віддалений репозиторій
  • pull – стянути усі нові коміти із віддаленого репозиторія на локальний

Для чого потрібна команда git clone?

Команда git clone потрібна щоб скопіювати (склонувати) віддалений (remote) репозиторій на локальний хост (local).

Ось тут можна прочитати про інші варіанти взаємодії з віддаленим репозиторієм.

А ось тут ви знайдете повну документацію по команді.

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

Порядок наступний:

  • git status дозволить подивитись на нові/змінені файли
  • git add . або git add * підготують усі файли з попередньої команди до комміту
  • git commit -m "initial commit" створить новий комміт, та збереже його локально
  • git push надішле комміти, які ще не надсилались, у remote репозиторій

Команди git add та git commit можуть виконувати багато ітерацій, та пізніше один виклик git push надішле усі попередні локальні комміти.

Що таке GitHub?

GitHub - це оболонка для Git, яка надає ще багато іншого потрібного функціоналу. Список усіх фіч GitHub'у можна побачити тут.

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

Також, частково, GitHub є соціальною мережею. Для прикладу, профайли у GitHub можуть бути вашим технічним резюме – https://github.com/itspoma. Також, великі компанії, типу Google можуть одного дня знайти вас саме через GitHub, та запропонувати роботу.

Також ви можете створювати командні проекти – https://github.com/cursor-education, та організовувати репозиторії/матеріали.

Що таке branch? (або гілка)

Git Branch - це можливість створити ізольовано копію головної гілки master (директорії) проекту, та працювати у своїй гілці. Це дає можливість абсолютно ізольовано працювати, та не поламати код/логіку іншим розробникам.

Команди:

  • git checkout -b name-of-my-new-branch або git branch name-of-my-new-branch створить нову гілку
  • git branch покаже список гілок, та покаже на які ми зараз знаходитесь
  • git checkout some-branch переключитись на іншу гілку
  • git merge master стягнути зміни з гілки master до поточної гілки

Детально про розгалуження в Git можна прочитати тут.

Чи можна закомітити файл у чужий репозиторій в GitHub?

Так, можна, якщо:

  • вам дали на це права (додали як contributor до проекту)
  • ви скопіювали репозиторій у свій workspace (тобто зробили Fork), зробили зміни у скопіюваному репо, і надсилаєте Pull-Request (PR)

Про Pull Requests можна почитати тут.

Доречі, PR це особливість GitHub'у, а не Git'а. Також можливість робити PR-и є у всіх популярних системах - GitHub, Bitbucket, GitLab, etc.

Як підготувати усі нові файли до коміту?

git add * або git add . – обидва команди додадуть усі нові або змінені файли. Якщо потрібно додати лише .txt файли, тоді команда буде – git add *.txt. Якщо потрібно додати лише test.jpg файл, тоді команда буде – git add test.jpg.

Також, у Git є можливість створювати аліаси – короткі команди (ярлики) на довгі команди. Почитати ось тут.

Ось цікавий аліас https://content.pivotal.io/blog/git-unadd, який дозволить робити git unadd ., тобто зворотню команду до git add ..

Яка команда допоможе перевірити список нових файлів та папок (які ще не були закомічені)?

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

Як ігнорувати файл credentials.txt, якому містяться паролі?

У Git є можливість ігнорувати файли, записавши їх у файл .gitignore. Для прикладу, якщо вам потрібно щоб під час git status файл credentials.txt ніколи не показувався (ігнорувався), просто додайте його у .gitignore.

Детальніше про команду та паттерни можна прочитати тут.

Важливо, що файли, які вже закомічені, не можуть бути заігнорені. Для цього вам прийдеться видалити файл з remote репозиторію, заігнорити його локально, та закомітити .gitignore файл з правками.

Які best practices (кращі практики) є при роботі з Git?

  • Уникати "add file" та схожі абстрактні коментарі в commit message, – це дозволить іншим розробник, не дивлячись всередину комміту, лише по його коментарі зрозуміти які зміни відбулись
  • Кожен комміт - це окрема ізольована одиниця, – уникати великі комміти. Для прикладу, якщо ви зробили зміни які стосуються зеленої та синьої кнопок, зробіть окремі комміти на це.
  • Не комітити конфіденційні файли, – ігноруйте тимчасові, великі та авто-згенеровані файли через .gitignore
  • Краще невеликі і часті коміти, – уникайте коммітів гігантів, які мають в собі увесь проект та 100500 змін
  • Використовувати commit messages, які очевидні і чітки, – кожен комміт меседж повинен бути чітким, та пояснювати які зміни відбулися у комміті. Для приклад, "add file", "added stuff", "qwer" – це погані повідомлення, бо по їх контексі незрозуміло що відбулося в комміті. А "change color to green", "added about page", "updated authentification to use jwt tocken" – це хороші приклади комміт повідомлень.
  • Не комітити авто-згенеровані файли
  • Спілкуватися з іншими розробниками, щоб уникати merging conflicts