Quelles sont les différences entre «git commit» et «git push»?


895

Dans un didacticiel Git que je traverse, git commitest utilisé pour stocker les modifications que vous avez apportées.

À quoi git pushsert alors?


83
Vous pouvez également consulter la "feuille de triche Git" qui m'a beaucoup aidé à comprendre le concept: ndpsoftware.com/git-cheatsheet.html
adriendenat


2
pas de réponse puisqu'elle a déjà été fournie. juste une observation. me semble qu'un commit devrait vraiment être appelé un save et le push devrait être appelé commit. Problème de scénario de dénomination classique.
dublinx

Réponses:


1619

Fondamentalement, git commit" enregistre les modifications apportées au référentiel " tandis que git push" met à jour les références distantes avec les objets associés ". Ainsi, le premier est utilisé en connexion avec votre référentiel local, tandis que le dernier est utilisé pour interagir avec un référentiel distant.

Voici une belle photo d' Oliver Steele , qui explique le modèle git et les commandes:

Commandes de transport de données Git

En savoir plus sur git pushet git pullsur GitReady.com (l'article auquel j'ai fait référence en premier)


20
Voici la source originale: osteele.com/archives/2008/05/my-git-workflow avec une autre image d'un workflow git
tanascius

9
@ben github n'est qu'une solution pour héberger votre référentiel public "sur le cloud" git pushavec lequel travailler. En réalité, la destination de git pushpeut être n'importe quel référentiel git. Il peut être sur votre propre disque dur local dans un autre répertoire ( git remote add clone ~/proj/clone.git; git push clone masterou git push ~/proj/clone.git master, par exemple), ou dans un référentiel git que votre propre hôte sert.
Santa

2
alors ... devez-vous pousser en premier ou vous engager en premier?
Kokodoko

5
@Piet commence par votre espace de travail, où vous modifiez les fichiers. Ensuite, vous les ajoutez à l'index, les validez dans le référentiel local et - enfin - les
envoyez

2
@ Mr.Hyde non ce n'est pas possible. Git en tant que contrôle de version distribué nécessite que vous ayez une copie locale.
tanascius

215

commettre : ajout de modifications au référentiel local

push : pour transférer le (s) dernier (s) commit (s) vers un serveur distant


56

Eh bien, git commit place vos modifications dans votre référentiel local, tandis que git push envoie vos modifications à l'emplacement distant.


9
c'est mon deuxième jour d'utilisation de GIT. En regardant les réponses ci-dessus, je n'ai toujours pas une image claire, mais votre réponse la résume. Merci.
Bopha

1
git pushTélécharge- t-il les fichiers mis à jour ou un fichier spécial "diff"?
multigoodverse

27

git pushest utilisé pour ajouter des validations que vous avez faites sur le référentiel local à un référentiel distant - avec git pull, il permet aux gens de collaborer.


26

Étant donné que git est un système de contrôle de version distribué, la différence est que commit valide les modifications dans votre référentiel local, tandis que push pousse les modifications vers un référentiel distant.


19

Commit : Instantané | Changeset | History_record | Version | «Enregistrer sous» d'un référentiel. Git repository = série (arbre) de commits .

Référentiel local : référentiel sur votre ordinateur.

Référentiel distant : référentiel sur un serveur ( Github ).

git commit: Ajoutez une nouvelle validation (dernière validation + modifications par étapes ) au référentiel local . (Tous les commits sont stockés dans /.git)

git push, git pull: Synchronisez le référentiel local avec son référentiel distant associé . push- appliquer les changements du local au distant , pull- appliquer les changements du distant au local .


11

git commitenregistrez vos modifications dans le référentiel local .

git push mettez à jour le référentiel distant avec vos modifications locales.


20
Votre réponse est fondamentalement identique à cette réponse , elle n'ajoute rien de nouveau.

7

Trois choses à noter:

1) Répertoire de travail ----- dossier où notre fichier de codes est présent

2) Dépôt local ------ C'est à l'intérieur de notre système. Lorsque nous effectuons la commande COMMIT pour la première fois, ce référentiel local est créé. au même endroit où se trouve notre répertoire de travail, le
fichier Checkit (.git) est créé.
Après cela, chaque fois que nous nous engageons, cela stockera les modifications que nous apportons dans le fichier du répertoire de travail vers le référentiel local (.git)

3) Référentiel distant ----- Il est situé en dehors de notre système comme sur des serveurs situés n'importe où dans le monde. comme github. Lorsque nous effectuons la commande PUSH, les codes de notre référentiel local sont stockés dans ce référentiel distant


