There isn't really a satisfactory solution.
Git was designed for a distributed group of people to work on Open Source software, so it doesn't really feature things like access controls. In particular, branches just describe different strands of development history, and aren't useful for describing different editions of the same software.
One approach is to work on an internal repository, then regularly export snapshots to a separate, public repository. During this export step, you could ignore some files. But the two repositories must not share their Git history. Note that this approach will complicate dealing with outside contributions.
It's also possible to to the inverse: work mostly on the public repository, but occasionally merge it into the internal repository. In principle, the internal view could just be another branch that you don't push to be a public repository.
For a lot of projects that have some sensitive parts, it is more appropriate to define extension points in the Open Source version, and to implement the internal features as plugins. These additions might either be inserted at runtime, or during your internal build process.
Your examples relate to more to tooling around the software, not to the software itself.
Consider whether they should be part of the repository in the first place. Secrets should be never committed, not even for purely internal repos. Instead, CI environments offer tools to manage secrets such as API keys.
Consider whether you actually have to remove this configuration from a public version. For example, if you develop the project in an Open Source first manner, then you will likely want to run CI jobs on that version as well. Even if not, it can be OK to include files that don't have value outside of your organization (if they don't disclose anything sensitive).
Quite often, such issues can be avoided by keeping environment-specific details out of the repository. For example, instead of hardcoding a Maven URL, you might require developers to set an appropriate environment variable. Instead of having a complex CI pipeline, you might have a simple pipeline definition that just calls into an environment-independent build script that contains the actual steps.
I've linked to the 12 Factor App here, because it is a great (albeit dated) condensation of best practices mostly for web apps, SaaS, and cloud-native software. Many of those lessons are also applicable in an Open Source context, and also for different kinds of software.