1. Handling GitHub API’s rate limits in the ``GitHubClient``: This can be accomplished by implementing a rate limit detection and backoff system. When a rate limit HTTP error is received from GitHub, pause the execution of that method for the necessary amount of time before the next API call is allowed. You may allow an optional retry policy in GitHubClient’s methods where it could automatically wait and retry after rate limit resets.

2. Handling private repos with ``GitHubClient``: To access private repositories, the access token provided to the GitHubClient should include the appropriate permissions (like repo, write:repo_hook). When generating a token on GitHub, there is an option to set these permissions.

3. Edge cases to consider when using ``GitHubClient``: A few possibilities include responding to errors like insufficient permissions, handling branch or PR conflicts, managing non-existent repositories or branches, execution during high API load conditions or when Github is down, and managing issues related to connectivity or request timeouts.

4. Extending this to support other Git platforms like Bitbucket or GitLab: We would need to create similar client classes for Bitbucket and GitLab. These classes should include methods covering the same functionality that is provided by GitHubClient, using the respective APIs provided by Bitbucket and GitLab. As an alternative, the GitHubClient class could be refactored into a more generic GitClient class which could be subclassed by specific GitHubClient, BitBucketClient, and GitLabClient implementations. This would allow for common features to be centralized in the superclass, reducing redundant code. However, this would require careful design to maintain flexibility for the unique aspects of each platform.