Vous êtes sur votre projet .net framework, ou votre projet .net core. Vous faites un fetch sur le repo commun. Et là, de nouveau, de nouveau !, vous récupérez un web.config / appsettings.json modifié, à cause de la chaine de connection qui a encore été commit ….
Comment diable éviter ça à chaque fois ?
Vous le savez, dans git, un des fichiers les plus importants, c’est le gitignore.
Du coup la solution, simple à priori, c’est de mettre le web.config / appsettings en gitignore.
Ah ?! comment ça, ça ne fonctionne pas ?
Ben oui, vous souhaitez aussi pouvoir récupérer votre travail chez vous (vous faites et du remote, et du travail dans l’entreprise).
Dans la plupart des outils de gestionnaire de sources d’aujourd’hui (gitlab, github, bitbucket, …), vous avez un pouvoir immense, qui est à portée de main : le fork.
Oui, le fork !
Une fois ce système mis en place, pour mettre à jour le repository commun, comment faire ?
Il vous suffira de faire un Pull Request / Merge Request sur le repository commun.
C’est beaucoup plus propre, et en plus, cerise sur le gateau, ça permet aussi de favoriser une communication entre les devs !
Sans aller vers le fork (même si je vous invite à le mettre en place), vous pouvez utiliser une technique qui est déjà présente dans Visual Studio / Msbuild.
Vous connaissez le principe depuis votre web.config, d’avoir des sous config, avec le configSource ?
Et hop, le tour est joué !
Pour la partie .net core, c’est encore plus simple, puisque les fichiers sont choisis suivant la valeur dans la variable d’environnement “ASPNETCORE_ENVIRONMENT”.
Et hop, le tour est joué ! 🙂