I should have clarified; sorry. I was referring to how some editors and IDEs can interact with git repositories. For instance, if I was editing a file that had uncommitted changes, it might display that text in a different colour. Interaction with GitHub might be in the form of browsing pull requests within the IDE.
This is what I do with Emacs using a package called Magit[1]; VS Code comes with something similar.
I think they mean a desktop GUI application on top of git like GitKraken or SourceTree. These sometimes allow you to perform actions like creating a PR (which is not done via git itself, of course).
> but you still need a Personal Access Token to integrate pull requests and issues with your Git client
(Nitpick from a former GH employee) PATs really are almost exclusively intended for personal testing with curl and such. The strongly preferred way for apps like you describe to work is a pseudo-OAuth flow (“GitHub Apps”) which yields a token that is not a Personal Access Token. Better in just about every way: more ergonomic, more secure (revocable, shorter duration, predictable fine grain scope with a mechanism for requesting additional permissions as apps change, etc), and requests are attributable to the application which generated them instead of just the user. If you use an app that actually requires generating and pasting a PAT, it’s either extremely old or made by someone who is not prioritizing security and user experience. It even works well in CLI apps, cf. the `gh` command line utility.
