Il simbolo più ha un significato speciale nella maggior parte dei server di posta elettronica. Sebbene faccia parte dell'indirizzo, generalmente non influisce su chi riceve il messaggio. Quindi [email protected] va a [email protected]. Questo vale anche per Gmail for Business.
I filtri di Gmail non sono sofisticati come quelli, diciamo, in procmail o, per quanto posso dire, in Outlook. Ma se si ottiene [email protected], tutti i messaggi per queste coppie passeranno da lì. Ma puoi scrivere un filtro che cerca, ad esempio, per: yourname e taggalo con un'etichetta speciale.
Per questo motivo, e dato che Google limita il numero di regole che puoi avere per l'email in avanti, probabilmente inizierei semplicemente impostando dev up come alias o mailing list e assicurandoti che tutti ricevano quelle email. Consiglia ad ogni membro del team di impostare un filtro che assomigli a "dev: to theirname" e catturalo in un modo che attiri la loro attenzione (applica un'etichetta, esegui una stella o qualsiasi altra cosa per loro).
Se hai bisogno di qualcosa di più sofisticato di quello che offre Gmail, ad esempio solo inoltrando i messaggi pertinenti allo sviluppatore giusto, devi essere [email protected] un vero account. Puoi quindi utilizzare uno strumento come Sift , magari su un'istanza Amazon leggera o su una macchina sottoutilizzata seduta in un armadio da qualche parte, per elaborare i messaggi e inoltrarli quando necessario.
Un'altra alternativa è riconoscere che ci sono due campi di informazioni rilevanti memorizzate su ciascun commit: l'autore e il committer. L'autore e il committer sono automaticamente gli stessi in circostanze tipiche in cui più persone hanno i diritti di commit. Tuttavia, nei flussi di lavoro in cui una persona estrae un cambiamento da qualcun altro e la impegna nel repository principale, l'autore e il committer possono essere diversi. Puoi forzarlo a farlo utilizzando uno dei due meccanismi, spiegato su Un tour di Git :
If you specify a --author option to the “git commit” command on the
command line, followed by a "Real Name " string,
then this name and addresss will be used for the author fields. The
committer fields will still be determined as below. This option is
very helpful for when applying a commit originally authored by someone
other than yourself.
If any of the GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_COMMITTER_NAME,
or GIT_COMMITER_EMAIL environment variables are set, then those values
will be used for the corresponding fields
If you have a file in your home directory called .gitconfig, with name
or email settings in the [user] section, then these values will be
used to set any remaining author and committer fields. For more
details on the contents of this file, refer to section 2.7.1 below.
If you have a file in the local repository called .git/config, again with
name or email settings in the [user] section, then these values will
be used to set any remaining author and committer fields.
If you have
set the EMAIL environment variable, this will be used to set author
and committer email addresses if still unset. git will query your
system to find out your real name from available GECOS field and your
username, hostname, and domain to construct an email address, (or at
least an identifier resembling an email address).
In un contesto di accoppiamento, quale è l'autore e quale è il committer è una decisione arbitraria, ma il fatto è che la distinzione apre la porta a documentare entrambe le persone coinvolte in un particolare commit.
Un'integrazione continua o un sistema di compilazione ragionevolmente esperto potrebbe sfruttare entrambi i campi per inviare notifiche a due persone separate, che a mio avviso potrebbero funzionare in modo appropriato per le situazioni di abbinamento. Non so se sarebbe il tuo, non avendo esperienza diretta con esso, ma probabilmente merita un esperimento o forse un tuffo nella documentazione per scoprirlo.