Glad you asked; I've been wanted to share. The simplest approach is to just use the default nix channel. For a team and production environment, this isn't idea

Glad you asked; I've been wanted to share. The simplest approach is to just use the default nix channel. For a team and production environment, this isn't ideal because you don't control when changes are made to your dependencies. So, we fork nixpkgs and rebase on our own schedule. This is also nice because it gives us an easy avenue to contribute upstream. Changes that may have community value go in this fork, nothing private. The fork is then squashed as a git subtree into our main repo. That way it's part of our history like everything else. You can even git-bisect with confidence in the face of many dependency changes! In addition, we have a tree of our own nix expressions for dependencies that are unique to us or that we haven't bothered to contribute back to nixpkgs yet. Sometimes this includes copying an expression for a dependency into our tree with a patch until the bug is fixed in an upstream project. The final result is one or many nix files reference our private nix expressions and nixpkgs subtree, intended to be used with nix-shell.