Repositórios Git são completamente independentes uns dos outros. Quando vc clona um repositório, vc está efetivamente copiando todo o repositório de origem para uma cópia local completamente independente da original. Ainda assim, é desejável ter um certo nível de sincronismo entre a "cópia de trabalho" e o repositório de origem (chamado de "upstream", ou "origin"). Por este motivo, existe um conceito chamado repositório remoto no git.
Seu repositório local pode ter quantos remotos forem necessários. Vc pode associar seus branches locais com branches de algum repositório remoto qualquer, e o Git te ajuda a manter os dois sincronizados através dos mecanismos de fetch (atualizar as referências/estado do repositório remoto no local, e.g. quais branches/refs existem no remoto, etc), push (envio de alterações/commits de um branch local para o repositório remoto) e pull (obtenção de alterações/commits remotos para um branch no repositório local).
Quando vc clona um repositório do Github no seu PC, vc está efetivamente copiando o repositório remoto (no Github) para o seu repositório local. Por padrão, o Git automaticamente associa o repositório no Github como um repositório remoto de nome "origin" na sua cópia local. Para cada checkout (mudança de branch) realizada localmente, e desde que a sua cópia local esteja atualizada, se houver um branch de mesmo nome no "origin", o Git é inteligente o suficiente pra entender que este branch possui associação com um branch remoto.
Se a intenção for criar um branch novo, vc pode fazer um checkout a partir de um branch pré-existente (git checkout -b) e criá-lo no remoto via push (git push --set-upstream).
Operações que envolvam algum repositório remoto (fetch, push, pull, etc) podem exigir permissões no repositório remoto, mas qualquer operação local (add, commit, checkout, etc) pode ser feita sem restrições, já que só dizem respeito ao seu repositório local.
No Github (e em qualquer SaaS Git de respeito), vc pode proteger o acesso ao seu repositório em vários níveis. Uma dessas restrições é a de proteger branches. Um branch protegido só pode ser alterado:
- Por administradores (caso esta opção não seja desabilitada nas configurações do repositório); ou
- Via PRs.
Ou seja, a única opção, caso vc não seja um administrador, é criar um novo branch a partir do estado atual do branch de origem (o que vc quer alterar), fazer as suas alterações e abrir um PR. Alguma outra pessoa do time irá revisar e fazer o merge (aplicar) das suas alterações (no branch protegido).
Dito isto, nem todos os branches são protegidos. Dadas as permissões corretas, vc pode muito bem criar novos branches em um repositório Github (o remoto), e pedir PRs para os branches protegidos quando vc terminar de fazer algum trabalho. (A propósito, este é o seu caso.)
Agora, se o desenvolvedor não fizer parte de um repositório Github, a única opção é fazer um "fork" desse repositório, o que é basicamente fazer um clone do repositório de origem inteiro, para que vc trabalhe de forma independente ao repositório de origem (chamado de "upstream", ou "origin" em alguns casos). O repositório clonado fará parte da sua conta, e vc poderá, por exemplo, cloná-lo para a sua máquina local. O Github é inteligente o suficiente pra entender se o seu repositório é um fork ou não.
Feito o fork, localmente (no seu PC), vc pode fazer um git clone; seu remoto será o "fork", não o repositório original. Efetuadas as alterações, basta dar um git push, e as atualizações locais irão para o seu repositório "fork" no Github.
No geral, a colaboração entre fork e upstream é feita da seguinte maneira:
- O repositorio fork precisa constantemente ser atualizado para que, chegado o momento, não hajam conflitos ao enviar as alterações realizadas do seu fork para o upstream.
- Chegado tal momento, o upstream recebe as alterações propostas por um fork por meio de um PR. O PR indica qual branch do fork será integrado a algum outro branch do upstream.