Dois-je utiliser git stash pour enregistrer les modifications en cours de mon projet et le pousser vers github pour y accéder sur d'autres ordinateurs?


20

Je travaille très souvent sur certaines fonctionnalités de mon projet dont j'ai besoin de faire une pause avant qu'il ne soit assez bon pour un commit. Cependant, j'utilise quotidiennement deux ordinateurs différents pour coder (mon ordinateur portable et mon bureau de laboratoire de recherche). Par exemple: je travaille sur une fonctionnalité à la maison, puis je m'arrête et je vais à mon laboratoire.

Je ne veux pas mélanger la synchronisation du cloud (par exemple Dropbox) avec le suivi à distance GitHub.

J'ai simplement commis des états inachevés (et désordonnés) de mon code avant (et je l'ai poussé) uniquement dans le but de le récupérer dans l'autre ordinateur pour continuer le travail. Je suis presque sûr que c'est une mauvaise pratique.

Aujourd'hui, cependant, je suis tombé git stashun peu sur Google. Cela semble être la solution parfaite pour ce dont j'ai besoin.

Cependant, la documentation ne dit pas si elle va à github une fois que j'ai poussé mes modifications. En plus de cela, je veux savoir s'il existe un moyen plus efficace d'accomplir la mobilité dont j'ai besoin.

Merci d'avance!


1
Je vote pour fermer cette question comme hors sujet car elle a déjà été répondue sur Stack Overflow
David Arno

5
@DavidArno: Je ne pense pas que ce soit un doublon intersite. La question StackOverflow concerne "Puis-je faire X" et celle-ci concerne "Est-ce que X est une bonne pratique". À tout le moins, la cause profonde de la question est différente.
Greg Burghardt du

7
@DavidArno le dernier que j'ai vérifié, "déjà répondu sur SO" n'est pas une raison pour fermer une question.
RubberDuck

Réponses:


28

J'ai simplement commis des états inachevés (et désordonnés) de mon code auparavant (et je l'ai poussé) uniquement dans le but de le récupérer dans l'autre ordinateur pour continuer le travail. Je suis presque sûr que c'est une mauvaise pratique.

C'est OK de commettre un travail inachevé malpropre. Faites votre travail dans une branche thématique. Engagez-vous tôt et engagez-vous souvent. En savoir plus sur Quand valider le code? pour quelques directives sur le moment de faire un commit. Spécifiquement pour Git, validez dans une branche de sujet et poussez-la aussi souvent que vous le souhaitez.

Si cette branche de rubrique vous est destinée, validez et envoyez du code cassé. Vous ne devez defer de pousser un code erroné à une branche qui est utilisée par d' autres personnes. N'hésitez pas à casser votre propre code.


6
Je dirais même que c'est plus fort: ne travaillez jamais sur une branche principale, utilisez toujours une branche de sujet. Engagez-vous comme bon vous semble, poussez-le sans crainte. Lorsque vous êtes satisfait des modifications, fusionnez-le pour le maîtriser.
9000

Très bon conseil! Je pense que la grande confusion pourrait se produire parce que nous devons ajouter un commentaire à un commit, et parfois ce sera littéralement quelque chose comme "tâche en cours" ou quelque chose comme ça. Et oui, je travaille seul dans cette branche donc tout ce que vous avez dit a du sens!
Leandro

4
Cela vous donne également la possibilité d'écraser les validations individuelles en une seule lors de la fusion de votre branche git merge --squash bugfix
snoopy

2
Les messages de validation @Leandro doivent être aussi atomiques et clairs que possible. Par exemple, même si c'est WIP, vous pouvez dire par exemple "Ajouter un contrôleur pour gérer les requêtes de page - WIP". Les messages de validation fournissent également un historique de recherche des modifications apportées au projet. Dix commits de «WIP» n'aideraient personne à la recherche d'un changement concernant la gestion des utilisateurs par exemple.
Ben

7

Les cachettes sont destinées à un usage local, comme un endroit temporaire pour mettre des choses pendant que vous vous amusez avec des branches.

Si vous êtes le seul à travailler sur une branche, il n'y a aucun problème à valider du code cassé. Ce que je fais dans des situations similaires, c'est faire un commit cassé, puis après l'avoir tiré à l'autre emplacement, faire un git reset HEAD~1pour l'annuler. Bien sûr, cela nécessite une utilisation --forcesur vous pullset pusheslorsque vous changez de lieu.

Ou j'attends juste mon premier commit et fais un git commit --amend. Ou je supprime simplement toutes les validations rompues lorsque je valide la branche de fonctionnalité. Ou je ne m'inquiète tout simplement pas de quelques commits cassés clairement marqués dans mon histoire, car j'ai tendance à ne pas partir tant que je ne suis pas à une bonne étape. Il y a beaucoup d'options.


1
Je ne recommanderais pas de s'y habituer, --amenddonc cela nécessite --forcedes poussées. Mieux vaut ne s'engager que dans une branche jetable.
leftaroundabout

1

stashn'est pas vraiment satisfaisant pour autre chose que de nettoyer votre répertoire de travail pour «débrancher votre branche»; si vous ne stash popretournez pas immédiatement l'état, les choses deviendront très confuses.

S'il y a du travail réel à enregistrer, même si ce n'est pas bon pour une entrée de référentiel permanent, il doit toujours s'agir d'un commit. En fait, je ne laisse jamais mon répertoire de travail dans un état qui n'est pas sous contrôle de version - j'utilise des scripts Python très simples pour enregistrer chaque modification en tant que commit temporaire. Si vous voulez essayer, voici ce qu'il faut faire:

  1. Lorsque vous avez fait un travail inachevé et que vous êtes sur le point de quitter le lieu de travail, exécutez git-tmp-commit. Il valide automatiquement toutes les modifications dans une nouvelle branche unique.
  2. Poussez cette branche à distance.
  3. Laisser.
  4. Lorsque vous souhaitez continuer, clonez à nouveau cette branche à partir de la télécommande. Je le fais avec le ccdscript, qui vérifie en fait tout, de zéro à un dossier temporaire , en choisissant automatiquement la branche la plus récente ... mais vous pouvez également simplement récupérer et extraire manuellement la branche à temporary-commits/original-branch/YYYY-MM-DD...partir d'un clone existant du référentiel.
  5. Enfin, «désengagez» les modifications avec git-tmp-commit -r. Cela vous ramènera à la branche d'origine (par exemple master) et laissera les modifications de la validation temporaire dans le répertoire de travail, afin que vous puissiez continuer ici jusqu'à ce qu'il soit temps pour une validation correcte (ou temporaire, si vous devez repartir).

La façon dont le script est écrit en ce moment, cela ne fonctionne que s'il n'y a pas de branche masterdans le référentiel de paiement . Donc, dans le doute, vous devriez le faire git branch -d master; ce n'est évidemment pas vraiment idéal ...

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.