Inviare una modifica

Avete una modifica pronta e volete restituirla.

Ci sono due vie, e quale valga dipende dall'entità. Un singolo file di testo si può creare o modificare e registrare direttamente nella schermata del repository. Tutto ciò che riguarda più file, è binario o va costruito e verificato in locale torna indietro attraverso l'endpoint Git.

Le due vie non richiedono lo stesso permesso, ed è il motivo più frequente per cui l'una funziona e l'altra no:

Vedere e ottenere non bastano per nessuna delle due. Quale livello un mount assegni a chi sta sotto Clonare un repository; il livello proporre lì non lo assegna nessuno dei modelli, nasce solo da una regola scritta apposta.

Via 1 — un singolo file di testo nel browser

1. Aprire il repository da Repository.
2. Verificare nell'intestazione su quale branch vi trovate — il commit va lì. Un altro si può scegliere in quel punto.
3. Un file esistente: aprirlo nell'albero, cambiare il contenuto, registrarlo con una descrizione. Vedi Modificare un file.
4. Un file nuovo: Nuovo file nell'intestazione, indicare percorso e contenuto, registrare. Se sotto quel percorso c'è già qualcosa, viene rifiutato e non si scrive nulla. Vedi Creare un file nuovo (in tedesco).
5. Se il vostro permesso non basta, queste possibilità non compaiono.

I file binari — immagini, archivi, caratteri — non passano per questa via. Per essi vale la via 2.

Via 2 — in locale, tramite Git

1. Verificate la vostra modifica secondo i cinque passi di collaudo da Allestire un ambiente di sviluppo.
2. Fate girare la verifica di stile e correggete i rilievi correggibili automaticamente:

composer cs
composer cbf

1. Aggiornate la data del manifesto del pacchetto modificato. È il segnale da cui un aggiornamento viene riconosciuto; se resta ferma, il pacchetto si annuncia come la revisione precedente.
2. Scrivete il testo del commit in modo che nomini il proprio elemento di lavoro in una riga finale a sé. Senza quella riga non nasce alcun legame fra elemento di lavoro e codice, e non c'è alcun avviso in proposito.
3. Restituite:

git push

Al livello proporre l'endpoint accetta solo branch sotto il vostro prefisso e rifiuta tutto il resto con push refused: outside_own_prefix. Il nome del branch e i due comandi necessari li nomina Clonare un repository.

Un push rifiutato è per lo più una questione di permessi, non un errore. Se nella sezione Dieses Repository beziehen c'è l'avviso di accesso in sola lettura, un push viene rifiutato; la via passa allora per Richiedere l'accesso. Se l'avviso non compare e viene comunque rifiutato, dipende dal nome del branch e non dal permesso — il messaggio dell'endpoint distingue i due casi.

Non stabiliti: branch, revisione, integrazione. Per questa impresa non esiste un modello di branching vincolante, né una procedura di revisione, né una regola di merge. Questa guida non ne inventa; descrive ciò che la piattaforma offre. Quale branch valga nel caso concreto e chi riveda, chiaritelo con la responsabilità del progetto. Lo stato completo sta sotto Stato delle regole di contribuzione.

Nessun registro delle modifiche come obbligo. Fra i pacchetti propri, uno tiene un registro delle modifiche; una convenzione coerente non esiste.

Non dimenticare le lingue. Se una modifica tocca i testi di interfaccia, essi vanno in tutti e cinque i file di lingua. Una voce mancante non mostra un errore, ma il nudo nome della chiave.

• Allestire un ambiente di sviluppo
• Stato delle regole di contribuzione
• Clonare un repository
• Modificare un file nel browser — la prima via in dettaglio
• Creare un file nuovo nel browser (in tedesco) — la stessa via per un file che non esiste ancora