Робота з репозиторієм

Фіксація змін та їх опис

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

[!TIP] Щоб краще опанувати роботу з командою git commit вам треба ознайомитися з статею Запис змін до репозиторія

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

[!NOTE] Як працювати з історією ви можете почитати в Перегляд історії комітів для перемикання на конкретний комміт чи гілку ми розглянемо далі.

Виключення деяких змін з процесу фіксації

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

[!NOTE] Файл .gitignore має розташовуватись в кореневій директорії вашого репозиторію.

Приклади використання .gitignore:

Веб-фреймворк Laravel зберігає налаштування у файлах .env, тому ці файли повинні бути виключені з коміту, щоб запобігти поширенню конфіденційної інформації
Якщо розроблювач використовує редактор коду Visual Studio Code, то файли налаштувань цього редактора .vscode/* можуть бути виключені з коміту
Якщо в проекті є файли, які автоматично генеруються програмним забезпеченням, наприклад, за допомогою Sass-компілятора, то їхні створені файли повинні бути виключені з коміту

Застосування файлу .gitignore дозволяє зміцнити безпеку та ефективність вашого проекту, зберігаючи відповідну структуру проекту та виключаючи з коміту непотрібні файли та директорії.

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

[!WARNING] Зазвичай Git не зберігає пусті директорії, що може призвести до проблем при розумінні структури проекту.

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

Приклади `.gitignore`

JetBrains IDE

# macOS
.DS_Store

# IntelliJ IDE files
.idea/
*.iml

# Compiled Java class files
*.class
# Compiled Kotlin class files
*.kts
*.kts$

# Compiled Python files
*.pyc

# Log files
*.log
logging/

# Gradle/Grails build files
.gradle/
/build/

VSCode

# folders
__pycache__/
.vscode/
.idea/
node_modules/
bower_components/
dist/

# files
.env
*.log
npm-debug.log*
yarn-debug.log*
yarn-error.log*
.DS_Store
.history/
*.bak

# OS generated files
._*
.Spotlight-V100
.Trashes
Icon?
ehthumbs.db
Thumbs.db

Гілки: Розгалуження та злиття

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

Це дозволяє більш ефективно працювати в команді та швидко розв'язувати проблеми. Розуміння та вміння працювати з гілками Git є важливим компонентом успішної роботи в команді.

Про гілки

[!TIP] Для кращого розуміння вам треба ознайомитися зі статею Гілки у кількох словах

На картинці зображено:

HEAD - це покажчик на те, який коміт в даний момент використовується в гілці. Отже, HEAD - це посилання на поточне положення в репозиторії.
Tag - це ознака, яку встановлюєте на певному коміті у своєму репозиторії. Теги зазвичай використовуються для позначення важливих точок в історії вашого репозиторія. Наприклад версія - v1.0
Hash - це унікальний ідентифікатор коміту (98ca9), який Git призначає кожному коміту. Hash - це 40-значний номер, який ідентифікує конкретний коміт в історії репозиторія. У ваших командах ви можете вказувати перші 5 символів для переходу або пошуку необхідного коміту.
Branch - гілка master (або гілки) використовуються для одночасної роботи з різними версіями коду у репозиторії. Гілка базується на конкретному коміті з історії репозиторія та містить свою власну логіку розробки, а пізніше може бути злита назад в основну гілку (наприклад, в гілку main).

[!NOTE] Раніше основна гілка називалася master, але декілька років тому прийняли новий стандарт назви головної гілки main. Ви можете задати власну назву головної гілки, але так краще не робити без необхідності, для виключення плутанини у команді.

Створення гілок

Для створення нової гілки використовуйте команду git branch. Спробуємо створити нову гілку, додати файл та закомітити його і подивитися оновлену історію коммітів. Виконаємо команди:

створюємо гілку та файл

git branch testing
git checkout testing
cat > hello.txt # Input some text

переглядаємо файл

cat hello.txt

робимо комміт та дивимося історію

git add hello.txt
git commit -m "Create demo file"
git log --graph

Отримаємо наступний стан репозиторію

* commit 6c077be8bba2b84c348a34579718abaa3ab3e74c (HEAD -> testing)
  | Author: Taras Omelianenko <hello@production-ready.dev>
  | Date:   Tue Jun 27 18:32:16 2023 +0300
  |
  |     Create demo file
  |
* commit e2df22fc90f80044be06beebb04a718491dedc5c (testing,)
  Author: Taras Omelianenko <hello@production-ready.dev>
  Date:   Tue Jun 27 18:06:30 2023 +0300

        Додано файл1

Переключення гілок

Для переключення на попередню гілку master вам треба скористатися командою git checkout.

git checkout master

[!TIP] Для того щоб освоїти роботу з Git у командному рядку, вам необхідно виконати вправи на сайті тренажері Learn Git Branching, а саме мінімум: Основи (Вступ, Їдемо далі, Переміщуємо роботу туди-сюди, Всяке) та Віддалені репозиторії (Push & Pull -- віддалені репозиторії в Git!).

Історія змін

Для відстеження історії змін внесених до програмного забезпечення, може створюватися файл CHANGELOG.md. Він містить повний список змін, включаючи нові функції, виправлення помилок та інші важливі деталі, пов'язані з релізом програмного забезпечення.

Як створити хороший лог змін?

Головні принципи

Лог змін для людей, а не машин.
Окремий розділ для кожної версії.
Зміни одного типу мають бути згруповані.
На версії та секції потрібно ставити гіперпосилання.
Остання версія мусить бути на початку.
Кожна версія має мати власну дату.
Вкажіть чи підтримуєте Ви принципи Семантичне версіювання.

Типи змін

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

Приклад файлу змін

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]

## [1.1.1] - 2023-03-05

### Added

- Arabic translation (#444).
  - v1.1 French translation.
  - v1.1 Dutch translation (#371).
  - v1.1 Russian translation (#410).
  - v1.1 Japanese translation (#363).
  - v1.1 Norwegian Bokmål translation (#383).
  - v1.1 "Inconsistent Changes" Turkish translation (#347).
  - Default to most recent versions available for each languages
  - Display count of available translations (26 to date!)
  - Centralize all links into `/data/links.json` so they can be updated easily

### Fixed

- Improve French translation (#377).
  - Improve id-ID translation (#416).
  - Improve Persian translation (#457).
  - Improve Russian translation (#408).
  - Improve Swedish title (#419).
  - Improve zh-CN translation (#359).
  - Improve French translation (#357).
  - Improve zh-TW translation (#360, #355).
  - Improve Spanish (es-ES) transltion (#362).
  - Foldout menu in Dutch translation (#371).
  - Missing periods at the end of each change (#451).
  - Fix missing logo in 1.1 pages
  - Display notice when translation isn't for most recent version
  - Various broken links, page versions, and indentations.

### Changed

- Upgrade dependencies: Ruby 3.2.1, Middleman, etc.

### Removed

- Unused normalize.css file
  - Identical links assigned in each translation file
  - Duplicate index file for the english version

## [1.1.0] - 2019-02-15

### Added

- Danish translation (#297).
  - Georgian translation from (#337).
  - Changelog inconsistency section in Bad Practices.

### Fixed

- Italian translation (#332).
  - Indonesian translation (#336).

## [1.0.0] - 2017-06-20

### Added

- New visual identity by [@tylerfortune8](https://github.com/tylerfortune8).
  - Version navigation.
  - Links to latest released version in previous versions.
  - "Why keep a changelog?" section.
  - "Who needs a changelog?" section.
  - "How do I make a changelog?" section.
  - "Frequently Asked Questions" section.
  - New "Guiding Principles" sub-section to "How do I make a changelog?".
  - Simplified and Traditional Chinese translations from [@tianshuo](https://github.com/tianshuo).
  - German translation from [@mpbzh](https://github.com/mpbzh) & [@Art4](https://github.com/Art4).
  - Italian translation from [@azkidenz](https://github.com/azkidenz).
  - Swedish translation from [@magol](https://github.com/magol).
  - Turkish translation from [@emreerkan](https://github.com/emreerkan).
  - French translation from [@zapashcanon](https://github.com/zapashcanon).
  - Brazilian Portuguese translation from [@Webysther](https://github.com/Webysther).
  - Polish translation from [@amielucha](https://github.com/amielucha) & [@m-aciek](https://github.com/m-aciek).
  - Russian translation from [@aishek](https://github.com/aishek).
  - Czech translation from [@h4vry](https://github.com/h4vry).
  - Slovak translation from [@jkostolansky](https://github.com/jkostolansky).
  - Korean translation from [@pierceh89](https://github.com/pierceh89).
  - Croatian translation from [@porx](https://github.com/porx).
  - Persian translation from [@Hameds](https://github.com/Hameds).
  - Ukrainian translation from [@osadchyi-s](https://github.com/osadchyi-s).

### Changed

- Start using "changelog" over "change log" since it's the common usage.
  - Start versioning based on the current English version at 0.3.0 to help
    translation authors keep things up-to-date.
  - Rewrite "What makes unicorns cry?" section.
  - Rewrite "Ignoring Deprecations" sub-section to clarify the ideal
    scenario.
  - Improve "Commit log diffs" sub-section to further argument against
    them.
  - Merge "Why can’t people just use a git log diff?" with "Commit log
    diffs".
  - Fix typos in Simplified Chinese and Traditional Chinese translations.
  - Fix typos in Brazilian Portuguese translation.
  - Fix typos in Turkish translation.
  - Fix typos in Czech translation.
  - Fix typos in Swedish translation.
  - Improve phrasing in French translation.
  - Fix phrasing and spelling in German translation.

### Removed

- Section about "changelog" vs "CHANGELOG".

## [0.3.0] - 2015-12-03

### Added

- RU translation from [@aishek](https://github.com/aishek).
  - pt-BR translation from [@tallesl](https://github.com/tallesl).
  - es-ES translation from [@ZeliosAriex](https://github.com/ZeliosAriex).

## [0.2.0] - 2015-10-06

### Changed

- Remove exclusionary mentions of "open source" since this project can
  benefit both "open" and "closed" source projects equally.

## [0.1.0] - 2015-10-06

### Added

- Answer "Should you ever rewrite a change log?".

### Changed

- Improve argument against commit logs.
  - Start following [SemVer](https://semver.org) properly.

## [0.0.8] - 2015-02-17

### Changed

- Update year to match in every README example.
  - Reluctantly stop making fun of Brits only, since most of the world
    writes dates in a strange way.

### Fixed

- Fix typos in recent README changes.
  - Update outdated unreleased diff link.

## [0.0.7] - 2015-02-16

### Added

- Link, and make it obvious that date format is ISO 8601.

### Changed

- Clarified the section on "Is there a standard change log format?".

### Fixed

- Fix Markdown links to tag comparison URL with footnote-style links.

## [0.0.6] - 2014-12-12

### Added

- README section on "yanked" releases.

## [0.0.5] - 2014-08-09

### Added

- Markdown links to version tags on release headings.
  - Unreleased section to gather unreleased changes and encourage note
    keeping prior to releases.

## [0.0.4] - 2014-08-09

### Added

- Better explanation of the difference between the file ("CHANGELOG")
  and its function "the change log".

### Changed

- Refer to a "change log" instead of a "CHANGELOG" throughout the site
  to differentiate between the file and the purpose of the file — the
  logging of changes.

### Removed

- Remove empty sections from CHANGELOG, they occupy too much space and
  create too much noise in the file. People will have to assume that the
  missing sections were intentionally left out because they contained no
  notable changes.

## [0.0.3] - 2014-08-09

### Added

- "Why should I care?" section mentioning The Changelog podcast.

## [0.0.2] - 2014-07-10

### Added

- Explanation of the recommended reverse chronological release ordering.

## [0.0.1] - 2014-05-31

### Added

- This CHANGELOG file to hopefully serve as an evolving example of a
  standardized open source project CHANGELOG.
  - CNAME file to enable GitHub Pages custom domain.
  - README now contains answers to common questions about CHANGELOGs.
  - Good examples and basic guidelines, including proper date formatting.
  - Counter-examples: "What makes unicorns cry?".

[unreleased]: https://github.com/olivierlacan/keep-a-changelog/compare/v1.1.1...HEAD
[1.1.1]: https://github.com/olivierlacan/keep-a-changelog/compare/v1.1.0...v1.1.1
[1.1.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v1.0.0...v1.1.0
[1.0.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.3.0...v1.0.0
[0.3.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.2.0...v0.3.0
[0.2.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.1.0...v0.2.0
[0.1.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.8...v0.1.0
[0.0.8]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.7...v0.0.8
[0.0.7]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.6...v0.0.7
[0.0.6]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.5...v0.0.6
[0.0.5]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.4...v0.0.5
[0.0.4]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.3...v0.0.4
[0.0.3]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.2...v0.0.3
[0.0.2]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.1...v0.0.2
[0.0.1]: https://github.com/olivierlacan/keep-a-changelog/releases/tag/v0.0.1

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

Робота з репозиторієм

Робота з репозиторієм

Фіксація змін та їх опис

Виключення деяких змін з процесу фіксації

Приклади `.gitignore`

JetBrains IDE

VSCode

Гілки: Розгалуження та злиття

Про гілки

Створення гілок

Переключення гілок

Історія змін

Як створити хороший лог змін?

Головні принципи

Типи змін

Приклад файлу змін

results matching ""

No results matching ""

Робота з репозиторієм

Фіксація змін та їх опис

Виключення деяких змін з процесу фіксації

Приклади .gitignore

JetBrains IDE

VSCode

Гілки: Розгалуження та злиття

Про гілки

Створення гілок

Переключення гілок

Історія змін

Як створити хороший лог змін?

Головні принципи

Типи змін

Приклад файлу змін

results matching ""

No results matching ""

Приклади `.gitignore`