Comment «recommencer» dans GitHub?

Je prévois une réécriture complète de mon projet, en utilisant un autre framework, etc. Ce serait bien de conserver l'ancien code, y compris l'historique pour référence. Quelle est la meilleure façon de procéder pour éviter les risques, la confusion et les surprises?

Mon idée est de créer une nouvelle branche, de tout remplacer là-bas et d'obtenir une "nouvelle" version de base, de baliser le dernier "ancien" maître, puis de fusionner la branche avec le maître. Cela vous semble-t-il raisonnable?

Je vote pour tout garder dans un seul référentiel.

Je voudrais:

1. Créez une nouvelle branche pour pointer vers votre ancien code
2. Supprimer tout le code et valider sur le maître
3. Commencez votre réécriture sur master.

C'est ainsi:

# checkout the master branch
git checkout master

# create a new branch so you can find the old code easily
git branch oldStuff-KeepingForReference

# push the branch to github
git push origin oldStuff-KeepingForReference

# You currently have the master branch checked out
# so now cd to the project root and start your rewrite: 
cd <your project root>
rm -rf *

# Create a commit of the delete
git add --all *
git commit -m "Fresh start"

# Start your rewrite
echo "Some changes" > file.txt
git add file.txt
git commit -m "This is the first commit of the rewrite"

En plus: vous pouvez également créer une balise de l'ancien code hérité, si vous savez que vous ne voudrez jamais y ajouter de commit.

Quand vous devez créer un nouveau référentiel au lieu de faire ceci:

• Lorsque votre dépôt actuel est prohibitif et que le clonage est lent. Vous voudrez peut -être envisager d'utiliser un nouveau dépôt.

À moins qu'il n'y ait une raison pressante de fusionner les branches de réécriture et d'historique, je les garderais séparées. Créez une nouvelle branche pour conserver l'ancien code, faites votre réécriture dans master et gardez-les séparés de cette façon. De cette façon, vous pouvez toujours travailler avec l'ancien framework / implémentation si la situation change.

C'est à cela que servent les branches orphelines.

git branch -m master new_branch       #rename the branch
git push origin new_branch:new_branch #push the old code
git push origin :master               #delete the origin/master branch containing the old code
git checkout --orphan master          #create a new orphane branch - master. The first commit made on this new branch will have no parents and it will be the root of a new history totally disconnected from all the other branches and commits.

echo foo > file.txt
git add file.txt
git commit -m 'init commit'
git push origin master

Vous devrez peut-être définirnew_branch temporairement la branche par défaut dans Github car elle affiche master par défaut.

Vous pouvez créer une nouvelle branche dans le projet en cours, mais il peut être préférable de marquer le référentiel comme privé, puis d'en créer un nouveau pour votre nouveau code, de cette façon, vous avez toujours l'ancien référentiel, mais le travail obsolète n'est pas surchargé.

Je vous suggère de prendre cette approche au lieu d'essayer de fusionner plus tard la branche vers master non seulement parce que vous aurez toujours ce ballonnement du code obsolète, mais aussi parce qu'il peut y avoir plusieurs conflits de fusion frustrants au moment où vous êtes prêt à faites le pull. Afin d'éviter cela, il serait préférable de commencer avec une branche claire plutôt que de fusionner deux complètement différentes.