I prefer the first example. Of course, is tightly coupled by Guzzle, but you don't change the HTTP Client every day.
However, if you really want to be more general, you can use the second option with a little "upgrade": use a contract (interface) to represent the type hint into the constructor. Like you define the constructor now, the Github class is tightly coupled by Guzzle client (and you go back to the first example).
I don't mind coupling it to Guzzle either although I personally got really used with the last example because as your client might get more complicated (request logging, different authentication strategies, handling failed requests, refreshing tokens, etc.), it is pretty cool that you can extract all of that stuff to dedicated classes.
I prefer the first example. Of course, is tightly coupled by Guzzle, but you don't change the HTTP Client every day.
However, if you really want to be more general, you can use the second option with a little "upgrade": use a contract (interface) to represent the type hint into the constructor. Like you define the constructor now, the Github class is tightly coupled by Guzzle client (and you go back to the first example).
I don't mind coupling it to Guzzle either although I personally got really used with the last example because as your client might get more complicated (request logging, different authentication strategies, handling failed requests, refreshing tokens, etc.), it is pretty cool that you can extract all of that stuff to dedicated classes.
All of them are equally coupled to Guzzle: "use GuzzleHttp\Client;"
There's no way to not couple some bit of your code to Guzzle if you use Guzzle, is there?