Np powiedzmy, ze mamy spory plik excel i napisalismy program w Python do parsowania i generowania insertow co sa potrzebne, albo jakies mapowanie czegostam. I caly serwis to jest powiedzmy jakis mikroserwis w springboot korzystajacy posrednio z tych danych - ale nie ze skryptu, ktory jest pomocny tylko lokalnie dla developera.
Czy jest sens pushowac taki skrypt na "dev" branch i czy w takim wypadku jest sens pushowac go dalej na "qat"? Nie ma sensu zasmiecac wyzszych env typu PROD/UAT jak nie bedzie to tam wykorzystywane. Jak ktos automatycznie sprawdza roznice dev-qat, to taki plik moze przeszkadzac, bo sie bedzie platac, pokazywac roznice gdzie jej nie ma.
Z drugiej strony nie spushowac, to plik sie zgubi, albo strata czasu, szukac tego lokalnie.
Robic inne repo specjalnie, tez moze byc strata czasu i biurokracja. Mozna zrobic oddzielnego brancha, ale ktors moze zrobic purge przy migracji i usunac. To co w koncu robic z takimi skryptami?
Companion repo brzmi sensownie 
Ciekawe pytanie, sam nie jestem przekonany, bo oba rozwiązania (to samo repo i inne repo) mają wady i zalety, ale chyba wolałbym, żeby cały kod powiązany z daną aplikacją był jednak w jednym repo. Tak, będzie trzeba pewnie formalnie przepchnąć "pustą" zmianę na wyższe branche/środowiska (bo zakładam że ten skrypt po prostu sobie leży w katalogu gdzieś, gdzie nie jest brany pod uwagę przy budowaniu), ale to jest (przynajmniej dla mnie) akceptowalny narzut.
EDIT: czyli w praktyce, masz projekt typu Maven, i po prostu robisz katalog /tools czy /utils czy cokolwiek, i wpieprzasz tam cały ten majdan. Jak ktoś przegląda PR to wie po nazwie folderu, że to nie jest używane na produkcji (przynajmniej w zamyśle). Tak samo jakieś dane przykładowe ale nieużywane w testach.
lambdadziara napisał(a):
Czy jest sens pushowac taki skrypt na "dev" branch i czy w takim wypadku jest sens pushowac go dalej na "qat"?
Ja bym się zastanowił czy w ogólności jest sens posiadania brancha per środowisko, bo z opisu rozumiem, że tak macie.
lambdadziara napisał(a):
Nie ma sensu zasmiecac wyzszych env typu PROD/UAT jak nie bedzie to tam wykorzystywane.
W jaki sposób doszedłeś do tego że będzie to zaśmiecać PROD? O ile ten Spring mikro serwis nie wystawia wszystkich plików które są w repo do internetu to jest dobrze 
Ja preferuję mieć wszystko w jednym repo. Aczkolwiek wydaje mi się że pytasz o gusta, a więc to zależy.
W jaki sposób doszedłeś do tego że będzie to zaśmiecać PROD
Zwróciłeś mi na jedną rzecz uwagę - w przypadku chorych korpo, w których mamy drakońskie skany i statyczną analizę kodu -> zdecydowanie osobne repo. Tłumaczenie się, że w repo javowym masz skrypt w JS i tak naprawdę jest tylko odpalany lokalnie, a 1337 przestarzałych zależności to nie jest istotny problem do rozwiązania, to raczej strata czasu.
Ma sens zaśmiecać to można traktować jako kopie zapasową za jakiś czas będziesz czegoś szukać to sobie pomyślisz, a na gicie to było i może przetrwało.
Git też nie zapisuje wszystkiego, a różnice, czyli w miarę jest optymalnie im więcej kopii tym lepiej kiedyś coś się spiepszy jakiś dysk czy coś i będziesz szukać jak problem rozwiązać, a na szczęście będzie kopia na githubie czy gdzieś.