Hmm... I did mean those ancillary features in my comment too. But you will be incorrect by assuming you are not incurring into GitHub vendor lock-in also at the level of the git repository. There are TWO problems with GitHub on this regard (the first less problematic than the second):
1) GitHub Flow
GitHub imposes its own git workflow. This is fine, because GitHub Flow is really not a bad workflow. The problem is that if your project requires a different methodology, you'll have to face GitHub specialized UI which is tailored to their workflow. For instance, you cannot really emulate git-flow in GitHub; GitHub master is meant to be always deployable, however you branch/merge features and pull requests directly from/into master. Some gymnastics may allow you to work with git-flow under GitHub if you keep a separate repository that only merges the development branch into GitHub. But this is really just using GitHub to host code, not to actually work with it. Alternatively, you can just go ahead and create git-flow branches and instruct your users. But the UI defaults will be working against you all the time and you need to always remember to switch branches or point to a different target branch than the omnipresent master default. You are solving the problem by with increased complexity and a very real chance for mistakes.
GitHub Flow was designed out of the necessity to simplify the workflow of simple projects, which usually face constant and rapid deployment. And it works! I mean, it has too. A whole lot of people use it successfully. But I always like to take a step back on things that are popular choices and said to be "simpler and easier". I happen to not trust very much those two words on software development. I immediately become suspicious and try to see for myself.
And the thing is: Many projects on GitHub are not simple and do not have rapid deployment schedules. The lack of a development branch where a feature merge can go through a second screening layer (especially useful when you have many people working on different features) is begging for master branches with a higher rate of bugs. And I'm pretty sure (I haven't done a study on this) that the more complex projects on GitHub have higher revert rates and they bug trackers have a larger number of bugs, that aren't just a normal result of the project complexity, but are actually originated by the decision to employ GitHub Flow.
Workflow is a central aspect to version control. Git itself allows all manner of workflows. But GitHub imposes its own vendor lock-in on the user. And come the day you wish or need to migrate to another service (or host your own), you may not have the specialized GitHub Flow as an offer, which will complicate adoption and force you into complex project management decisions.
(2) Pull Requests
GitHub has its own implementation of pull requests, different from Git. And it is actually a bad implementation. It is odd that the very central feature of GitHub Flow is so weak. This is an old problem to some users and even Linus had something to say about it. Personally I find it ludicrous that you can't even tag a pull request. But in a nutshell, GitHub doesn't offer a patch culture to the collaborative development process. It completed discarded it between choosing to implement its own pull request module and forcing users into its own web interface for presentation and discussion of the pull request.
Come the day you need to change your source code hosting provider, you will almost certainly lose your entire pull request history due to GitHub vendor lock-in. The only thing remaining will be the pull request entry in your repository and the merge sometime later. I won't buy the argument that Git itself does not perform recording keeping of pull request discussions. It does not need to; Git is not an email program. But pull requests discussion is an essential function of pull-requesting/patching and it needs to be saved for future reference. Email and mailing lists have been the traditional safest method to do just that. For a reason.
Lack of text formatting features on the pull request message (one of the things that annoyed Linus) are another example of an implementation that will only work under GitHub. Migrate and you can bet all your pull requests messages will be a complete mess.
-----------------------------------------------------------------------------------
Now for something completely different
As I said before, I did mean to also include such ancillary features like the bug tracker, schedules, or wiki present in almost all popular SCMs. These are usually better understood in the context of vendor lock-in. It's like we give these features the vendor lock-in pass. As if they are not an important part of the development process, or they are hard features not to lock the user in. Needless to say I find that is a big mistake.
Bug trackers in particular are one of the saddest stories in software development. While we have successfully created all sorts of standards, unspoken rules, or tools with mass appeal, on about everything related to software development, bug trackers still suffer from a complete lack of powerful generic tools that a large part of the industry adopts as an unspoken standard, muck like Git, Mercurial and SVN have become de facto version control standards. And because of this it is reasonable to expect everyone and their mother want to implement their own bug tracker on their own source code hosting business.
(It is actually telling of us software developers, that we start to fail to care and come up with powerful solutions right on the frontier of our interaction with the real customers of our work. It does not speak highly of us. And despite having dealt with final customers -- along with the difficulties that entails. Oh, do I have stories! -- almost all my professional career, I can say I'm not one to come with the usual 'customers are dumb' jokes. And never liked to hear them. In almost 30 years of doing this I never forgot who I really work for and who really pays the bill. I wish more developers remembered too. And I wish more developers thought a little of what is that waiter thinking when we can't even make our minds about something as simple as the menu offerings.)
The problem however is that vendor lock-in can happen in here too, not because these features have been specially designed, but because the vendor does not offer access to the source code and database contents, removing from the user any chance to change or adapt the code, or use the raw data as a basis for the migration process. Such is the case of GitHub.