1
votes

Conserver l'historique des premiers commit lors de la préparation de la version initiale

Disons que je démarre un nouveau projet et le suit dans git. J'ajoute Feature 1 , puis je m'engage. J'ajoute ensuite Feature 2 et je m'engage. Enfin, après avoir ajouté Feature 3 , je décide que je souhaite publier ce projet. Je crée un troisième commit avec le message Initial Release . Je renomme la branche master actuelle en dev . Maintenant, je veux créer une NOUVELLE branche principale dont l'historique montre UNIQUEMENT le commit Initial Release .

Je pourrais faire

git checkout dev
git rebase -i --root

Cela m'aurait jusqu'à un seul commit, à partir duquel il est facile de commencer à rebaser sur ma nouvelle branche master . Mais que faire si je veux conserver mes deux premiers commits sur la branche dev ? Je veux pouvoir les regarder en arrière pour voir comment j'ai construit l'application, mais je veux que la branche master ait un historique propre qui COMMENCE avec le commit Initial Release .

Est-ce possible? Ou ma branche master doit-elle afficher chaque ancêtre commun jusqu'au premier commit?

git

3 commentaires

Je suggère de lire sur les balises et l'option --first-parent pour log .

Merci pour le conseil. Cependant, le but est que lorsque je pousse master en amont, il n'aura aucun des premiers commits.

Si vous avez une nouvelle branche master avec une seule révision ... comment faire pour garder dev par rapport à cette nouvelle branche master? ... ma question serait plutôt: que voulez-vous que dev soit par rapport au nouveau maître?

3 Réponses :

2
votes

Vous pouvez produire n'importe quel graphe de validation de votre choix avec le contenu de votre choix. Commencez comme suit:

...C---D   dev
      /
    D'     master

qui vous amène de

git checkout -B dev $(  # add a parent, keep existing message and tree:
        git show -s --pretty=%B dev | git commit-tree -p dev^ -p master dev:
        )

A---B---C---D    dev

           D'    master

où D 'a le contenu de D.

Si vous n'avez pas besoin de fusionner de master en dev, s'il s'agit d'une branche d'historique de publication uniquement, vous avez terminé. La prochaine fois, ajoutez -p master à l'arborescence de validation pour enregistrer l'ascendance.

Si vous souhaitez fusionner à partir de tout travail de développement, vous devez également fournir une fusion de l'historique maître à l'historique des développeurs, je le ferais probablement en réécrivant le conseil dev pour inclure le nouvel ancêtre, après avoir créé le nouveau conseil maître,

A---B---C---D    master

2 commentaires

Ce sont des réponses comme celle-ci qui me font réaliser combien il y a à apprendre sur git! Merci! Je suis heureux d'avoir cette réponse à titre de référence, et je vais peut-être aller dans ce terrier à l'avenir, mais c'est exagéré pour ce projet. Pour l'instant, je viens de créer une branche supplémentaire avec mes premiers commits, en supprimant master , en écrasant dev en un seul commit, puis en fusionnant dev dans master . Ce que je retiens de cette réponse, c'est qu'à moins que ces premiers engagements ne soient vraiment précieux, il ne vaut pas la peine d'essayer de les conserver, du moins pas dans le cadre d'une branche active.

Yah, votre méthode vous a laissé un commit de fusion supplémentaire qui n'était pas strictement nécessaire et est passé par quelques girations enchaînant des commandes pratiques pour contrecarrer les bits que vous ne vouliez pas, mais à part ce commit de fusion supplémentaire, vous avez exactement le même effet.

1
votes

Je le ferais comme ceci:

git checkout feature3 # or the revision that says "initial release"
git checkout -b new-master --orphan # new master, orphan, everything will be in index, no parent revisions
git commit -m "Initial release"
# if you like the result
git branch -f master # point master where we are
git checkout master
git branch -d new-master

1 commentaires

Intéressant! Donc dans ce cas, vous avez TOUJOURS un seul commit sur la branche master. Pas tout à fait ce que je recherchais, mais j'ai l'impression que cela pourrait être utile à un moment donné.

0
votes

(sur la branche master):

git checkout -b dev    #create new dev branch at master
git branch -D master   #delete master branch
git checkout --orphan master   #create new orphan master branch and switch to it
git commit             #commit current changes (which should be the "Initial Release")

Vous avez maintenant un seul commit sur master, et tous les commits originaux sur dev

2 commentaires

Si vous faites cela, vous ne pouvez pas fusionner sans l'indicateur --allow-unrelated-histories et sans corriger manuellement les conflits. Accomplit l'objectif principal, mais au détriment de la destruction de la relation entre les branches dev et master (ce qui semble être le nœud de ce problème).

Vous avez raison, si vous avez l'intention de fusionner à l'avenir entre dev et master, ce n'est pas une bonne solution. Malheureusement, je ne connais pas de moyen de cacher les commits précoces de la branche master tout en gardant une bonne relation de fusion avec la branche dev. Avec cette solution, plus aucun développement ne doit être effectué sur la branche dev. Il n'est là que pour l'historique ... afin que vous puissiez garder une trace de l'historique que vous ne voulez pas voir visible sur master.