Should microservices be separated based on business logic or based on programming responsibilities?

Let's say my overall system includes the following business domains (among other business domains)

• Searching for types of files in a GitHub repo
• Checking in files to a GitHub repo

One possible way to divide these into services is like

• Service 1: Searcher Service
• Service 2: Checkin Service

Both services will have to know how to connect to a GitHub repo. For single-responsibility and code reuse, a couple ways I can think of structuring this are

Option 1:

• Service 1: Searcher Service
• Service 2: Checkin Service
• GitHub general-use client library used by both services

Option 2:

• Service 1: Searcher Service
• Service 2: Checkin Service
• GitHub General-Use Service (does searches, checkins, etc., thus the other 2 services are like "business logic wrappers" on top of this service, whereas this service doesn't understand any business logic)

Option 3:

• Single 1: GitHub Everything Service

Which is the best, and why (i.e. what principles dictate why)?