4 ms·

This really should be the top comment here. Learning about the non-destructive nature of Git really helped me overcome the unease around using some of Git's mor

This really should be the top comment here. Learning about the non-destructive nature of Git really helped me overcome the unease around using some of Git's more advanced features (especially in a team environment).

thanatos_dem 7y ago
Once I learned about the reflog I got a lot more adventurous with git. Now I’m the “git expert” in my team.
Buttons840 7y ago
Yep. Specifically, git will never delete a commit, unless it is old (like 30 days old or older I think?) and is not part of a branch. I suppose there may be some arcane commands to force a deletion, but it wont happen by accident or by normal usage. Like you, I felt much more comfortable using git after learning this.
- dahart 7y ago
  > git will never delete a commit, unless it is old (like 30 days old or older I think?) and is not part of a branch. Yeah, completely unreachable commits have 30 days, even when you run git gc. The default reflog for a branch is even longer: 90 days! https://git-scm.com/docs/git-gc https://git-scm.com/docs/git-gc
- MichaelMoser123 7y ago
  How comes that I see older commits with git log -p ? I can even see what the commit changed.
  - tomcatfish 7y ago
    Those commits are referenced. Parent comment is talking about commits that have no references to them (ie. You make a commit then remove all traces of it, it is not gone completely until after a certain amount of time).
- shandor 7y ago
  This is also why commiting very often is a very good idea. I often try to reassure people new to git that "if you'll just commit often, there's basically no way you can lose work so that I can't help you get it back. Apart from deleting the whole repo folder. Don't delete the repo folder.". I also have the habit of preventing non-fast-forward pushes on origin/master, which also helps when I can tell my team that they can't trash the origin even if they try.
  - kohtatsu 7y ago
    Which merge strategy do you recommend? # Merge commit git merge --no-ff -m <message> <hash> # Squash and merge git merge --no-commit --squash <hash> git commit -m <message> # Rebase and merge git rebase --force-rebase <hash> From https://stackoverflow.com/a/52301456 https://stackoverflow.com/a/52301456
    - shandor 7y ago
      I...have to admit that my merge strategy, and what I teach my teams, is "don't" :) (only slightly tongue-in-cheek) I believe in clean, linear history, and strongly prefer rebase-based workflows to merges. That's actually one of the reasons I chose Phabricator for my current place, as it is also very opinionated towards the same way of working. Edit: oh, and to answer your actual question, the third one.
      - greyskull 7y ago
        +1. Interactive rebase to squash your feature branch, then ff merge into master/mainline. Years ago when I was just reading about git instead of using it, I saw sentiments along the lines of "always use feature branches and merge them so your thoughts and process can still be looked at later". In the last ~5 years or so I've worked professionally, I've not once wished I could reference intermediate commits in my own code or someone else's. I've found that ambiguities and clarifications can and are caught during the code review process. I'd say another couple of benefits: - It's relatively easy to teach git workflows when the log/graph is linear, and similarly it's _way_ easier to reason about your workspace when you have an actual production codebase. - Merge commits can make certain operations like reverts and patches harder to reason about
kradroy 7y ago
I had to do a git history rewrite via "git filter-branch" and one other method. I can attest that you really have to go out of your way to actually permanently get rid of anything in a git repo. It's always funny to me when I see an engineer have a panic attack the first time they think they've trashed the repo and lost important code. They always have that same look as relief washes over them when I show them how to recover from the mistake.
rags2riches 7y ago
Git is non-destructive and its great. Until you learn why the really dangerous command nobody talks about is git checkout.
- lisper 7y ago
  Or until you accidentally check in a file that contains a secret. Then the non-destructiveness becomes a serious problem.
  - palunon 7y ago
    Two possibilities there: either your secret was published to others, and it's not a secret anymore, or it wasn't, and you can easily remove it. (Even from your local repo, if necessary remove the relevant blob hash)
    - kkarakk 7y ago
      Easy to say but a chinese dev went to prison for pushing DJi's secret crypto key to github

thanatos_dem 7y ago

Once I learned about the reflog I got a lot more adventurous with git. Now I’m the “git expert” in my team.

Buttons840 7y ago

Yep. Specifically, git will never delete a commit, unless it is old (like 30 days old or older I think?) and is not part of a branch. I suppose there may be some arcane commands to force a deletion, but it wont happen by accident or by normal usage. Like you, I felt much more comfortable using git after learning this.

dahart 7y ago
> git will never delete a commit, unless it is old (like 30 days old or older I think?) and is not part of a branch. Yeah, completely unreachable commits have 30 days, even when you run git gc. The default reflog for a branch is even longer: 90 days! https://git-scm.com/docs/git-gc https://git-scm.com/docs/git-gc
MichaelMoser123 7y ago
How comes that I see older commits with git log -p ? I can even see what the commit changed.
- tomcatfish 7y ago
  Those commits are referenced. Parent comment is talking about commits that have no references to them (ie. You make a commit then remove all traces of it, it is not gone completely until after a certain amount of time).
shandor 7y ago
This is also why commiting very often is a very good idea. I often try to reassure people new to git that "if you'll just commit often, there's basically no way you can lose work so that I can't help you get it back. Apart from deleting the whole repo folder. Don't delete the repo folder.". I also have the habit of preventing non-fast-forward pushes on origin/master, which also helps when I can tell my team that they can't trash the origin even if they try.
- kohtatsu 7y ago
  Which merge strategy do you recommend? # Merge commit git merge --no-ff -m <message> <hash> # Squash and merge git merge --no-commit --squash <hash> git commit -m <message> # Rebase and merge git rebase --force-rebase <hash> From https://stackoverflow.com/a/52301456 https://stackoverflow.com/a/52301456
  - shandor 7y ago
    I...have to admit that my merge strategy, and what I teach my teams, is "don't" :) (only slightly tongue-in-cheek) I believe in clean, linear history, and strongly prefer rebase-based workflows to merges. That's actually one of the reasons I chose Phabricator for my current place, as it is also very opinionated towards the same way of working. Edit: oh, and to answer your actual question, the third one.
    - greyskull 7y ago
      +1. Interactive rebase to squash your feature branch, then ff merge into master/mainline. Years ago when I was just reading about git instead of using it, I saw sentiments along the lines of "always use feature branches and merge them so your thoughts and process can still be looked at later". In the last ~5 years or so I've worked professionally, I've not once wished I could reference intermediate commits in my own code or someone else's. I've found that ambiguities and clarifications can and are caught during the code review process. I'd say another couple of benefits: - It's relatively easy to teach git workflows when the log/graph is linear, and similarly it's _way_ easier to reason about your workspace when you have an actual production codebase. - Merge commits can make certain operations like reverts and patches harder to reason about

kradroy 7y ago

I had to do a git history rewrite via "git filter-branch" and one other method. I can attest that you really have to go out of your way to actually permanently get rid of anything in a git repo. It's always funny to me when I see an engineer have a panic attack the first time they think they've trashed the repo and lost important code. They always have that same look as relief washes over them when I show them how to recover from the mistake.

rags2riches 7y ago

Git is non-destructive and its great. Until you learn why the really dangerous command nobody talks about is git checkout.

lisper 7y ago
Or until you accidentally check in a file that contains a secret. Then the non-destructiveness becomes a serious problem.
- palunon 7y ago
  Two possibilities there: either your secret was published to others, and it's not a secret anymore, or it wasn't, and you can easily remove it. (Even from your local repo, if necessary remove the relevant blob hash)
  - kkarakk 7y ago
    Easy to say but a chinese dev went to prison for pushing DJi's secret crypto key to github