Answer to this specific question
I'm researching this myself and surprised at how many caveats there are.
You can just specify a local path as the source repository for git clone, so that's one way to start working on a codebase given to you e.g. as a zipped repo without worrying about its hooks, given that (at least as of June 2018) there are no hooks which are executed on a "remote" repository when it is being cloned.
But even then, you have to be careful to never accidentally run git push in your cloned repo afterwards, as it will trigger the "server-side" hooks in the original repo, again allowing arbitrary code execution! To eliminate the possibility of this happening, it's probably best to remove the reference to the original repo from the cloned repo's remotes altogether.
In conclusion, my suggested "workflow" for this would be:
# instead of cloning normally, we will use --mirror in order to exactly
# replicate the branches of the original repo; unfortunately, this implies
# creating a "bare" repo without working tree (think .git directory).
mkdir -p cloned_repo/.git
# --no-hardlinks to get a "proper" copy
git clone --no-hardlinks --mirror /path/to/original_repo cloned_repo/.git
cd cloned_repo
# turn this into a proper repo with working tree
git config core.bare false
git checkout HEAD
# check if the database has been tampered with
git fsck
# remove remote pointing back to the original repo
git remote remove origin
But it's entirely possible that I've missed yet more issues.
Circumventing the problem
If possible, you could also ask whoever gave you the repo to prepare it using git bundle instead (cf. How to git bundle a complete repo). Bundles can be cloned the same way you would clone a local repo and, to the best of my knowledge, can not contain hooks. In fact, they are specifically designed to enable "offline" git workflows (e.g. via files exchanged on flash drives) and you can also prepare bundles containing only parts of a repo's history.
