Je suis au courant de Il est gênant de taper différentes commandes à chaque fois. Ce serait super sympa s'il y avait un moyen de trouver les commits sur "ma branche" et seulement sur "ma branche" sans avoir à me souvenir de "ma branche".
Pour simplifier le problème, n'assumez aucune succursale de la branche de la succursale actuellement vérifiée. Parce que j'ai l'intention d'utiliser cela sur les branches de fonctionnalités locales uniquement.
J'ai une solution et je vais le poster comme une réponse, mais je suis curieux s'il y a une meilleure façon. Git journal maître .. . Je comprends que cela montre tous les engagements sur la branche actuelle qui ne sont pas dans maître . Cependant, tout en travaillant avec plusieurs branches de longue durée, cela est ennuyeux. Est ma succursale de maître , développe , version-x.x.x , Feature-bla ? Qui sait! Je ne sais pas, je ne m'en souviens sûrement pas.
3 Réponses :
Cela fonctionne mais n'est pas simple. Il peut ne pas y avoir de manière simple. Je n'ai pas seulement 99% sûr qu'il est correct. Contrairement à Ceci Répondre il fonctionne pour les succursales qui existent déjà.
Utilisation de ci-dessous, nous utilisons le git fusion-base code> Nous pouvons trouver le meilleur (c'est-à-dire la plus récente de l'histoire) ancêtre entre deux commits. Si nous exécutons cela entre tête code> (la branche actuelle) et la branche de l'autre, nous trouvons un ensemble de commettre où les choses se divisent. P> pour chacun -ref code> commande car il vaut mieux être script et nous exécutons la commande. Nous filtrons également le COMTT actuel. P> [alias]
# ...other aliases...
log-my-branch = !git log HEAD $(git for-each-ref --shell --format='git merge-base HEAD %(refname)' refs/heads/ | sh | sed /"$(git rev-parse HEAD)"/d | sed 's/^/^/' | tr '\n' ' ' )
Votre question implique un concept de commit "appartenant à" une succursale, ou une succursale composée de commettre. C'est peut-être comment d'autres outils considèrent le monde, mais Git ne fonctionne vraiment pas de cette façon. Depuis que je comprends que c'est comme ça que vous voulez voir les engagements, je vais essayer de répondre à la question dans cet esprit, mais je comprends qu'il n'y aura aucune bonne solution à ce problème, car Git lui-même ne "se souvient" de quelle branche est votre succursale "Parent".
Alors ... Votre propre réponse est imparfaite de deux manières. Je vais aborder ceux-ci, puis je vais suggérer une autre approche qui pourrait mieux fonctionner (cependant, imo, toujours pas parfaitement).
les problèmes de votre réponse: < / P> Premièrement, cela peut ne pas toujours obtenir tout ce que vous êtes après. Et si une suction a été créée de votre branche? dans cette image - à nouveau si nous supposons que les entreprises et les succursales se rapportent à la manière dont votre question Suggère - vous visualiseriez Cette image illustre également pourquoi il n'y a pas de solution réelle au problème comme posé. J'ai utilisé des indices visuels pour impliquer que alors rien ne peut indiquer si vous voulez Voir Je vais ajouter, même si vous dites "Ah, mais je ne le fais jamais", un autre problème possible Se produit si vous fusionnez jamais une succursale à son parent, mais continuez ensuite à travailler dessus. Tous les engagements avant que la fusion ne soit exclu de votre sortie. second, c'est trop compliqué. Au lieu d'exclure "la base de fusion entre une approche différente: Si GIT ne stocke pas assez d'informations pour faire ce que vous voulez, le meilleur que vous puissiez faire est de suivre une approche disciplinée pour stocker délibérément des données supplémentaires. Par exemple, vous pouvez créer un alias pour ramification afin que chaque fois que vous créez une branche Même alors si vous avez des branches latérales qui sont fusionnées dans Le plus gros problème avec cette approche est que les étiquettes devraient être déplacées si jamais vous rebastez votre succursale et que vous devriez probablement être supprimé si jamais vous supprimez votre succursale. Encore une fois une combinaison de script et / ou de décider de ne pas décider de ne pas faire certaines choses pourrait atténuer le problème. Donc, je dirais que cette solution est beaucoup plus simple et vous rapproche de vous près (disons 95% du chemin) à ce que tu veux; Mais il ne fonctionne toujours que si vous pouvez faire des hypothèses sur la manière dont la ramification et la fusion sont effectuées dans votre repo. votre_branch comme A , b , c et d d , à droite? Mais si vous donnez log exclusions pour toutes les branches Fusionne bases avec Your_branch , l'une des bases de fusion est B , donc A < / Code> et B serait exclu. autre_branch a été créé à partir de your_branch plutôt que l'inverse, mais aussi loin que git stocke ses données, cette image est la même comme celui où your_branch est pensé à créer à partir de autre_branch A et B ou non. quelque_branch , vous créez également une balise légère quelque_branch_root . Ensuite, vous pouvez toujours enregistrer one_branch_root..some_branch . one_branch Vous les verriez. Vous pouvez atténuer cela en donnant journal l'option - First-parent , mais si vous fusionnez votre succurse en quelque chose d'autre, puis en avançez votre succursale qui vous fusionner "LL aura des problèmes encore plus gros.
"Je dirais que cette solution est beaucoup plus simple" Je pense à peine à créer une étiquette pour chaque branche est "simple" haha. Mais je peux voir faire des alias qui fait une branche et une balise ainsi que celle qui supprime une branche et la balise. En outre, de bonnes suggestions à l'exclusion des succursales au lieu des ancêtres, ainsi que d'utiliser le premier parent pour faire des fusions dans ma branche ont un sens.
Cette méthode est plus propre mais ne fonctionnera malheureusement que pour de nouvelles branches à l'avenir.
Nous stockons essentiellement des "métadonnées" à propos de la succursale de notre branche. Nous le stockons dans la configuration du référentiel local sous Nous pouvons "envoyer des paramètres" à un alias git si nous utilisons une fonction dedans. Premièrement, nous notons la branche actuelle (comme plus tard dans le script, ce sera la nouvelle branche). sucaire.branch_name.parent . Ceci est plus agréable que d'utiliser des tags car il ne pas encombrer notre histoire. De plus, Git traitera automatiquement la suppression de la suppression lorsque la branche est supprimée. GIT Make-Branch FOO fera votre succursale et notez le parent. GIT LOG-MY-BRANCH FAIRE FAIRE LOGMING ET GIT REBASE2 BAR Réinitialisera le parent après qu'il recule. Pour ceux-ci, vous pouvez donner des paramètres supplémentaires, mais le nom de la branche doit être d'abord.
.gitconfig
@Markadelsberger comment alors? Cela peut signifier beaucoup de choses différentes.
Les paramètres ne poussent ni ne vont pas.
@Markadelsberger Ceci est destiné à vérifier les journaux localement sur des succursales personnelles. Le fait que les paramètres ne poussent pas ou ne prennent pas la bonne chose.
Ou donc, vous penserez jusqu'à la première fois que vous devez vous retrouver. Regardez, si vous voulez prétendre que c'est une bonne solution pour vous, utilisez-le; Ne change pas mon commentaire ni mon opinion de la solution.
@Markadelsberger Si je dois vous reconnaître, cela ne me dérange pas de prendre le temps supplémentaire pour déterminer quelle agence venait quelque chose depuis que je reçois déjà quelque chose de création.
@Markadelsberger Je n'essaye pas de vous convaincre que c'est une bonne solution pour vous, j'essaie de soulager les préoccupations que vous avez sur ce qui pourrait vous tromper. Ceci fait travaille (dans la mesure où j'ai testé). Donc, je suis confus pourquoi vous insistez pour la descendre. Et honnêtement, ce n'était peut-être pas vous, mais les horaires du représentant changent de la question de la question / réponse avec votre réponse / commentaires. C'est juste frustrant de rencontrer un problème et de proposer une solution, de partager avec la communauté pour les personnes qui se débattent avec la même chose et simplement de se faire évasser parce que "cela ne fonctionne pas avec des repos distants".
@Markadelsberger Je n'ai pas dit que je n'essayais pas de vous convaincre de rien, j'ai dit que je n'essayais pas de vous convaincre que c'était une bonne solution pour vous. "Les gens vont s'attendre à ce qu'il soit sûr de se ré-cloner" Vous le faites sonner comme ça va briser quelque chose en l'appelant "dangereux", je vous assure que rien ne le fera. Si la préoccupation est vraiment que les gens vont assumer ces œuvres avec les branches d'autres personnes, je vais mettre à jour "mais malheureusement ne travaillera que pour de nouvelles succursales allant de l'avant" de dire quelque chose "ne travaillera que avec de nouvelles branches que vous créez localement et seulement dans votre référentiel local "
Il n'y a vraiment aucun "meilleur moyen" spécifique, car la question fondamentale est que les engagements sont sur de nombreuses branches simultanément, avec l'ensemble de branches qui contiennent une validation donnée en évolution de manière dynamique car les noms de branche sont créés, supprimés ou déplacés. Il y a quelques modifications mineures que vous pouvez apporter, surtout simplement syntaxique, afin de réduire le nombre de programmes à exécuter. En particulier, envisagez d'utiliser
- pas --Not au lieu de beaucoup de ^ ^ opérations. @torek "Les commits sont sur de nombreuses branches simultanément, avec l'ensemble des succursales qui contiennent une validation donnée de manière dynamique" - je suis au courant. Mais 99% du temps que ce n'est pas le cas. J'essaie de simplement obtenir les commits de la branche de fonctionnalité que je travaille. Assumer aucune autre branche de branche de la branche que je suis sur. Je peux éditer la question avec cela si cela aide à clarifier.
Un modèle que fait travaille est Mercurial: un commit est à jamais attaché à la succursale sur laquelle vous le faites. Cela a quelques inconvénients: à la fin, j'ai conclu que la méthode de Git, imparfaite comme elle pourrait être, c'est mieux. Git peut être amélioré en ajoutant une deuxième notion (locale) de «branche parente» d'une branche, à distinguer de ce que Git appelle déjà le en amont d'une succursale. Ensuite,
Git Journal Pourrait être par défaut sur .. la tête et la définition du parent de la branche actuelle suffirait pour la plupart de vos utilisations. Git n'a pas vraiment cela, mais il a des configurations flexibles. Vous pouvez faire un alias qui exécute
git log $ (parent git). Head oùgit-parent est votre propre script qui obtient ou définit ce paramètre "Parent". Le moyen évident de stocker est avecbranche. .parent . Appelez-le «Parent» pourrait être trop éloigné, au moins à ce stade, mais j'espère que l'idée elle-même est claire. @torek Je comprends que, dans Git, les branches ne sont guère plus que des indicateurs qui se déplacent avec le temps. Mais je n'essaie pas d'obtenir des informations sur les succursales qui ont été supprimées (par exemple, pour une commission arbitraire, quelle branche a-t-elle été faite). Mais le stocker (en
.gitconfig Je suppose que vous voulez dire?) Semble avoir de sens. Semblable à ce que Mark mentionné , mais c'est bien que ce n'est pas une étiquette pour que cela n'implique pas beaucoup de choses.À droite. Cette idée particulière (stockage d'une branche
de configuration. .parent ou peut-être succursale. .top ou d'autres) est juste un moyen de dire à votre section locale Git: "Je veux traiter cette gamme de commits, délimitée par parent..Branch, comme le permet d'utiliser la plupart du temps." Le parent ou l'arrêt pourrait être un identifiant de hasch brut ou un nom; Le nom serait résolu de la même manière que gitravisions (ou Git Rev-Payse ) résout tous les noms.@torek j'ai utilisé cette approche ici et cela fonctionne assez bien. J'ai également reçu un formulaire pour mettre à jour le "parent" lorsque vous rebasez aussi. Merci pour les suggestions :)