title |
---|
Git & GitHub Quiz Answers |
Ні. Git – це безкоштовна програма, є абсолютно вільною.
https://uk.wikipedia.org/wiki/Git
Про коротку історію Git можна почитати тут.
GitHub є умовно безкоштовним для більшості задач. У випадку, якщо вам буде потрібна командна робота (приховані репозиторії, інтеграції, додаткове місце, тощо), лише тоді GitHub попроси оплатити сервіс.
Окрім GitHub, є ще інші аналоги - BitBucket, GitLab, etc.
Ні, Git - це програма яка можна встановити на любій OS. У unix based систем (Ubuntu, MacOS, etc) у більшості випадків він вже буде встановлений.
Завантажити Git можна ось тут – https://git-scm.com/downloads.
Про процес інсталяції Git можна прочитати тут або https://www.atlassian.com/git/tutorials/install-git.
Одразу після встановлення, потрібно буде налаштувати Git.
Важливо відмінністю на діаграмах, є те, що декілька Repository (репозиторіїв), які склоновані на кожен хост.
Додатково детальніше можна прочитати тут.
Розподілені системи контролю версій, зокрема Git, є:
- швидкі (за рахунок того, що найчастіші операції commit проводяться із локальною копією репозиторія)
- безпечні (якщо центральний репозиторій буде недоступним, то у кожного є повна копія репозиторія)
- оффлайн (можна працювати з локальним репо без інтернету, наприклад у потязі. А потім зробити push усіх локальних комітів як тільки зявиться інтернет).
- проста (для мінімально роботи вам потрібно вивчити лише декілька команд – add, commit, push, pull).
Ось тут можна знайти список із дуже багатьох команд.
Базові необхідні команди:
- add – підготувати файли до коміту
- commit – закомітити підготовлені файли у локальний репозиторій
- push – надіслати усі локальні коміти у віддалений репозиторій
- pull – стянути усі нові коміти із віддаленого репозиторія на локальний
Команда 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 - це оболонка для Git, яка надає ще багато іншого потрібного функціоналу. Список усіх фіч GitHub'у можна побачити тут.
Для прикладу, – сторінка, яку ви зараз читаєте, розміщена на статичному безкоштовному хостингу GitHub.
Також, частково, GitHub є соціальною мережею. Для прикладу, профайли у GitHub можуть бути вашим технічним резюме – https://github.com/itspoma. Також, великі компанії, типу Google можуть одного дня знайти вас саме через GitHub, та запропонувати роботу.
Також ви можете створювати командні проекти – https://github.com/cursor-education, та організовувати репозиторії/матеріали.
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 можна прочитати тут.
Так, можна, якщо:
- вам дали на це права (додали як 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
– покаже усі нові або змінені файли, а також на якій бренчі (гілці) ми зараз знаходимось.
У Git є можливість ігнорувати файли, записавши їх у файл .gitignore
.
Для прикладу, якщо вам потрібно щоб під час git status
файл credentials.txt
ніколи не показувався (ігнорувався), просто додайте його у .gitignore
.
Детальніше про команду та паттерни можна прочитати тут.
Важливо, що файли, які вже закомічені, не можуть бути заігнорені. Для цього вам прийдеться видалити файл з remote репозиторію, заігнорити його локально, та закомітити .gitignore
файл з правками.
- Уникати "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