Pourquoi devrais-je pousser si je travaille seul dans un référentiel local?


21

J'interagis avec Git via GitHub pour Windows , ce qui est drôle car je ne pousserai jamais mon référentiel vers GitHub. J'y travaille seul et il est destiné à être utilisé uniquement par moi. J'ai remarqué que mes validations sont répertoriées sous «validations non synchronisées» et sous «historique», il indique «aucune validation». Ce qui m'amène à la question, qu'est-ce que j'obtiendrai en poussant sauf mes commits listés sous "histoire"?


14
Il y a un manque de compréhension important dans la question qui mérite d'être souligné: si vous n'avez rien poussé à distance, tout votre travail se trouve dans le référentiel local sur disque. Perdez votre machine, perdez tout ce que vous avez fait.
Lars Viklund

Réponses:


40

Vous êtes techniquement correct - pas vraiment besoin de pousser si vous ne partagez le code avec personne.

Là encore, votre ordinateur portable dispose d'un disque dur fabriqué par le plus bas soumissionnaire. Votre maison pourrait brûler avant que le disque dur ne tombe en panne. Vous voudrez peut-être regarder votre code à distance. Ou même le partager avec quelqu'un.

Maintenant, avec Github, ils exigent que tout soit public ou vous devez payer pour des référentiels privés. Donc, si vous voulez le garder pour vous, vous voudrez peut-être consulter bitbucket qui vous permettra de faire git mais propose également des dépôts privés gratuits.

Une autre option serait d'enregistrer votre référentiel git quelque part qui est sauvegardé à distance. Mais il y a peu d'avantages à le faire plutôt que de simplement utiliser un fournisseur SCM cloud ces jours-ci.


Bitbucket offre à peu près un nombre illimité de prises en pension privés gratuitement .

Il y a de nombreuses raisons de pousser. Le workflow ne change vraiment pas grand-chose. Vous travaillez commit, commit, commit, terminez un workflow et poussez ...
Rig

7

Il y a une autre raison pour laquelle vous voudriez pousser vers un dépôt (même si c'est, d'une manière ou d'une autre, local): les postes de travail .

Je ne sais pas pour vous, mais je travaille sur 4 ordinateurs différents (1 PC à la maison, 1 ordinateur portable, 1 ordinateur de bureau et 1 ordinateur portable de bureau). sans douleur. Étant donné que Git est un DVCS, cela met cet avantage à profit: ce ne sont pas seulement des sauvegardes, mais toutes les différentes bases de code sur lesquelles je travaille peuvent être facilement fusionnées, vérifiées et analysées.

Il peut être local si, par exemple, votre ordinateur personnel est le "serveur" (ou l'origine) et que vous avez un ordinateur portable domestique - de cette façon, vous pouvez facilement rester synchronisé.

Sidenote : Les gens disent souvent "Je préfère utiliser Dropbox (ou tout autre service de synchronisation)". Les quantités massives d'objets qu'un dépôt Git a rend ridicule d'utiliser Dropbox comme ça. C'est une option, mais je n'en dirais pas une bonne.


+1, je ferais certainement la même chose dans votre cas. Que faites-vous si vous avez oublié de pousser à la maison et êtes maintenant au travail?
Moshe Revah

2
@Zippoxer Concentrez-vous sur une autre tâche et fusionnez plus tard.
bytebuster

Exactement, ce qu'a dit @bytebuster. C'est la beauté des DVCS! (Bien que, avec suffisamment de pratique, vous n'oublierez plus!)
AeroCross

Alternativement: travaillez sur un projet parallèle / hobby pour vous détendre ou explorer de nouvelles idées, etc. :-)
johannes

6

En tant que SCM distribué, git fait la distinction entre les concepts «faire un instantané de la copie de travail» (commit) et «référentiels de synchronisation» (push / pull / fetch).

Si vous n'avez qu'un seul clone local de votre référentiel, il n'est pas logique de pousser. Cependant, avec github, vous faire un autre clone (celui sur github), et en poussant vos changements a au moins un avantage: la sauvegarde. Si votre ordinateur meurt, vous avez toujours tout poussé jusqu'à présent sur github.

Bien sûr, ce n'est pas le but principal de github; github est destiné au partage de code, donc si votre projet est sur github, vous pouvez autoriser d'autres personnes à tirer de là, cloner votre projet, agir sur les demandes d'extraction de leurs clones, ou même donner à d'autres personnes de confiance un accès push à votre référentiel.

Une autre raison de pousser est si vous utilisez plusieurs clones locaux. Cela peut être utile pour diverses choses: par exemple, vous pouvez vouloir travailler sur deux branches différentes en même temps, ou vous pouvez essayer des opérations potentiellement destructrices sur votre référentiel; si tout fonctionne comme prévu, vous conservez le clone modifié (ou repoussez vos modifications dans le référentiel d'origine), mais si les choses vont au sud, vous pouvez simplement supprimer le clone foiré et revenir à l'original (qui est toujours inchangé) .

Certaines personnes utilisent même git pour le déploiement: la version de production est également un dépôt git, et la mise à jour vers une version plus récente est une question de récupération et d'extraction (évidemment, cela ne fonctionne que si vous n'avez pas besoin d'une étape de construction). Je ne le recommanderais pas nécessairement pour les choses sérieuses, mais pour les petites choses, c'est une solution simple et pragmatique.

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.