„Floating“ commit in git
In a project of ours we have, as usual, a master branch. Based on that is the deployment branch, where the settings are modified. Also based on that is a mirror branch that runs the mirror of the deployment. The master branch ought not contain any config changing patches.
Small features and fixes are developed in the mirror branch. So after adding a feature, it looks like this:
- Combining non-linear commits into one commit (sausage making)
- How do I get git branch history to match master after a squash rebase?
- GIT Rebase a Branch that is collaborated on?
- Is it right to use git cherry-pick in these scenarios?
- How can I rebase from specific develop branch commit to specific master branch commit
- Git-Stash: Is there a way to prevent merge feature to develop without rebase?
master: history ┐ deployment: ├─ deployment-config mirror: └─ mirror-config ── feature
Now to move the feature back into master, I first have to reorder the patches in the mirror branch:
master: history ┐ deployment: ├─ deployment-config mirror: └─ feature ── mirror-config
Now I can fast-forward-merge that into master
master: history ┬─ feature ┐ mirror: │ └─ mirror-config deployment: └─ deployment-config
And then merge master into mirror, and rebasing it onto master
master: history ── feature ┐ mirror: ├─ mirror-config deployment: └─ deployment-config
Is there a plugin or tool that would automate that, so that
- every new commit is automatically applied „below“ the top commit,
- every merge or cherry-pick is also automatically applied „below“ the top commit,
- a merge from such a branch pulls from the state „below“ the top commit?
2 Solutions collect form web for “„Floating“ commit in git”
In general I would recommend to try and get away from that config commit situation. Can’t you just store the config on your deployments? Or use smudge filters, as I explained here: https://stackoverflow.com/a/13616911/758345
If that’s not an option, let me answer your questions, as there are simpler ways to achieve what you want thanks to the fact that branches in git are so light-weight. None of these are a complete automation, but quite simple and you could definitely write some small scripts for that.
every new commit is automatically applied „below“ the top commit
Not quite sure about the situation, but assuming you made changes and want to commit them:
- Remember your current branch-head’s SHA
- Stash your changes
git reset --hard HEAD^
- cherry-pick your old branch-head
every merge or cherry-pick is also automatically applied „below“ the top commit
same as above:
reset --hard, do your work, cherry-pick old branch head
a merge from such a branch pulls from the state „below“ the top commit?
This one is very simple:
git merge mybranch^
If you do not want to change your working dir, and the files modified by your “config commit” are not touched by your other operations, you can do this:
- Remeber your current branch-head’s SHA
- Do a soft reset:
git reset HEAD^
- Make git ignore your config files via
git update-index --assume-unchanged
- create your commit
git update-index --no-assume-unchangedfor your config files
- commit again – this will recreate your config files.
If you automate this via script, you can use git to get a list of config files for
--assume-unchanged by looking at the config commit. If you do not want to automate this, you can skip step 3 and 5, and just make sure you don’t commit your config files in step 4.
What can automate the reordering is a
git rebase -i --autosquash, which can reorder / squash commits for you, based on the commits message:
If you know what commit you want to squash something in to you can commit it with a message of “
Then if you run
git rebase --interactive --autosquash commitish, the line will automatically be set as
squash, and placed below the commit with the subject of
(More details in the second part of “Trimming GIT Checkins/Squashing GIT History”)
That could be an idea to facilitate the reordering of the ‘feature’ commits together, especially if you have “feature” and ‘mirror-config’ commits mixed together.
Once reordered, a
rebase --onto can move those feature merge to the right branch.
See for instance “Complex git rebase maneuver”.
Beside that, I don’t know of any plugin which can automate those tasks: there are all about