Pliki .dot: najlepszy sposób na przechowywanie w podstawowym repozytorium Git
Zastrzeżenie: tytuł jest nieco przesadzony — istnieją również inne sprawdzone rozwiązania problemu. Myślę jednak, że poniższa technika jest bardzo elegancka.
Niedawno dowiedziałem się o pewnej świetniej technice w wątku w witrynie Hacker News na temat rozwiązań dotyczących przechowywania plików .dot. Użytkownik StreakyCobra pokazał swoją elegancką konfigurację i... to było genialne! Jestem w trakcie przejścia na tę technikę z własnego systemu. Jedynym warunkiem wstępnym jest zainstalowanie Git.
Tak określił wymagania swojej techniki:
brak dodatkowych narzędzi, brak łączy symbolicznych, pliki są śledzone w systemie kontroli wersji i można używać różnych gałęzi na różnych komputerach, a także replikować konfigurację w nowej instalacji.
Ta technika polega na przechowywaniu podstawowego repozytorium Git w folderze „pomocniczym” (na przykład $HOME/.cfg lub $HOME/.myconfig) przy użyciu specjalnie przygotowanego aliasu, aby polecenia były uruchamiane w tym repozytorium, a nie w zwykłym folderze lokalnym .git, co zakłóciłoby działanie innych repozytoriów Git.
Od zera
Jeśli wcześniej nie śledzono konfiguracji w repozytorium Git, możesz z łatwością zacząć używać tej techniki za pomocą następujących poleceń:
git init --bare $HOME/.cfg
alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'
config config --local status.showUntrackedFiles no
echo "alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'" >> $HOME/.bashrc- Pierwsze polecenie tworzy folder
~/.cfg, który jest podstawowym repozytorium Git, w którym będą śledzone pliki. - Następnie tworzymy alias
config, którego użyjemy zamiast zwykłego poleceniagit, gdy będziemy wchodzić w interakcje z naszym repozytorium konfiguracji. - Ustawiamy lokalne dla repozytorium oznaczenie, aby ukryć pliki, których jeszcze jawnie nie śledzimy. Dzięki temu po wpisaniu polecenia
config statusi innych poleceń pliki, które nie są istotne, nie będą wyświetlane jakonieśledzone. - Możesz również dodać definicję aliasu ręcznie do pliku
.bashrcalbo użyć dodanego dla ułatwienia czwartego wiersza.
Spakowałem powyższe polecenia jako fragment kodu w Bitbucket i dodałem do niego łącze za pomocą krótkiego adresu URL. Dzięki temu możliwa jest poniższa konfiguracja:
materiały pokrewne
Jak przenieść pełne repozytorium Git
POZNAJ ROZWIĄZANIE
Poznaj środowisko Git z rozwiązaniem Bitbucket Cloud
curl -Lks http://bit.do/cfg-init | /bin/bashPo wykonaniu konfiguracji każdy plik w folderze $HOME może być objęty kontrolą wersji przy użyciu zwykłych poleceń z Git zastąpionym nowo utworzonym aliasem config, na przykład:
config status
config add .vimrc
config commit -m "Add vimrc"
config add .bashrc
config commit -m "Add bashrc"
config pushInstalacja plików .dot w nowym systemie (lub migracja do tej konfiguracji)
Jeśli przechowujesz już konfigurację / pliki .dot w repozytorium Git, możesz zmigrować tę konfigurację do nowego systemu, wykonując następujące czynności:
- Przed instalacją upewnij się, że alias został zatwierdzony w pliku
.bashrclub.zsh:
alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'- Upewnij się też, że repozytorium źródłowe ignoruje folder, do którego sklonujesz konfigurację, aby uniknąć dziwnych problemów z rekursją:
echo ".cfg" >> .gitignore- Teraz sklonuj pliki .dot do podstawowego repozytorium w folderze „kropka” w swoim katalogu
$HOME:
git clone --bare <git-repo-url> $HOME/.cfg- Zdefiniuj alias w bieżącym zakresie powłoki:
alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'- Wyewidencjonuj rzeczywistą zawartość z podstawowego repozytorium do katalogu
$HOME:
config checkout- Powyższy krok może zakończyć się niepowodzeniem z komunikatem:
error: The following untracked working tree files would be overwritten by checkout:
.bashrc
.gitignore
Please move or remove them before you can switch branches.
AbortingDzieje się tak, ponieważ Twój folder $HOME może już zawierać standardowe pliki konfiguracyjne, które zostałyby zastąpione przez Git. Rozwiązanie jest proste: utwórz kopię zapasową plików, jeśli Ci na nich zależy — w przeciwnym razie usuń je. Oto skrót do automatycznego przenoszenia wszystkich plików, które mogą powodować problemy, do folderu kopii zapasowej:
mkdir -p .config-backup && \
config checkout 2>&1 | egrep "\s+\." | awk {'print $1'} | \
xargs -I{} mv {} .config-backup/{}- Jeśli wystąpiły problemy, uruchom ponownie operację wyewidencjonowania:
config checkout- W celu oznaczenia
showUntrackedFilesustaw wartośćnow tym konkretnym (lokalnym) repozytorium:
config config --local status.showUntrackedFiles no- Gotowe. Od teraz możesz wpisywać polecenia
config, aby dodawać i aktualizować pliki .dot:
config status
config add .vimrc
config commit -m "Add vimrc"
config add .bashrc
config commit -m "Add bashrc"
config pushAby mieć możliwość skorzystania z kolejnego skrótu i nie musieć pamiętać wszystkich tych kroków na każdym nowym komputerze, który chcesz skonfigurować, możesz utworzyć prosty skrypt, zapisać go jako fragment kodu Bitbucket, tak jak ja, utworzyć dla niego krótki adres URL i wywoływać go w ten sposób:
curl -Lks http://bit.do/cfg-install | /bin/bashOto całe końcowe rozwiązanie (testowane na wielu nowych kontenerach Alpine Linux):
git clone --bare https://bitbucket.org/durdn/cfg.git $HOME/.cfg
function config {
/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME $@
}
mkdir -p .config-backup
config checkout
if [ $? = 0 ]; then
echo "Checked out config.";
else
echo "Backing up pre-existing dot files.";
config checkout 2>&1 | egrep "\s+\." | awk {'print $1'} | xargs -I{} mv {} .config-backup/{}
fi;
config checkout
config config status.showUntrackedFiles noPodsumowanie
Mam nadzieję, że ta technika śledzenia konfiguracji okaże się przydatna. Jeśli Cię to interesuje, moje pliki .dot przechowuję tutaj. Bądź na bieżąco, obserwując @durdn lub mój niesamowity zespół @atlassiandev.
Udostępnij ten artykuł
Następny temat
Zalecane lektury
Dodaj te zasoby do zakładek, aby dowiedzieć się więcej na temat rodzajów zespołów DevOps lub otrzymywać aktualności na temat metodyki DevOps w Atlassian.
Blog Bitbucket
Ścieżka szkoleniowa DevOps
