How long does git keep out-of-branch commits?

Question

Assume I create a branch in my local repository named feature1 based on master and add one or two commits. Then I switch back to master and decide that feature1 is not going to make it and delete the branch.

I assume that a branch is basically a "pointer" to a particular commit object.

Now on to the actual questions.

1. Is the assumption above correct, perhaps in some simplified sense?
2. For how long do the commit objects still exist on the filesystem (so that I can later do git checkout SHA1-HERE)? Is there some kind of "retention policy" that would remove commits which are not part of any existing branch history or tag (not sure if using correct terminology here...) ?
3. Would any of the above be dependent on the git server's implementation (gitosis, github, etc...)?
4. If the objects are kept around forever and are not auto-cleaned after some time/event, would it imply that setting git's receive.denyNonFastForwards as a measure to prevent data loss is meaningless?

Reason for this question: I am currently working on a project that has receive.denyNonFastForwards enforced on the basis that it avoids losing any committed work (I suspect receive.denyDeletes is also enforced). I want to make sure there is no better way to preserve commited but unmerged work and also be able to clean up old branches to avoid clutter.

Answer 1

The default s 90 days:

gc.reflogexpire
gc.<pattern>.reflogexpire

git reflog expire removes reflog entries older than this time; defaults to 90 days. With "<pattern>" (e.g. "refs/stash") in the middle the setting applies only to the refs that match the <pattern>.

So:

1. Yes
2. 90 days
3. no (you actually can contact GitHub support to ask them and restore a deleted pushed branch)
4. "preserve commited but unmerged": you can push it on a dedicated dev branch or to a dedicated upstream repo (just for you)