Jak „zacząć od nowa” w GitHub?


14

Planuję całkowite przepisanie mojego projektu, używając innego frameworka itp. Byłoby miło zachować stary kod wraz z historią w celach informacyjnych. Jak najlepiej to zrobić, aby uniknąć ryzyka, zamieszania i niespodzianek?

Moim pomysłem jest utworzenie nowej gałęzi, zastąpienie tam wszystkiego i uzyskanie uruchomionej tam podstawowej „nowej” wersji, oznaczenie ostatniego „starego” wzorca, a następnie połączenie gałęzi z wzorcem. Czy to brzmi rozsądnie?


18
To pytanie dotyczy Gita, a nie Githuba.
user253751

Jeśli nie planujesz edytować starego kodu, po prostu chcesz, aby łatwo mógł zobaczyć, że możesz użyć tagu. Ale tagi mają być niezmienne (ale zawsze można je usuwać, dodawać ponownie).
Travis

2
Utwórz nowe repozytorium.
CodeGnome

Odpowiedzi:


15

Głosuję za utrzymaniem wszystkiego w jednym repozytorium.

Ja bym:

  1. Utwórz nowy oddział, aby wskazywał na stary kod
  2. Usuń cały kod i zatwierdź na master
  3. Rozpocznij przepisywanie na master.

Oto jak:

# 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"

Poza tym: Możesz również utworzyć tag starego, starszego kodu, jeśli wiesz, że nigdy nie będziesz chciał dodawać do niego żadnych zatwierdzeń.

Kiedy zamiast tego zrobić nowe repozytorium:

  • Gdy bieżące repo jest zbyt duże i klonowanie repo jest powolne. Państwo może warto rozważyć przy użyciu nowego repo.

8

O ile nie ma pilnego powodu, aby połączyć przepisane i historyczne gałęzie, trzymałbym je osobno. Utwórz nową gałąź, aby zachować stary kod, przepisz w master i zachowaj je w ten sposób oddzielone. W ten sposób zawsze możesz pracować ze starym frameworkiem / implementacją, jeśli sytuacja się zmieni.


3

Po to są osierocone gałęzie.

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

Może być konieczne tymczasowe ustawienie domyślnej gałęzi na new_branchGithub, ponieważ domyślnie wyświetla master.


2

Możesz utworzyć nową gałąź w bieżącym projekcie, ale może być lepsze oznaczenie repozytorium jako prywatne, a następnie utworzenie nowego dla nowego kodu, w ten sposób nadal będziesz mieć stare repozytorium, ale przestanie być przestarzałe.

Sugeruję, abyś zastosował to podejście zamiast próbować później połączyć gałąź z powrotem w celu opanowania nie tylko dlatego, że nadal będziesz mieć rozdęcie z przestarzałego kodu, ale także dlatego, że do czasu, gdy będziesz gotowy, może wystąpić kilka frustrujących konfliktów scalania zrób to. Aby tego uniknąć, najlepiej byłoby zacząć od wyraźnej gałęzi, niż scalać dwie zupełnie różne gałęzie.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.