Dans un didacticiel Git que je traverse, git commit
est utilisé pour stocker les modifications que vous avez apportées.
À quoi git push
sert alors?
Dans un didacticiel Git que je traverse, git commit
est utilisé pour stocker les modifications que vous avez apportées.
À quoi git push
sert alors?
Réponses:
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:
En savoir plus sur git push
et git pull
sur GitReady.com (l'article auquel j'ai fait référence en premier)
git push
avec lequel travailler. En réalité, la destination de git push
peut ê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 master
ou git push ~/proj/clone.git master
, par exemple), ou dans un référentiel git que votre propre hôte sert.
Eh bien, git commit place vos modifications dans votre référentiel local, tandis que git push envoie vos modifications à l'emplacement distant.
git push
Télécharge- t-il les fichiers mis à jour ou un fichier spécial "diff"?
git push
est 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.
É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.
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 .
git commit
enregistrez vos modifications dans le référentiel local .
git push
mettez à jour le référentiel distant avec vos modifications locales.
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
Je veux juste ajouter les points suivants:
Vous ne pouvez pas pousser jusqu'à ce que vous vous engagiez comme nous l'utilisons git push
pour pousser les validations effectuées sur votre branche locale vers un référentiel distant.
La git push
commande 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
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.
Il est plus facile de comprendre l'utilisation des commandes git add
et commit
si 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 pull
demande et la termine par une git push
demande. 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 add
commande 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 add
et git commit
vous 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.
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)
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
en termes simples, git commit
est l'étape avant de les git push
exécuter dans cet ordre pour réussir à git votre fichier à github.
git commit
consiste à valider les fichiers qui sont mis en scène dans le référentiel local. git push
consiste à 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 pull
pour réussir git push
.