Vous aurez besoin d'avoir un script de quelque sorte construire les différentes branches de contenu pour vous. Le moyen de base consiste à ajouter le contenu à la base de données (dans votre cas, en les validant à la branche master), puis dans un index temporaire, en lisant tous les contenus que vous voulez avoir dans chaque branche (git read -tree/git update-index), écrire cette arborescence (git write-tree), écrire un objet commit (git commit-tree) et mettre à jour la branche vers ce nouveau commit (git update-ref). Ce sont toutes des commandes de plomberie qui ne sont normalement pas utilisées dans les opérations quotidiennes, mais qui vous permettent de créer des instantanés sans avoir tout le contenu d'un répertoire sur le disque en même temps.
Un exemple de script pour faire quelque chose comme ceci est ici:
http://github.com/schacon/gitcrazy/blob/master/update_content.rb
Ici, je définir un certain nombre de serveurs qui ont chacun un ou plusieurs rôles (« memcache », « base de données » ou « serveur Web »). Ensuite, je peux ajouter du contenu à un rôle comme celui-ci:
$ update_content.rb /path/to/content file_name memcache
qui ajoutera le contenu à mon db git, puis mettez à jour les branches pour les serveurs qui sont touchés (qui ont le rôle memcache, dans ce cas). Je peux le faire pour plusieurs fichiers pour n'importe lequel des rôles et git gardera une trace du contenu que chaque serveur devrait avoir. Chaque serveur peut ensuite récupérer sa branche spécifique ('server/s1', 'server/s2', etc.).
Je pense faire un rapide screencast démontrant cela bientôt - espérons que l'exemple de script est utile. Il devrait être assez facile de courir et de comprendre ce qui se passe. Dans le même projet, il existe un script 'list' qui répertorie le contenu de la branche du serveur.
Merci pour cette information utile. Dans le script Ruby, d'où vient le mode 100644 dans cette commande 'git update-index --add --cacheinfo 100644 (sha1) (chemin)'? Merci! – Scud
et à la ligne 43: pcommit = (prev_commit! = "Servers/# {server}")? "-p # {prev_commit}": '' le prev_commit est sha1 où les serveurs/# {server} est une chaîne comme "master", donc il ne sera jamais égal à l'autre. Est-ce supposé être ainsi? Merci. – Scud
lorsque vous ajoutez du contenu à l'index (avec update-index) vous devez donner au fichier un mode - soit 100644 qui est un fichier normal, soit vous pouvez rendre le fichier exécutable (100755, je pense) ou un lien symbolique. C'est juste un mode de fichier unix. comme pour prev_commit - il sera égal à une valeur sha1 s'il y a une validation précédente, mais s'il n'y a pas de validation précédente - si les serveurs/{server} n'est pas encore défini, la commande rev-parse retournera la chaîne vous l'avez donné car il ne peut pas trouver un sha pour cela.c'est comme ça que je peux dire s'il n'y a pas encore de premier commit. espérons que cela aide. –