Próbuję wymyślić lepszy sposób kontroli wersji naszych projektów witryn. Pamiętaj, że jestem tylko programistą front-end, więc nie mam głębokiej wiedzy o VCS.
Przepływy pracy zmieniają się, a nawyki kontroli wersji w przeszłości stają się przestarzałe. Główny problem polega na tym, że dla każdej witryny istnieją 2 tablice plików frontonu.
Środowisko deweloperskie (mniej plików, nieskompresowane pliki J, obrazy itp.). Środowisko kompilacji „gulpified” (wszystko skompresowane i nieczytelne dla ludzi).
Ale nie możesz sprzedawać witryny z plikami źródłowymi. Cóż, to nie jest w porządku.
Istnieje rozwiązanie polegające na posiadaniu 2 repozytoriów: jednej kompilacji, jednego programisty, z gulp wysyłającym pliki programistów do katalogu kompilacji. Ale jest to trudność do utrzymania, w małych firmach nie sądzę, że jest tak wspaniale. Tworzy wiele repozytoriów, a ludzie muszą radzić sobie z kilkoma repozytoriami, czasem nawet z jednym repozytorium svn, pojawiają się problemy.
Istnieje również rozwiązanie polegające na posiadaniu 1 repozytorium: plików źródłowych i plików prod w tej samej svn. Ale wtedy konieczne jest usunięcie plików źródłowych, gdy strona przechodzi z lokalnego serwera deweloperskiego na serwer produkcyjny (więc w jednym repozytorium znajdują się różne pliki, w zależności od lokalizacji, dewelopera lub produkcji ...). Z tego, co słyszałem, nie jest dobrze
Jaki jest prawidłowy sposób zarządzania przepływem pracy front-end w systemie kontroli wersji?
źródło
boot/ocamlc
melt/generated/*.cc