Git на мінімалках

• 1. Створення віддаленого Git репозиторію на одному комп’ютері
• 2. Створення віддаленого Git репозиторію на іншому комп’ютері
• 3. Деякі команди git, що використовую
• 3.1. Отримати красивий лог змін
• 3.2. Отримати лог змін по якомусь файлу чи каталогу
• 3.3. Які зміни в файли внесені у вказаному комміті
• 3.4. Оновити вашу гілку змінами з віддаленого репозиторію: rebase
• 3.5. Оновити вашу гулку змінами з віддаленого репозиторію через merge, це про pull

1. Створення віддаленого Git репозиторію на одному комп’ютері.

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

Налаштування віддаленого репозиторія на локальній машині

1.1. Створення bare repository:

Створення нової папку, наприклад, my_project.git, і перейти у неї в терміналі.

$ mkdir /path/to/my_project.git
$ cd /path/to/my_project.git
$ git init --bare

Bare repository відрізняється від звичайного тим, що він не має робочої директорії з файлами проєкту. Він містить лише внутрішні дані Git, такі як історія коммітів, гілки та теги (тобто, лише вміст папки .git). Такий репозиторій ідеально підходить для використання як “центральне сховище”, з якого розробники будуть завантажувати й надсилати зміни. Зазвичай такі репозиторії називають з суфіксом .git, щоб підкреслити їхню “бездротову” природу.

1.2. Створення локального репозиторію:

Створіть робочу папку для вашого проєкту. Якщо у вас вже є проєкт, просто перейдіть у його директорію.

$ mkdir /path/to/my_project
$ cd /path/to/my_project
$ git init

1.3. Прив’язка локального репозиторію до bare:

Тепер, коли у вас є локальний репозиторій, додайте ваш bare repository як віддалений. Зазвичай йому дають назву origin за замовчуванням.

$ git remote add origin /path/to/my_project.git

1.4. Перший push:

Додайте файли у свій локальний репозиторій, зробіть перший комміт, а потім надішліть (push) його у віддалений (bare) репозиторій.

$ touch README.md
$ git add README.md
$ git commit -m "Initial commit"
$ git push -u origin master

Тепер можна працювати з локальним репозиторієм, робити комміти та періодично синхронізувати його з вашим “бекапом” за допомогою команд git push та git pull. Це дозволить мати повну історію версій і локальний “бекап” без використання сторонніх сервісів.

2. Створення віддаленого Git репозиторію на іншому комп’ютері

А якщо bear репозиторій розмістити на іншій машині. Як між ними організувати спілкування?

Для того, щоб це працювало, потрібно налаштувати доступ по SSH між вашим комп’ютером (client) і машиною, де буде розміщено bare repository (server).

2.1. На машині-сервері (server):

Створити користувача Git (наприклад, git), який буде керувати репозиторіями. У домашній директорії цього користувача створити папку з вашим bare repository:

$ mkdir my_project.git
$ cd my_project.git
$ git init --bare

2.2. На машині-клієнті (client):

Створити пару SSH-ключів. Публічний ключ (id_rsa.pub) потрібно скопіювати на сервер в файл ~/.ssh/authorized_keys користувача git. Додати віддалений репозиторій до локального проекту, використовуючи SSH-адресу:

$ git remote add origin ssh://git@<IP_адреса_сервера>/path/to/my_project.git

2.3. Тепер можна надіслати (push) зміни на сервер:

$ git push origin master

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

## 3. Деякі команди git, що використовую

### 3.1. Отримати красивий лог змін

git log --pretty=format:"%h - %an, %ar : %s" --since=2.weeks

f4a2b1c - Jane Doe, 3 days ago : Fix critical bug in user authentication
a9b8c7d - John Smith, 5 days ago : Add feature for data export
e6f5g4h - Jane Doe, 1 week ago : Refactor payment processing module

• %h: Відображає короткий commit hash.

• %an: Відображає ім’я автора.

• %ar: Відображає відносний час від поточної дати ( “2 days ago”, “5 hours ago”).

• %s: Відображає перший рядок commit message.

• –since=2.weeks: Вказує на проміжок часу (останні 2 тажні) за який відрображати лог.

Відносні проміжки часу

Можна використовувати різні одиниці виміру часу.

Секунди, хвилини, години, дні:

    --since=30.minutes (за останні 30 хвилин)

    --since=12.hours (за останні 12 годин)

    --since=10.days (за останні 10 днів)

Місяці та роки:

    --since=3.months (за останні 3 місяці)

    --since=1.year (за останній рік)

Комбіновані вирази: Ви можете поєднувати різні одиниці.

    --since="1.month 2.days ago" (місяць і два дні тому)

Звісно! Git надає багато гнучких способів для фільтрації комітів за часом. Ось основні альтернативи та доповнення до –since=2.weeks.

Відносні проміжки часу

