Given that:
The manifest describes user intent, and the lock describes computed outputs. There's flexibility in manifests that isn't present in locks..., as the "branch": "master" constraint will match whatever revision master HAPPENS to be at right now, whereas the lock is nailed down to a specific revision.
This flexibility is important because it allows us to provide easy commands (e.g. dep ensure -update) that can manage an update process for you, within the constraints you specify, AND because it allows your project, when imported by someone else, to collaboratively specify the constraints for your own dependencies.
Reference: https://github.com/golang/dep/blob/master/docs/FAQ.md
Yes, in order to ensure a reproducible build.
There's flexibility in manifests that isn't present in locks..., as the "branch": "master" constraint will match whatever revision master HAPPENS to be at right now, whereas the lock is nailed down to a specific revision.
Anyone cloning your Go project repository with a lock file will get the exact SHA1 of the dependencies.
You can still update that lock file anytime you want, and version its updated content.