Making a Git + Jenkins Server: non-bare repository vs bare repository?

Question

My team's source version control system is currently migrating from SVN to git.

I've been using GitHub for a while, but it's my first time building an actual git server from scratch, so I'm going through git basics.

I came across a documentation that says it's better to make the shared server a bare repository rather than a non-bare repository.

But if the server is planned to have an automated deployment system like Jenkins, it seems to me that project source files need to be there, which bare repos don't have.

So I came out with a conclusion with 2 choices, but can't seem to decide which one's better.

1. Make the repository non-bare.
2. Clone a non-bare repository and build from the cloned repository.

How can I set up the repository in order to enable automated deployment system?

Answer 1

A bare repository is the best practice when you need to directly push to it.

A Jenkins agent would checkout the same repository in its own dedicated job workspace, so that would not be the same repository anyway.

And if you need to trigger a deployment when pushing to said bare repository, you can add to that bare repo a post-receive hook, which will do the checkout for you, as seen here.