git-gud
git-gud copied to clipboard
Why not to commit passwords (It's hard to remove things in Git)
Roughly taken from thomasdriscoll/open-source-illinois-web.
This looks bad, but it gets worse. There's still Kary's branch that has changes. Kary pulled the changes from the middle of the working tree, so we need to preserve the commits.
Another lesson here would be to not commit large files that you don't want to download every time you clone and have in the git history. A solution in this case would be to instead
Levels to stem from this:
- Removing a commit through an interactive rebase in a linear tree
- Removing many commits through reverting then squashing
- Trying to remove many commits in a tangled tree like below through reverting then squashing (this won't work, and would be very hard because the changes won't match up and whenever there are merge conflicts, you would have to solve them again and it wouldn't be clear how to do that)
- Removing many commits by branching from a commit before the accident and just checking out a fixed commit.
- Given the last one, also logging the commit messages from the previous commits in the new commit
- Preserving the branching history and all but the broken commit branching history by cherry-picking and gymnasitcs
- Removing many commits but leaving some so that the branches don't have issues later on (still a lot of work, but potentially less)
- In any of those situations above, needing to make sure that all the loose (unmerged) branches do not have the password in them
The reason you would want to preserve the history rather than just saving the current version in a new commit is that people who have forked or merged from any of those commits will have issues when merging
Plaintext description of Kary's branch:
- forks from commit very far back in the history
- pulls from a commit on master before the bad changes started
- pulls server/master, incorporating the bad changes
- has several commits after this
- thomas/master has several commits after server/master too
Other lessons:
-
git checkout $HASH -- .to get the changes from a merge when updating (just make sure to remove the file with the password) - Don't commit large files
- Don't commit passwords
- Don't commit configuration files that could reveal your production setup and potentially also vulnerabilities specific to your setup
- If you're committing a large file, you could solve with another method. There is a git command to have a commit reference another commit but by default not check out the rest of the history. It behaves as it's the initial commit, but git behaves specially in other situations.
- TODO: To solve the above, google "What to do when git history gets too big" or similar
* 8b2f146d (server/master, server/HEAD) Made updating prod easier
* 88bcb290 Running dev server stuff
* d5a9b353 nice looking members page
* 32821d40 (tag: goodstuff) updated project page
* 986f977f (tag: three) Merged completed sidebar
|\
| * dcf66dba Merge branch 'thomas/master'
| |\
| | * bd592953 Merge pull request #27 from gprakarsh/production
| | |\
| | | * 8641257b Finished sidebar
| | | * 242ca357 Added mobile styles
| | | * 4c7a3763 Removed styling from sidebar
| | | * d9771f53 (tag: added-password) Initialized dev environment (and added password!)
| * | | eda27b30 (tag: efficial) Merge branch 'thomas/master' into master
| |\| |
| | * | f15d554c (tag: efficient) Efficient redirects
| | * | 5ea04aa2 Added server run command
| | * | 507af3dd Removed nginx static serving
| * | | 94656b99 updated docker file
* | | | ffd1f8e8 (tag: prettify) Prettyifying projects page
* | | | a64a57d3 Connected to database
* | | | 79de34c5 Merge branch 'thomas/production' into production
|\ \ \ \
| | |/ /
| |/| |
| * | | 5a9101f7 Changed to prod port
| * | | f098dab6 Added server config files
| | |/
| |/|
* / | b61b9257 Saving nginx setup before pulling nginx folder
|/ /
* | 6728dd97 Trying something
* | 8c7347a8 Stack trace
* | 436c8626 Updated environments
|/
* 367f6809 (tag: bottle) Merge remote-tracking branch 'origin/master'