Menu
Although I love the git history rewrite feature, how does one go about ensuring history isn't rewritten.
We dont mind what a programmer does on their own machine, but we need to ensure that a version is not pushed to the server that changes history.
ie We need to guarantee that a particular version from the past really was that version. So this would include preventing someone going through and permanently removes a file from the history, or permanently alters a file throughout all history.
985
Prevent rewriting historyPrevents history rewrites on the specified branch(es) - for example by a force push or rebase.
To modify older or multiple commits, you can use git rebase to combine a sequence of commits into a new base commit. In standard mode, git rebase allows you to literally rewrite history — automatically applying commits in your current working branch to the passed branch head.
By rewriting a branch's history, past commits can be cleaned up and reorganized to make the commit history more readable. Commits can be revised, combined, split, removed, or even reordered. Although rewriting history can create a clearer commit history, it also comes with potential downfalls.
git commit –amend However, git commit --amend is a relatively safe command that helps you keep control of your checkpoint commits. This command takes your current changes, adds them to the previous commit, and lets you edit your commit message.
If you can run:
git config --system receive.denyNonFastforwards true on the server, that should take care of rewriting history case being pushed to said server.
However that is for the all repo, not for a specifc file or group of files.
git config:
receive.denyNonFastForwardsIf you rebase commits that you’ve already pushed and then try to push again, or otherwise try to push a commit to a remote branch that doesn’t contain the commit that the remote branch currently points to, you’ll be denied. This is generally good policy; but in the case of the rebase, you may determine that you know what you’re doing and can force-update the remote branch with a
-fflag to your push command.The other way you can do this is via server-side receive hooks, which I’ll cover in a bit. That approach lets you do more complex things like deny non-fast-forwards to a certain subset of users.
As ebneter (who knows the importance of a coherent repository -- see the answer about SVN to Git migrations [question now deleted, 10K+ users only]) comments:
You might want to also add
receive.denyDeletes truebecause otherwise, someone can just delete the branch and then push their rewritten one as a new branch, effectively rewriting history.
git config:
One of the workarounds to the denyNonFastForwards policy is for the user to delete the branch and then push it back up with the new reference. In newer versions of Git (beginning with version 1.6.1), you can set
receive.denyDeletesto true:
$ git config --system receive.denyDeletes trueThis denies branch and tag deletion over a push across the board — no user can do it. To remove remote branches, you must remove the ref files from the server manually. There are also more interesting ways to do this on a per-user basis via ACLs, as you’ll learn at the end of this chapter.
159
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
