A common source of timeout on fetch (clone) is incorrect or missing credentials. If your repository is private and you have not assigned credentials during the checkout, the checkout may fail with a timeout rather than providing a clear error message that access was denied.
A less common source of timeout on fetch (clone) is embedding the username / password credentials directly into the https URL. JENKINS-41066 describes that problem for Bitbucket, GitHub, and Visual Studio Online repositories.
Another less common source of timeout on fetch (clone) is using the wrong type of credential. The git plugin supports username / password credentials with https URL's to the repository, and it supports private key credentials with ssh/scp URL's to the repository. It does not support private key credentials with https URL's. It does not support username / password credentials with ssh/scp URL's.
If you've verified that credentials are assigned to the pipeline checkout command correctly and are working as expected (for example, the log file includes progress indicators which show that it has started to read some of the repository, but then that operation is killed after 10 minutes), then you probably need to extend the timeout with the CloneOption rather than the CheckoutOption.
Use the "Pipeline Syntax" link on the job definition page, select "checkout: General SCM" from the drop down list, and select Git as the SCM. It will allow you to add "Additional Behaviours" including "Advanced clone behaviours". Within the "Advanced clone behaviours", you can define a reference repository (local pointer to a bare git repository which acts as a cache to reduce data transfer time) and you can define the timeout for clone.
If you have a slow local file system (SMB/CIFS, NFS, AFS, etc.) and a large repository, you may find that the checkout option also needs a timeout value set. That is much less common, and usually means that you should improve the performance of your file systems rather than increase the timeout of the checkout.