Git.аналог svn dcommit для git-репозиториев

Question

Я хочу использовать следующий типичный рабочий процесс:

1. создать новую ветвь для функции и оформить ее
2. сделать коммиты в ветви функции
3. мастер проверки
4. объединение с функциональной ветвью.
5. push изменения

Это очень типичный вариант использования.Тем не менее, есть одна вещь, которая раздражает меня - я не хочу показывать, что моя ветвь обязывает публику.Я просто хочу выдвинуть только коммит слияния, без истории развития функций.

Можно предложить использовать git rebase для сжатия коммитов.Но на самом деле такое сжатие - это просто обходной путь, а не реальное решение.Я хочу, чтобы все мои коммиты были локально, граф слияния, для целей истории.

Я хочу получить то же самое, что я получаю с помощью git svn dcommit - на удаленный удален только коммит слияния, но я вижу локально всю историюразработки, с фиксацией объекта, с узлом слияния с двумя родителями и соответствующим графом слияния.

Answer 1

Если я вас правильно понимаю, вы хотите иметь один коммит (то есть один SHA1), но вы хотите, чтобы он выглядел по-другому на вашей копии хранилища, чем на центральной копии.

Выполнение этогопросто невозможноGit был сделан так, что этот способ невозможен.Если вам известен идентификатор SHA1 коммита в репозитории, вы можете быть уверены, что знаете всю его историю.

Но есть один способ подделать это: использовать grafts .Таким образом, вы можете добавить родителя в коммит, фактически не изменяя его.Хотя я не совсем уверен, что это хорошая идея.

Answer 2

Исходя из ваших комментариев, вот еще одно решение: Работайте в тематических ветках, как обычно.При необходимости объединяйте ветки объектов в мастер, как обычно.Прежде чем вы нажмете на удаленное устройство, выполните слияние сквоша с отдельной ветвью и нажмите эту ветку на удаленную ветвь.Пример:

# Create two repos for testing
mkdir test-git-merging
mkdir test-git-merging2
cd test-git-merging2
git init
# Have to set this flag to be able to push with master checked out
git config receive.denyCurrentBranch ignore
cd ../test-git-merging
git init
# Base commit in first repo
git commit --allow-empty -m "init"
# Create the branch that will be pushed to the remote
git branch remote-master
# Make some files and commit them in master
echo foo >> foo
echo bar >> bar
git add .
git commit -m "added files"
# Make a change on a branch
git checkout -b branch
echo 1 >> foo
git commit -am "Modified foo"
# Make a non-conflicting change in master
git checkout master
echo 2 >> bar
git commit -am "Modified bar"
# Do a normal merge from branch to master--normal history
git merge branch
# Squash merge from master to special remote branch
git checkout remote-master
git merge --squash master
git commit -m "Everything is squashed"
# Set up the remote and push config
git remote add other ../test-git-merging2
git config branch.remote-master.remote other
git config branch.remote-master.merge master
git config push.default tracking
# Push the branch
git push

Я протестировал эту последовательность команд, чтобы убедиться, что она работает.Конечно, удаленный мастер филиала по-прежнему никогда не будет иметь реальной истории, а это означает, что всегда будет опасно возвращать материал из него в ваши рабочие ветви, но это, по сути, то, о чем вы просите.

Answer 3

Вы можете попробовать

git merge --squash <feature branch>

Это будет делать все, что вы хотите, за исключением того, что ветвь фактически не считается объединенной.