7

Je veux juste ajouter les points suivants:

Vous ne pouvez pas pousser jusqu'à ce que vous vous engagiez comme nous l'utilisons git pushpour pousser les validations effectuées sur votre branche locale vers un référentiel distant.

La git pushcommande prend deux arguments:

Un nom distant, par exemple, origin Un nom de branche, par exemple,master

Par exemple:

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

4

Une analogie très grossière: si nous comparons git commità l'enregistrement d'un fichier édité, alorsgit push serait copier ce fichier vers un autre emplacement.

Veuillez ne pas retirer cette analogie de ce contexte - la validation et la poussée ne sont pas tout à fait comme enregistrer un fichier édité et le copier. Cela dit, cela devrait tenir pour des comparaisons.


1

Il est plus facile de comprendre l'utilisation des commandes git addet commitsi vous imaginez un fichier journal en cours de maintenance dans votre référentiel sur Github. Un fichier journal de projet typique pour moi peut ressembler à:

---------------- 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

Je commence généralement ma journée par une git pulldemande et la termine par une git pushdemande. Donc, tout ce qui se trouve dans le dossier d'une journée correspond à ce qui se passe entre eux. Chaque jour, il y a une ou plusieurs tâches logiques que j'effectue et qui nécessitent de modifier quelques fichiers. Les fichiers modifiés au cours de cette tâche sont répertoriés dans un index.

Chacune de ces sous-tâches (tâche A et tâche B ici) sont des validations individuelles. La git addcommande ajoute des fichiers à la liste «Index des fichiers modifiés». Ce processus est également appelé mise en scène et enregistre en réalité les fichiers modifiés et les modifications effectuées. legit commit commande enregistre / finalise les modifications et la liste d'index correspondante avec un message personnalisé qui peut être utilisé pour référence ultérieure.

N'oubliez pas que vous ne modifiez toujours que la copie locale de votre référentiel et non celle de Github. Après cela, seulement lorsque vous faites ungit push toutes ces modifications enregistrées, ainsi que vos fichiers d'index pour chaque validation, que vous vous connectez au référentiel principal (sur Github).

Par exemple, pour obtenir la deuxième entrée dans ce fichier journal imaginaire, j'aurais fait:

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

En un mot, git addet git commitvous permet de décomposer une modification du référentiel principal en sous-modifications logiques systématiques. Comme d'autres réponses et commentaires l'ont souligné, il y a bien sûr de nombreuses autres utilisations. Cependant, c'est l'un des usages les plus courants et un principe moteur derrière Git étant un système de contrôle de révision à plusieurs étapes contrairement à d'autres populaires comme Svn.


0

git commit n'est rien d'autre que d'enregistrer nos modifications officiellement, pour chaque commit que nous donnons un message de commit, une fois que nous avons fini avec les commits, nous pouvons le pousser à distance pour voir notre changement globalement

ce qui signifie que nous pouvons faire de nombreuses validations avant de passer à distance (nous pouvons voir la liste des validations et les messages également) git enregistre chaque validation avec un identifiant de validation qui est un code à 40 chiffres

et j'utilise git push uniquement lorsque je voulais voir mon changement dans remote (là après je vérifierai si mon code a fonctionné dans jenkins)


-1

Eh bien, git commit place vos modifications dans votre référentiel local, tandis que git push envoie vos modifications à l'emplacement distant. Étant donné que git est un système de contrôle de version distribué, la différence est que commit valide les modifications dans votre référentiel local, tandis que push pousse les modifications vers un référentiel distant

source Google

http://gitref.org/basic/ ce lien sera également très utile

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


Cette réponse copie mot à mot les autres réponses en une seule.
Jeffery Opoku-Mensah

Cela n'apporte rien de nouveau à tout ce qui a déjà été dit auparavant ...
hublo

-1

en termes simples, git commitest l'étape avant de les git pushexécuter dans cet ordre pour réussir à git votre fichier à github.


-2

git commitconsiste à valider les fichiers qui sont mis en scène dans le référentiel local. git pushconsiste à fusionner rapidement la branche principale du côté local avec la branche principale distante. Mais la fusion ne réussira pas toujours. Si le rejet apparaît, vous devez le faire pullpour réussir git push.


Certaines personnes peuvent vouloir forcer la poussée au lieu de tirer. Ça dépend de la situation. En fait, si vous êtes rebasé, les commits sur une branche que vous ne partagez pas avec d'autres personnes (même sur un dépôt à distance), alors tirer n'est certainement pas ce que vous voulez faire.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.