Come dovrei controllare la versione del mio profilo bash?

7

Quindi sono molto a mio agio con il controllo della versione, e ho pensato di iniziare a monitorare le versioni del mio profilo bash: ~/.bash_profile con l'ulteriore vantaggio di poter condividere i miei vari alias e simili su GitHub.

Supponendo che il mio file .bash_profile debba rimanere nella mia home directory (non posso inserirlo in una directory per tracciarlo da solo come un normale file), quale sarebbe il modo migliore per farlo? Non voglio inizializzare un repository git nella mia home directory e devo ignorare ogni altro file presente.

Quindi quale potrebbe essere una buona soluzione?

Suppongo che potrei semplicemente farne una copia in una directory separata e aggiornarla / commit di volta in volta, ma sono curioso di sapere se esiste un buon modo per controllare la versione di un singolo file in una directory popolata?

    
posta elliot627 25.02.2017 - 20:17
fonte

4 risposte

8

Afaik, in genere ci sono due modi per farlo: a) link simbolico b) script di sincronizzazione. In entrambi i casi, devi creare un altro repository (chiamalo dotfile sotto) per bash_profile per essere controllato dalla versione.

Usa i link simbolici

bash_profile viene spostato nella tua dir controllata dalla versione (contenente .git ), $HOME/.bash_profile è un collegamento software ⇢ $HOME/dotfile/bash_profile .

$HOME/dotfile/bash_profile è il luogo in cui risiede il tuo% attuale di% co_de, vedi holman dotfile come esempio.

Utilizza lo script di sincronizzazione

bash_profile rimane nella tua bash_profile dir ma è solo una copia di quella più recente. L'ultimo HOME vive ancora in bash_profile .

Sì, è un approccio di copia e incolla, questo è il motivo per cui hai bisogno di un po 'di $HOME/dotfile per salvarti dal lavoro DRY . vedi mathiasbynens dotfiles come buon esempio. Il suo syncing script link .

Inoltre

Come sospetti:

I'm curious if there's a good way to version control a single file in a populated directory

La versione che controlla un singolo file non ha molto senso, copia & incollare o semplicemente rilasciarlo in alcune unità cloud ti consente di risparmiare molto tempo.

Il punto reale è che le cose non vengono ridimensionate in questo modo, quando aumenta il syncing script nella tua dotfiles , quando vuoi controllare la versione del tuo editor di testo preferito (ad esempio $HOME ), quando usi vimrc per lavorare con più shell in remoto, potresti avere SSH , zshrc , bashrc ecc.

Questo significa che a lungo termine potresti voler controllare la versione di tutti fishrc s. Il dotfile di Github è un buon punto di partenza.

    
risposta data 26.02.2017 - 00:57
fonte
2

I don't want to initialize a git repo in my home directory, and have to ignore every other file present.

Perché no? Vuoi tenere traccia di un file nella tua home directory, quindi anche la tua home directory dovrebbe essere sotto controllo di versione.

Questo non significa che la tua home directory debba essere un repository git. Lasciami spiegare:

I repository git sono composti da due parti: un albero di lavoro (a meno che non si tratti di un repository nullo, ovviamente) e la directory "database" di .git . Di solito il dopo è solo una sottodirectory (nascosta) del primo, ma non è strettamente necessario. git supporta l'uso di un albero di lavoro distaccato . In questo modo puoi mantenere la tua home directory sotto controllo di versione ma non è necessario che contenga una directory .git che possa confondere gli strumenti (vim, emacs, ...) o git stesso.

Impostazione:

cd ~
mkdir .dotfiles
cd .dotfiles
git init .

Ora c'è una directory ~/.dotfiles/.git . Usalo ma specifica la directory home come albero di lavoro. Ciò richiede una linea di comando piuttosto lunga, quindi un alias è una buona idea:

alias dotfiles='git --git-dir ~/.dotfiles/.git --work-tree=$HOME'

Per usarlo basta usare l'alias sopra invece di git , ad es. dotfiles status .

I vantaggi:

  • nessun altro strumento necessario, solo git
  • nessuna funzione symlink infernale / fuori sincrono possibile
  • i repository git nelle sottodirectory sottostanti home non sono influenzati in alcun modo

L'ho preso da questo post del blog (che ha alcune informazioni aggiuntive) e lo sto usando senza problemi. Non lo so, ma con una semplice riga * in .gitignore è possibile liberarsi di una quantità enorme di file non tracciati e salvaguardarsi un po 'dall'aggiunta di file al repository che non si intende aggiungere.

    
risposta data 26.02.2017 - 15:52
fonte
1

Un'altra soluzione potrebbe essere quella di deportare la configurazione specifica (come l'impostazione dei propri alias o la definizione delle proprie funzioni) in un file diverso da .bash_profile . In questo modo, solo la tua configurazione specifica sarà versionata e dovrai solo provenerla dal tuo .bash_profile .

Esegui manualmente

Supponiamo che questo file di estensione% co_de sia denominato .bash_profile e contenuto nella directory bash_profile_ext :

Alla fine del tuo file /path/to/bash/profile/ext/ avrai:

source /path/to/bash/profile/ext/bash_profile_ext

E solo la tua directory .bash_profile sarà versionata.

Usalo con un'app di terze parti

Ancora più semplice (immagino :-)), sto sviluppando shprofile che ti aiuta a gestire il tuo profilo shell, concentrandoti solo sulla configurazione del tuo profilo specifico. shprofile consente di definire tutta la configurazione del profilo specifico in una singola directory, che può quindi essere versionata. Nota puoi anche gestire diversi profili per lo stesso utente.

Ancora una volta, non è necessario eseguire la versione di tutte le configurazioni /path/to/bash/profile/ext , ma solo i valori aggiunti.

    
risposta data 13.06.2018 - 09:20
fonte
0

Per la gestione della configurazione IT a livello aziendale, molti usano Puppet. Raccomando Puppet ai clienti come misura di contenimento e affidabilità dei costi. Qui in laboratorio, lo rendiamo semplice.

Il nostro repository principale contiene i file necessari per ricostruire completamente un sistema in crash o creare un nuovo account utente, e il controllo della versione è stato utile in diverse occasioni. Git va bene con i file e le directory che iniziano con un periodo fintanto che git non è configurato per ignorarli.

Questi sono percorsi di repository per l'installazione e la configurazione di sistemi e applicazioni.

knowledge.resources/install.linux/std.fedora.dnf.sh (dnf installations) knowledge.resources/install.linux/font.install.info.te (font installation) knowledge.resources/install.linux/std.fedora.te (other install and config)

Questi sono file di configurazione utente generici.

startup/linux.basic.user/.bash_profile startup/linux.basic.user/.bashrc startup/linux.basic.user/.vimrc startup/linux.basic.user/.gitmessage startup/linux.basic.user/.gitconfig startup/linux.basic.user/use.ls.al.to.see.dot.files.here

Questi sono per gli account remoti sui server.

startup/linux.remote/.bash_profile startup/linux.remote/.bashrc startup/linux.remote/.vimrc startup/linux.remote/.gitmessage startup/linux.remote/.gitconfig startup/linux.remote/use.ls.al.to.see.dot.files.here

Questi sono per l'account root.

startup/linux.root/.bash_profile startup/linux.root/.bashrc startup/linux.root/.vimrc startup/linux.root/use.ls.al.to.see.dot.files.here

Uso file di dimensione zero chiamati use.ls.al.to.see.dot.files.qui per ricordarmi che la directory LISTA è vuota.

    
risposta data 26.02.2017 - 04:13
fonte

Leggi altre domande sui tag