Qual é a diferença entre dominar e desenvolver um ramo em Git?

Não há essencialmente nenhuma diferença a não ser os nomes dos ramos. Git não coloca restrições aos nomes dos ramos e como tal você pode chamar os seus ramos de qualquer coisa que você gostaria. Por convenção os desenvolvedores irão usar um branch "master" para ser a cópia base do código, é para este branch que todo o código sendo escrito em diferentes branches será eventualmente fundido, e representará a versão atual lançada da aplicação sendo desenvolvida. O "Develop", como o nome sugere, é normalmente usado como uma espécie de ambiente de encenação, ou ambiente de teste, no qual todos os ramos de novas funcionalidades/correção de correções serão fundidos para estabelecer os efeitos do novo código, bom ou ruim, antes que seja permitido fundi-lo com o ramo "master".

Os nomes são apenas a convenção aceita porque fazem sentido no contexto em que estão sendo usados, e foram adotados pela comunidade em geral.

A implementação exata da estratégia de controle de versão que você e sua equipe escolhem utilizar depende do tipo de aplicação que você está criando e do processo mais eficiente para a equipe trabalhar, pois quanto mais pessoas trabalharem nos mesmos arquivos/classes, etc. mais provavelmente a chance de problemas decorrentes de repositórios e fluxos de trabalho mal gerenciados.

Git fornece todas as ferramentas para permitir que grandes equipes colaborem de forma eficaz e eficiente em projetos de quase qualquer tamanho.

Uma estratégia que foi usada por uma empresa que eu costumava trabalhar para isso eu achei particularmente bom trabalhar algo como isto:

Origin - Repositórios remotos armazenados em uma instância interna do GitLab

Master - A versão atual da aplicação, etiquetada com um número de versão como v1, v2 etc. Isto se referia ao número da versão principal. Mudanças de código que foram assinadas no ramo de desenvolvimento seriam lançadas periodicamente como versões menores, tornando a tag algo como v2.3, v3.1 etc. Lançamentos de versões maiores ocorreram muito menos frequentemente e foram geralmente agendados com muito tempo de antecedência, como anexado a talvez um aviso de 2 ou 3 semanas de uma data de lançamento de uma versão menor para o ramo team.

Develop - Staging environment for testing code that will be released with next push to the master branch. Estes lançamentos adicionariam um número de versão menor à tag no ramo mestre, a menos que houvesse mudanças significativas ou de quebra sendo fundidas. As datas de lançamento foram agendadas e portanto se seu branch não foi fundido e testado no desenvolvimento por uma data de corte, ele teria que esperar pela próxima versão.

Fature Branches - A maioria do trabalho foi realizada em branches de características individuais que, como o nome sugere, introduziram uma nova característica ou processo na aplicação. Ele foi sempre criado a partir do ramo mestre, para que todos eles estivessem começando a partir do estado atual de lançamento da aplicação. Estas características eram então enfileiradas sob uma etiqueta de data de lançamento, e foi criada uma data de corte para que as fusões se desenvolvessem. Todo o ramo de desenvolvimento seria então integrado ao master na data de lançamento.

Hot-fix Branches - Novamente, como o nome sugere, um ramo hot fix foi usado para retificar um bug dentro da aplicação. Estas foram a exceção à estratégia de data de lançamento. Um branch foi criado a partir do master, o bug corrigido, e então mesclado para desenvolver. O branch seria então integrado diretamente ao master, ao invés do branch de desenvolvimento, pois isso envolveria a escolha da cereja para assegurar que apenas a correção do bug fosse integrada.

A estratégia descrita acima é bastante comum, e na minha experiência funciona muito bem, desde que todos os membros da equipe entendam e sigam as regras e convenções requeridas pela estratégia.

Eu espero que isso ajude a entender a relevância dos nomes dos branches dentro do git.