# на общей машине создаём bare-репозиторий
mkdir D:\Git\project.git
cd D:\Git\project.git
git init --bare
# у разработчиков (если эта папка расшарена на сервере)
git clone \\server\Git\project.git# если у коллеги репозиторий в папке D:\Work\project
# и он расшарил её как \\colleague\Work\project
git remote add colleague \\colleague\Work\project
git fetch colleague# Общая база
B=$(git merge-base --octopus M X Y)
# База для W
git checkout -b W "$B"
# Пакеты патчей только по m.txt (полный путь от корня!)
git format-patch --no-stat --keep-subject -o /tmp/patches_M "$B"..M -- path/to/m.txt
git format-patch --no-stat --keep-subject -o /tmp/patches_X "$B"..X -- path/to/m.txt
git format-patch --no-stat --keep-subject -o /tmp/patches_Y "$B"..Y -- path/to/m.txt
# Применяем по порядку
git checkout W
git am --3way /tmp/patches_M/*.patch
git am --3way /tmp/patches_X/*.patch
git am --3way /tmp/patches_Y/*.patch
# при конфликте: правим path/to/m.txt, затем git add path/to/m.txt && git am --continue
# Контроль: кроме m.txt ничего не менялось
git diff --name-only "$B"..W -- . ':!path/to/m.txt'# Имена веток и путь к файлу
P=path/to/m.txt
# В исходном репо: M, X, Y — исходные ветки
# 1) Временный клон и очистка истории до одного файла
git clone --no-local . ../tmp-m
cd ../tmp-m
git filter-repo --force --path "$P" --refs M X Y
# 2) Во втором репо найдём общий предок ОЧИЩЕННЫХ веток и дадим ему имя
B2=$(git merge-base --octopus M X Y)
git branch base_mxy "$B2"
cd -
# 3) В основном репо создаём базовую ветку W на настоящем предке (старое дерево целиком)
B=$(git merge-base --octopus M X Y)
git checkout -b W "$B"
# 4) Подключаем очищенный репозиторий как внешний и подтягиваем нужные refs
git remote add onlym ../tmp-m
git fetch onlym base_mxy M X Y
# 5) Переносим ТОЛЬКО коммиты после B2, в нужном порядке
git cherry-pick onlym/base_mxy..onlym/M
git cherry-pick onlym/base_mxy..onlym/X
git cherry-pick onlym/base_mxy..onlym/Y
# при конфликте: правим $P, git add "$P", затем git cherry-pick --continue
# 6) Контроль: кроме m.txt ничего не менялось
git diff --name-only "$B"..W -- . ':!'"$P"- name: Build and Push Docker Image with Kaniko
uses: int128/kaniko-action@v1
with:
context: .
file: Dockerfile
push: true
build-args: |
ID_RSA=${{ secrets.ID_RSA }}ARG ID_RSA
RUN mkdir -p /root/.ssh
RUN echo "$ID_RSA" | base64 -d > /root/.ssh/id_rsa
RUN chmod 600 /root/.ssh/id_rsa
RUN ssh-keyscan github.com >> /root/.ssh/known_hosts--amend во время rebase.git commit --amend не создает новый коммит, а перезаписывает предыдущий.rebase на каждом шаге делаете --amend, вы по сути всё время заменяете один и тот же коммит. Остальные коммиты, которые Git должен был «применить» в процессе ребейза, просто исчезают, потому что их заменили.rebase -i вместо amend нужно:git add <файлы> # главное проиндексировать правки файлов
git rebase --continue # тут гит уже сам сделает git commit --no-editgit commit перед continue имеет смысл только если вы хотите поменять ещё и сообщение коммита.reflog — журнале ссылок.git refloggit reset --hard <хеш_из_reflog>
GIT_COMMITTER_DATE="2025-03-28T17:00:00" git commit --date="2025-03-28T17:00:00" -m "Your message"git rebase -i HEAD~NGIT_COMMITTER_DATE="2025-03-28T17:00:00" git commit --amend --no-edit --date="2025-03-28T17:00:00"
git rebase --continueliquibase diff, generateChangeLog). Это может автоматически сгенерировать changesets. Не всегда идеально, особенно для данных, но может служить хорошей стартовой точкой.change_id
git checkout develop # удостовериться что мы в нужной ветке
git merge --ff $(git commit-tree -p develop -p master -m "Reset develop to master" master^{tree})master^{tree} — это ссылка на текущее состояние файлов из ветки master.git commit-tree — создаёт новый коммит, который:git commit-tree -p develop -p master -m "Reset develop to master" master^{tree}git merge --ff $(...)--ff (fast-forward) говорит гиту просто передвинуть указатель develop вперёд на этот новый коммит, если это возможно без создания нового коммита слияния.$(...) — это подстановка команды в bash, то есть git merge --ff получит на вход хеш коммита из предыдущего шага.
curl -H "Authorization: token YOUR_GITHUB_TOKEN" \
-H "Accept: application/vnd.github.v3+json" \
"https://api.github.com/user/repos?affiliation=collaborator" | jq -r '.[].full_name'Создаю на сервере репозиторий git init. Создаю у себя репозиторийДля чего? Вы создали две отдельные истории. Даже если в обоих случаях получилась ветка с названием main, это всё равно будут разные ветки без общей истории. Не нужно так делать. Репозиторий следует создавать в одном месте, а затем уже клонировать в другие.
Ни пуш ни пулл не работают.
Merge remote-tracking branch 'refs/remotes/origin/' into
моя ветка приняла все изменения с удаленного репозитория и происходит слияние в моей ветке?
моя ветка поглащает origin и станет основной