# на общей машине создаём 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"--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 получит на вход хеш коммита из предыдущего шага.
Создаю на сервере репозиторий git init. Создаю у себя репозиторийДля чего? Вы создали две отдельные истории. Даже если в обоих случаях получилась ветка с названием main, это всё равно будут разные ветки без общей истории. Не нужно так делать. Репозиторий следует создавать в одном месте, а затем уже клонировать в другие.
Ни пуш ни пулл не работают.
Merge remote-tracking branch 'refs/remotes/origin/' into
моя ветка приняла все изменения с удаленного репозитория и происходит слияние в моей ветке?
моя ветка поглащает origin и станет основной
git fetch --unshallowgit fetch --allgit fetch origin updater --depth=1git checkout updater
/ в конце пути не влияет на работу). Permission to kirill-pereshyvalov-13/laravel-docker.git denied to KirillPereshyvalov13— вероятно, вы вошли не под тем аккаунтом, который имеет доступ к репозиторию.
echo "url=https://github.com" | git credential reject__pycache__/
у меня не связывается папка B2 c репозиторием с гитхаба
.
└───yyy.loc
├───.git
└───packages
├───.git # пустой репо созданный git init
└───B2
└───.gitgit config pull.rebase false # mergegit pull --rebase
rm -rf ".git"git add . а индексировать только нужные файлы.
# Клонировать репозиторий с фильтром, чтобы не загружать все файлы сразу
git clone --filter=blob:none --sparse https://example.com/repo.git
cd repo
# Инициализировать выборочную загрузку
git sparse-checkout init --no-cone.git/info/sparse-checkout:# включить все файлы
/*
# кроме одной папки
!/node_modules/# Докачать всё, кроме папки node_modules
git sparse-checkout reapplynode_modules. Вы сможете работать с репозиторием, не загружая лишние данные. Если потребуется вернуть node_modules, достаточно удалить соответствующее правило из файла sparse-checkout и снова выполнить git sparse-checkout reapply