Git Staging: Quando encenar? O que fazer se a modificação ocorrer posteriormente

Sou um pouco novo no amplo mundo do Git. Eu li o manual e tenho praticado, mas estou confuso sobre alguns aspectos dele, que não consegui descobrir depois de pesquisar.

Eu estou pensando:

• Em um projeto (após a primeira confirmação), quando é o momento certo para preparar os arquivos de origem? Logo antes de cometer? Logo após adicionar / excluir ou modificar?

• Se os arquivos são testados no meio do caminho entre duas confirmações e depois são modificados, o que acontece com o Git? Ele precisa se preocupar com as alterações de conteúdo quando foi declarado e o que se tornou desde então?

• Se eu criar um novo arquivo, prepará-lo e depois deletá-lo, por que o Git me pede para usar o sinalizador "-f" e um simples "git -rm file.ext" não funciona?

Eu li "O que significa estágio" e vários outros assuntos do manual e outros tutoriais sobre o Git, mas como eu disse, ainda não entendo os assuntos acima.

Portanto, se você puder, responda às perguntas com suas próprias palavras e exemplos, para que eu possa ter uma chance melhor de entender.

Obrigado.

O objetivo da área de preparação é ter um espaço flexível para sua confirmação. Eu acho que isso ficará mais claro se você comparar o git aos sistemas de controle de versão centralizados, como o subversion.

Subversão

No subversion, você pode optar por confirmar certos arquivos da sua cópia de trabalho. Mas apenas os arquivos completos. Agora: e se você quiser preparar o arquivo A, não o arquivo B, e as partes do arquivo Crelacionadas ao arquivo, Amas não as partes que dependem de alterações no arquivo B(desde então, você teria um problema com a consistência da confirmação).

Git

O Git resolve isso fornecendo a preparação como segunda cópia de trabalho. Na área de preparação, você está montando uma captura instantânea que irá confirmar (grosso modo).

Portanto, na área de preparação, você pode criar um instantâneo que inclua alterações Ae uma versão do arquivo Cque reflita apenas as alterações A.

Para perguntas específicas

• Você pode encenar a qualquer momento que desejar. Eu pessoalmente prefiro encenar logo antes de iniciar o commit.

• Ao fazer alterações em um arquivo em etapas e depois alterá-lo na cópia de trabalho, você não alterou o arquivo em etapas, é claro. Você pode decidir se deseja realizá-las também ou não, essas mudanças. git gui citoolOu seja, se você executar , verá diferenças nas versões preparadas e não preparadas (ferramentas agradáveis ​​e simples para preparação e confirmação em linha).

• Git é cauteloso aqui, o que provavelmente é uma coisa boa.

Estratégia de confirmação geral: confirmações granulares

Acho que quando se fala da pergunta "Quando devo encenar", também se deve falar sobre hábitos de cometer.

VCS centralizado

Nos sistemas centralizados de controle de versão em que você se compromete com um servidor central, era importante para seus colegas de trabalho que suas confirmações fossem completas e bem testadas. Assim, as pessoas tentariam confirmar não tão frequentemente e depois confirmariam o estado dos arquivos completos para minimizar a possibilidade de um erro. Assim, um commit tende a ser blocos muito grandes que incluem muitas alterações (se não forem correções simples). As alterações em uma confirmação podem ser totalmente independentes.

Git

No Git, um commit é realizado localmente, apenas enviando-os para um servidor os torna públicos. Portanto, um commit é barato em um sentido. Um commit no sentido de subversão é bastante comparável a vários git commitseguidos por git push. Essa diferença importa.

O Git permite que você confirme linhas de código únicas, mesmo que você tenha alterado outras linhas no mesmo arquivo. Isso oferece muitos benefícios, pois é possível, por exemplo, cometer uma correção de bug de segurança na linha 100, ao alterar as linhas 300-350, introduzindo um novo recurso.

• Você pode separar diferentes alterações em diferentes confirmações. Isso os separa muito bem no histórico de versões e até permite reverter um, mas não o outro.
• Seu commit não precisa necessariamente refletir um estado de "compilação" da sua cópia de trabalho (embora eu tente mantê-lo dessa maneira).

Então, onde está o "controle de qualidade" e a garantia de construção em um commit que um usuário do subversion esperaria? Ele é deslocado para outras ações no git. Você ainda deseja enviar um estado de funcionamento do programa para um repositório público. Portanto, verifique se os testes foram bem-sucedidos e se o programa funciona antes de enviar suas alterações.

Além disso, tente utilizar ramificações ao máximo. Ao confirmar muitas pequenas alterações, você terá um histórico de versões bastante grande. Se você trabalha em ramificações, pode categorizar essas confirmações granulares pelo nome da ramificação e depois mesclá-las novamente (a opção --no-fftambém preservará que esses recursos residam em uma ramificação exclusiva).

Ou seja, você pode manter o hábito de mesclar masterapenas ao ramo, se o ramo estiver em bom estado. Você também pode usar tags para rastrear marcos e lançamentos.

Agora, voltando à preparação: Depois de confirmar algumas linhas por confirmação, você fará o estágio diretamente antes de confirmar. (Pelo menos é assim que eu faço).

Eu acho que você está levando isso muito a sério. A preparação é apenas a seleção do material que você deseja incluir no próximo commit. Raramente é importante quando ou como você faz o teste; e se você tiver muitas alterações em etapas e em etapas a qualquer momento, provavelmente precisará revisar seu processo de desenvolvimento.

Em um projeto (após a primeira confirmação), quando é o momento certo para preparar os arquivos de origem? Logo antes de cometer? Logo após adicionar / excluir ou modificar?

Eu costumo fazer isso antes de cometer (a menos que eu note algum erro de digitação, então eu tenho que fazer uma correção de última hora e prepará-la também). O processo é o seguinte: editar, executar testes, estágio, confirmar. Se você preparar antes do teste, é provável que os testes falhem e você terá que fazer alterações e prepará-las também. Por que não deixá-lo até o tempo de confirmação?

Se os arquivos são testados no meio do caminho entre duas confirmações e depois são modificados, o que acontece com o Git? Ele precisa se preocupar com as alterações de conteúdo quando foi declarado e o que se tornou desde então?

Ele mostrará a diferença entre o estado atual do repositório e (última confirmação + alterações faseadas). Quando você prepara algumas das novas alterações, ele apenas recalcula o estado (última confirmação + alterações faseadas).

Se eu criar um novo arquivo, prepará-lo e depois deletá-lo, por que o Git me pede para usar o sinalizador "-f" e um simples "git -rm file.ext" não funciona?

Agora, estou supondo aqui, mas provavelmente porque as informações em etapas podem ser importantes (caso contrário você não as prepararia), mas ainda não estão sob controle de versão (como um arquivo que você pode remover git -rm). Então, gitquer ter certeza de que você sabe o que está fazendo.