Quais são as diferenças entre "git commit" e "git push"?

Em um tutorial do Git que estou passando, git commité usado para armazenar as alterações que você fez.

Para que é git pushusado então?

Basicamente git commit" registra alterações no repositório " enquanto git push" atualiza referências remotas junto com objetos associados ". Portanto, o primeiro é usado em conexão com o repositório local, enquanto o último é usado para interagir com um repositório remoto.

Aqui está uma bela imagem de Oliver Steele , que explica o modelo git e os comandos:

Leia mais sobre git pushe git pullno GitReady.com (o artigo que me referi primeiro)

confirmar : adicionando alterações ao repositório local

push : para transferir o último commit (s) para um servidor remoto

Bem, basicamente o git commit coloca suas alterações no repositório local, enquanto o git push envia as alterações para o local remoto.

git pushé usado para adicionar confirmações feitas no repositório local a um repositório remoto - além de git pullpermitir que as pessoas colaborem.

Como o git é um sistema de controle de versão distribuído, a diferença é que o commit confirmará as alterações no repositório local, enquanto o push enviará as alterações para um repositório remoto.

Confirmar : Instantâneo | Changeset | History_record | Versão 'Salvar como' de um repositório. Repositório Git = série (árvore) de confirmações .

Repositório local : repositório no seu computador.

Repositório remoto : repositório em um servidor ( Github ).

git commit: Anexe uma nova confirmação (última confirmação + modificações faseadas ) ao repositório local . (Todas as confirmações são armazenadas em /.git)

git push, git pull: Sincronize o repositório local com seu repositório remoto associado . push- aplicar alterações de local para remoto , pull- aplicar alterações de remoto para local .

git commitregistre suas alterações no repositório local .

git push atualize o repositório remoto com suas alterações locais.

Três coisas a serem observadas:

1) Working Directory ----- pasta onde nosso arquivo de códigos está presente

2) Repositório local ------ Isso está dentro do nosso sistema. Quando tomamos o comando COMMIT pela primeira vez, esse Repositório Local é criado. no mesmo local em que está nosso diretório de trabalho, o
arquivo Checkit (.git) é criado.
Depois disso, sempre que confirmarmos, isso armazenará as alterações que fazemos no arquivo do Diretório de Trabalho no Repositório local (.git)

3) Repositório remoto ----- Está situado fora do nosso sistema, como em servidores localizados em qualquer lugar do mundo. como o github. Quando fazemos o comando PUSH, os códigos de nosso repositório local são armazenados nesse repositório remoto

Só quero adicionar os seguintes pontos:

Você não pode enviar por push até que você confirme, como usamos git pushpara enviar por push os commits feitos em sua filial local para um repositório remoto.

O git pushcomando usa dois argumentos:

Um nome remoto, por exemplo, origin Um nome de filial, por exemplo,master

Por exemplo:

git push  <REMOTENAME> <BRANCHNAME> 
git push  origin       master

Uma analogia muito grosseira: se compararmos git commitao salvar um arquivo editado, git pushcopiá-lo para outro local.

Por favor, não tire essa analogia desse contexto - confirmar e enviar não é como salvar um arquivo editado e copiá-lo. Dito isto, deve valer para comparações.

É mais fácil entender o uso dos comandos git adde commitse você imaginar um arquivo de log sendo mantido em seu repositório no Github. O arquivo de log de um projeto típico para mim pode se parecer com:

---------------- Day 1 --------------------
Message: Completed Task A
Index of files changed: File1, File2

Message: Completed Task B
Index of files changed: File2, File3
-------------------------------------------

---------------- Day 2 --------------------
Message: Corrected typos
Index of files changed: File3, File1
-------------------------------------------
...
...
...and so on

Normalmente começo o dia com uma git pullsolicitação e termino com uma git pushsolicitação. Portanto, tudo dentro do registro de um dia corresponde ao que ocorre entre eles. Durante cada dia, há uma ou mais tarefas lógicas concluídas que exigem a alteração de alguns arquivos. Os arquivos editados durante essa tarefa são listados em um índice.

Cada uma dessas subtarefas (Tarefa A e Tarefa B aqui) são confirmações individuais. O git addcomando adiciona arquivos à lista 'Índice de arquivos alterados'. Esse processo também é chamado de teste e, na realidade, os registros alteram os arquivos e as alterações executadas. O git commitcomando registra / finaliza as alterações e a lista de índices correspondente, juntamente com uma mensagem personalizada que pode ser usada para referência posterior.

Lembre-se de que você ainda está apenas alterando a cópia local do seu repositório e não a do Github. Depois disso, somente quando você fizer git pushtodas essas alterações registradas, juntamente com seus arquivos de índice para cada confirmação, será logado no repositório principal (no Github).

Como exemplo, para obter a segunda entrada nesse arquivo de log imaginário, eu teria feito:

git pull
# Make changes to File3 and File4
git add File3 File4
# Verify changes, run tests etc..
git commit -m 'Corrected typos'
git push

Em poucas palavras, git adde git commitpermite dividir uma alteração no repositório principal em sub-alterações lógicas sistemáticas. Como outras respostas e comentários apontaram, é claro que há muitos outros usos neles. No entanto, esse é um dos usos mais comuns e um princípio determinante por trás do Git, sendo um sistema de controle de revisão em vários estágios, diferente de outros populares como o Svn.

O git commit nada mais é do que salvar nossas alterações oficialmente; para cada commit que enviamos, uma vez concluído o commit, podemos enviá-lo para remoto para ver nossa mudança globalmente.

o que significa que podemos fazer numerosas confirmações antes de enviarmos para remoto (podemos ver a lista de confirmações ocorridas e as mensagens também) git salva cada confirmação com o ID de confirmação, que é um código de 40 dígitos

e eu uso o git push somente quando eu queria ver minha alteração no controle remoto (depois verificarei se meu código funcionava no jenkins)

Bem, basicamente o git commit coloca suas alterações no repositório local, enquanto o git push envia as alterações para o local remoto. Como o git é um sistema de controle de versão distribuído, a diferença é que o commit confirmará alterações no repositório local, enquanto o push enviará as alterações para um repositório remoto

fonte do Google

http://gitref.org/basic/ este link também será muito útil

https://git-scm.com/docs/git-commit

em termos leigos, git commité a etapa antes de git pushexecutá-los nessa ordem para obter com êxito o seu arquivo no github.

git commité confirmar os arquivos preparados no repositório local. git pushé avançar rapidamente mesclar a ramificação principal do lado local com a ramificação principal remota. Mas a fusão nem sempre é bem sucedida. Se a rejeição aparecer, você precisará pullfazê-lo para obter sucesso git push.