Не форканням єдиним Git репозиторіїв

На GitHub є чарівна функція що зветься fork repo. Робить вона просто - клонує основний репозиторій (званний в народі як upstream) і робить твій особистий репо.

Далі ти можеш оновлювати свій репо беручи оновлення із upstream'ового.

Закортіло трішки менше прив'язуватись до GitHub (просто, без /Майкрософт/ причини). Вибрав Framasoft бо мені подобається їхня філосовія.

Ця організація має свій Git-сервер, що побудований на основі GitLab.

Дзеркалючи (форкаючи) репозиторії

Форкінг (fork) на GitHub ніщо інше, як створення власного репозиторію і додавання під капотом основного репозиторію (з якого робиться форк) як remote upstream репозиторій. Використовуючи цю логіку, а також звісно відповідь на stackoverflow процедура створення особистого форку з будь-якого git-репо така:

• створюємо пустий репозиторій на https://framagit.org (але підійде будь-який git-репозиторій)

• клонуємо цей репозиторій собі локально на комп (git clone /www/repo/path)

• обов'язково вказати дані по йменю та емейлу для комітів (git config user.{name,email})

• додати головний/upstream репо як апстрім: git remote add upstream https://github.com/user/repo

• витягнути файли та коміти (чужу білизну не брати!) з головного репо

  git pull upstream master

• закинути файли,коміти на свій репо в гілку мастєра/master:

  git push -u origin master

Життя після форкінгу

Граємось дальше із модифікацією, новими гілками (branches) і все що можна з гітом)

Edit (06-09-2020):

Робота з власною гілкою (branch)

Оптимальним варіантом для персонального налаштування чи доповнення/зміни проєкту є створення власної гілки, напр. own (git checkout -b own).

Закидаємо її на Гіт-сервер:

git push -u origin own

Вносимо зміни, зберігаємо (комітимо, commits), граємось далі.

Підтримуємо свій форк оновленим

Для оновлення (синхронізації) свого форку з головним репозиторієм робимо:

git fetch
git pull upstream master

Це можна автоматизувати, наприклад, за допомогою bash-скрипту та cron.

Далі вносимо зміни до своєї гілки проєкту (в нашому випадку це own):

git checkout own
git merge master

Швидше за все виникнуть конфлікти між файлами (merge conflicts). Вирішуємо їх (вносимо зміни) і відправляємо змінену гілку own на свій гіт-сервер.