Flight rules for Git – What to do when things go wrong
github.com
github.com
wording there is a bit dangerous, see this snippet from `man git-gc`:
Some git commands run git gc --auto after performing operations that could create many loose objects.
After that, then the object is subject to pruning by `git gc`, and may go immediately, or up to 14 days later, depending on the packing. That 14-day grace period is there for objects that never got referenced in the first place (so a tree that you are building to make a commit, for example, would not go away before you run `git commit`).
Edit: Hang on it's worse then that, it just says 'always force push your changes' - wonderful, you might drop commits that were previously on the branch head that someone else has pushed. Hooray.
0. Be on local branch "foo". If you've just tried to pull and got conflicts, abort the merge. (Note that for this to work reliably, you should never pull without first committing or stashing your changes):
git merge --abort
git checkout -b m
git merge origin/foo
git merge [hash of some intermediate commit on origin/foo]
git checkout foo
git merge m
git branch -d m
git pushMore needs to be written on this though, thanks for pointing it out
Similarly the git development involves many throw-away branches, plus the "next" branch may get rebuilt every time there is a release.
People often say: "don't rewrite public history" but that's a simplification of: "don't rewrite public history unless people should have already known it was going to be rewritten"
If someone checks-out a branch from my private fork instead of from the official repo, they better not complain to me that I rebased it. Similarly if they checkout a branch named throwaway/test-integration-of-foo
1. Never do work on a branch that is being tracked on the origin. Always segregate your work on a local-only branch by doing a 'git checkout -b my-work'
2. Since I prefer not to have merge commits that don't add value to the history, I always get the latest changes, and rebase my-work off the latest. i.e.,
git checkout develop (being tracked on the origin)
git pull (get latest changes)
git co my-work
git rebase develop
git co develop
git merge my-work (no merge commit as it's fast forwarded)
git push
git branch -d my-workBtw, Mercurial Evolve makes this completely safe for hg. No more warnings about "git push -f"!
Scenario: "When I try to push, I get an error message"
Answer: "...you must force push (-f) your changes"
A newbie could follow that advice and blow away their teammates' commits. Better advice would be to think twice and then consult someone with more experience before you even think of using git push -f.
Eg, you've done work on a branch, and then attempted to pull in recent updates from master, but now while trying to commit there are a huge number of changes listed that you don't recognize.
In my experience this is a sign you've done something wrong (merge instead of rebase?) and what you do next can cause a commit that undoes your colleagues recent work. It's a minor inconvenience and not a permanent loss, but it's a common mistake to make when you don't have experience with multi-user git projects.
“Checklist” is the word for this. Checklists are widely used in aviation (they seem to have one for every case). I don't hear this term often in software engineering context, though Wikipedia says QA practices make use of checklists, too.
However the commands are a little haphazard and as Gabe (gkop) mentions, not entirely safe.
git reset --soft HEAD~N
This rolls back the history and places all the changes in those commits into staging. Commit with a new final message and off you go.
* If the credentials have already been written into shared history (e.g. merged into origin/master), regenerate the credentials ASAP. If the credentials are in local revisions only, use interactive rebase to edit the commit(s) in question.
* Introduce tooling to create better separation between dev and production credentials. Most automated tests should be able to run using bogus credentials. Pre-commit hooks can attempt to scan for accidental credential inclusion. Use a config system that loads credentials based on environment.