Git - Jak zgnieść zmiany do zignorowanych plików bez utraty tych zmian?

Question

Chcę użyć git, aby zachować historyczny zapis faktycznych zależności używanych przez aplikację w czasie, z większą wiernością, niż mogę uzyskać od menedżera pakietów.

Używam tych gałęzi:

• mistrz: tylko kod źródłowy. Zależności w .gitignore
• produkcji: kodu źródłowego i zależności
• Build- $ TIMESTAMP: chwilowy oddział wykorzystane do wymuszenia popełnić ignorowanych plików

a ten skrypt, build-release.sh:

DEV_MODULES="mocha chai bower coffeelint" 
BUILT_FILES="node_modules build" 
DATE=$(date) 
TIMESTAMP=$(date +"%s") 
BRANCH=$(git rev-parse --abbrev-ref HEAD) 

# create a temporary branch with the current dependencies and binaries 
npm uninstall $DEV_MODULES 
git checkout -b build-$TIMESTAMP 
git add --all --force $BUILT_FILES 
git commit -m "copy $BUILT_FILES from $BRANCH" 

# merge the temporary branch into the build branch 
git branch build || echo "build branch already exists" 
git checkout build --force 
git merge build-$TIMESTAMP --strategy=subtree -m "Build as of $DATE" 
git branch -D build-$TIMESTAMP 

# restore the original branch 
git checkout $BRANCH 
git checkout build -- $BUILT_FILES 
git rm -r --cached $BUILT_FILES 

Który działa i daje mi użyteczny widok zmian w źródle, zależnościach i plikach binarnych z jednej wersji na drugą:

Wymaga to jednak dwukrotnie większej liczby zatwierdzeń. Chcę drzewo wyglądać tak:

Jak mogę połączyć „Kopiuj pliki budowane” popełnić z „budować jak z” popełnić?

Kiedy próbuję git merge --squash, kończy się z państwem, które było na build zamiast stanu, który był na build-$TIMESTAMP, która jest niepoprawna (chcę zaimportować zmiany do ignorowanych plików, ale połączyć wydaje się nie mieć język Zrób to). Kiedy próbuję git rebase --onto build build-$TIMESTAMP, tracę pochodzenie nowego zatwierdzenia.

Chcę nagrać dokładnie pliki dostaję na build-$TIMESTAMP oddziału, ale zarówno z build i master gałęzie jak rodziców, a następnie wskazać build oddziału do tego zobowiązać.

Answer 1

To jest proste terytorium hydrauliczne. Używasz komend "porcelany", systemu kontroli źródła opartego na rdzeniu śledzącym zawartość Git, w sposób, który sprawia, że ​​porcelana robi to, co chcesz, ale o wiele łatwiej jest po prostu porozmawiać bezpośrednio z trackerem treści .

Dla najprostszego czytania tego, co jest w twoim pytaniu, a mianowicie, że chcą się „zbudować” oddział do rejestrowania migawek bieżącego kasie wraz z wyborem, co jest w tych "$BUILT_FILES" Ścieżki/katalogów, to

# knobs 
DEV_MODULES="mocha chai bower coffeelint" 
BUILT_FILES="node_modules build" 
DATE=$(date) 

# clean out stuff we don't care about 
npm uninstall $DEV_MODULES 

# record current checkout plus "$BUILT_FILES" to `build` branch 
git add --all --force $BUILT_FILES 
build=`git rev-parse -q --verify build` 
git update-ref refs/heads/build $(
     git commit-tree ${build:+-p $build} -p HEAD \ 
       -m "build as of $DATE" \ 
       `git write-tree` 
) 

# reset index to HEAD 
git reset # `git read-tree HEAD` will have the same effect, perhaps more quietly 

Jako krótki przegląd lub przypomnienie, w zależności od przypadku, baza danych obiektu git jest magazynem kluczy i indeksów indeksowanych hashcode. Pytasz git o cokolwiek przez jego typ i hash, to uprzejmie regurgitates dokładnie to z jego obiektu db. Indeks jest niczym więcej jak plikiem płaskim, plikiem indeksowanym ścieżką, pokazującym, jaka zawartość w obiekcie db znajduje się w jakiej ścieżce, wraz z niektórymi metadanymi i uwagami do śledzenia operacji wykonywanych na pokładzie. git add Zawartość w ścieżce po prostu umieszcza zawartość w obiekcie db i zawartość mieszania we wpisie indeksu dla tej ścieżki.

(trochę tu rantu, pomińcie, jeśli nie jesteście w nastroju do głoszenia) Należy zrozumieć, że git jest całkowicie, brutalnie konkretny. Wszystko o repozytorium poza obiektem db to czysta konwencja. git checkout powoduje, że HEAD odwołuje się do zatwierdzenia, które wymeldowałeś się wyłącznie na podstawie konwencji. Możesz wdrożyć git checkout jako wyjątkowo cienką powłokę wokół git read-tree -um - główną dodatkową operacją jest ustawienie HEAD do zatwierdzenia, z którego otrzymałeś to drzewo. git commit czyni HEAD rodzicem tego, co robisz wyłącznie na podstawie konwencji. Możesz zaimplementować git commit jako wyjątkowo cienką powłokę wokół git commit-tree i git write-tree, główną dodatkową operacją jest dostarczenie HEAD jako rodzica i dodanie do nowego zatwierdzenia HEAD. Nazwa HEAD sama jest czysto konwencjonalna. Moduł do śledzenia treści, na którym zostały zbudowane, nie może obawiać się, że ma on do czynienia z rozróżnieniem gałęzi i tagów lub czymkolwiek w tym rodzaju. Konwencje są celowo, agresywnie i brutalnie proste, ponieważ (a) nie ma potrzeby abstrakcji, model zawartości już doskonale odpowiada wymogom i (b) cały punkt git to brak abstrakcji w rdzeniu: jest "głupi ".

Answer 2

Moim zdaniem, najlepszym rozwiązaniem byłoby zmienić sposób korzystania z git tutaj. Git to system kontroli wersji i służy do śledzenia zmian plików w czasie. Ponieważ stale dodajesz i usuwasz pliki, tracisz je i używasz jako magazynu plików. Dlaczego więc nie używać magazynu plików? Myślę, że twoje rozwiązanie jest sprytne, ale pachnie do mnie tak, jakbyś "walczył z ramą".

Myślę, że jeśli chcesz zachować rejestr utworzonych plików i rzeczywistych zależności, lepiej jest zip wszystko i zarchiwizować gdzieś w ramach procesu kompilacji.