Ви можете використовувати різні одиниці виміру часу.

Секунди, хвилини, години, дні:

    --since=30.minutes (за останні 30 хвилин)

    --since=12.hours (за останні 12 годин)

    --since=10.days (за останні 10 днів)

Місяці та роки:

    --since=3.months (за останні 3 місяці)

    --since=1.year (за останній рік)

Комбіновані вирази: Ви можете поєднувати різні одиниці.

    --since="1.month 2.days ago" (місяць і два дні тому)

Конкретні дати та час

Можна вказувати точні дати у різних форматах.

Формат YYYY-MM-DD:

    --since=2025-09-15 (з 15 вересня 2025 року)

"Людський" формат:
    --since="Sep 15 2025"

    --since="yesterday" (за вчора і сьогодні)

    --since="10:00" (від сьогоднішнього ранку о 10:00)

    --since="2025-09-20 10:00:00" (точна дата і час)

3.2. Отримати лог змін по якомусь файлу чи каталогу

• Для файла

git log -- ./iib_app_srvc/post_storedocument_ProcessInput.esql

• Для каталога

git log -- ./iib_app_srvc/

• для каталога: ```text

commit d80c6a82e28693fb46c09664a453d0c8ded3a3ee Author: pasha pasha@mail.com Date: Mon Nov 25 18:14:02 2024 +0200

Future 1

commit 89d350b3214aaf1883dfe9a0f31286111fb9f4a4 Author: pasha pasha@mail.com Date: Mon Nov 25 07:19:42 2024 +0200

Fix 22 added new field check

### <a name="p3.3">3.3. Які зміни в файли внесені у вказаному комміті</a>

```bash
git show  b0f8d8f83a1bfc7f2dbfb9560e0423e13e6c243b

git show b0f8d8f83a1bfc7f2dbfb9560e0423e13e6c243b
commit b0f8d8f83a1bfc7f2dbfb9560e0423e13e6c243b
Author: pasha <pasha@mail.com>
Date:   Sat Sep 20 20:39:42 2025 +0300

    az-29

diff --git a/function_app.py b/function_app.py
index a73266f..f57a20f 100644
--- a/function_app.py
+++ b/function_app.py
@@ -40,7 +40,7 @@ async def hello_orchestration_starter(req: func.HttpRequest, client: df.DurableO

     # Start the orchestration and return a status response
     try:
-        logging.info(f" Starting orchestration with blob name = {blob_name}")
+        #logging.info(f" Starting orchestration with blob name = {blob_name}")
         #,  client_input={"name": blob_name}
         instance_id = await client.start_new(function_name)
         response = client.create_check_status_response(req, instance_id)
@@ -77,7 +77,7 @@ def hello_orchestration_orchestrator(context: df.DurableOrchestrationContext):
     result1 = yield context.call_activity("hello_orchestration_activity", "Seattle")
     result2 = yield context.call_activity("hello_orchestration_activity", "Tokyo")
     result3 = yield context.call_activity("hello_orchestration_activity", "London")
-    result4 = yield context.call_activity("video_orchestration_activity", 'blob_name')
+    result4 = yield context.call_activity("video_orchestration_activity", "blob_name")

     logging.info(f"Orchestration completed with results: {[result1, result2, result3, result4]}")

3.4. Оновити вашу гулку змінами з віддаленого репозиторію

Перед виконанням треба закоммітити останні зміни, або зробити git stash. Пілся виконання закоммічені зміни відправити в віддалений репозиторій використовуючи git push.

    git fetch  origin
    git rabase

git fetch + git rebase

Це двокроковий процес, який дає більше контролю і створює чистішу історію.

git fetch: завантажує зміни з віддаленого репозиторію, не торкаючись  робочої гілки. Ви можете переглянути зміни (git log origin/main), перш ніж їх застосовувати.

git rebase: Ця команда бере  унікальні локальні коміти (ті, що  зробили, але ще не відправили на сервер), "відкладає" їх убік, оновлює локальну гілку до останньої версії з сервера, а потім застосовує локальні коміти один за одним поверх цих оновлень.

Результат: Історія комітів залишається лінійною, без зайвих коммітів злиття. Виглядає так, ніби ви почали свою роботу вже після того, як ваш колега вніс свої зміни. Це “переписує” історію ваших локальних комітів (вони отримують нові хеші).

Аналогія: Ви написали свою частину документа. Потім побачили, що колега вже вніс зміни в основний документ. Ви берете свої правки, “вирізаєте” їх, оновлюєте основний документ до версії колеги, а потім “вставляєте” свої правки вже в оновлену версію.

Команда git pull –rebase є скороченням для послідовності git fetch + git rebase.

3.5. Оновити вашу гулку змінами з віддаленого репозиторію через merge

    git pull

або, якщо ви в гілці tz01 то

    git fetch
    git merge origin/tz01