github tutorial developers how use github
Questo tutorial su GitHub spiega cos'è GitHub e come creare un repository, branch e pull request. Include le regole di protezione dei rami e la risoluzione dei conflitti:
Cos'è GitHub?
GitHub è un servizio cloud che aiuta gli sviluppatori a memorizzare e gestire il proprio codice sorgente, nonché a tracciare e controllare tutte le modifiche al codice sorgente.
In termini semplici, GitHub è pensato per gli sviluppatori in cui possono gestire il progetto, ospitare il codice sorgente e rivederli. Esploreremo tutti questi elementi in questa serie.
Elenco dei tutorial in questa serie GitHub:
Tutorial n. 1: Tutorial su GitHub per sviluppatori | Come utilizzare GitHub (Questo tutorial)
Tutorial n. 2: Progetti GitHub, team, fork e wiki per la documentazione di progetti
Tutorial n. 3: Comandi Git avanzati e tutorial sull'integrazione di GitHub
Tutorial n. 4: Tutorial sull'API REST di GitHub - Supporto API REST in GitHub
Tutorial n. 5: Tutorial desktop GitHub: collabora con GitHub dal tuo desktop
Tutorial # 6: Tutorial TortoiseGit - Come usare TortoiseGit per il controllo della versione
Cosa imparerai:
Cos'è Git?
Git è un sistema di controllo della versione Open Source in cui l'intero codice sorgente è disponibile sul computer dello sviluppatore. Git è anche un client e un sistema di controllo della versione distribuito (DVCS) in cui è possibile eseguire ramificazioni e fusioni.
Introduzione a GitHub
Per iniziare con GitHub, eseguiremo i seguenti passaggi.
- Crea un repository per organizzare i progetti.
- Crea un ramo
- Apporta le modifiche al file ed esegui il commit.
- Crea una richiesta pull per unire i contenuti.
- Proteggi filiale
Nella seconda parte della serie, esamineremo anche le altre funzionalità di GitHub come la creazione di organizzazione, team, problemi, pietre miliari, fork, rilasci e wiki.
Crea un repository GitHub
Un repository GitHub contiene gli artefatti del progetto come codice sorgente, documenti, immagini, ecc. Creeremo e utilizzeremo un repository demo per eseguire tutti i passaggi precedenti.
Accedi a Github.com e Crea un nuovo repository . Clicca sul Nuovo pulsante.
Aggiungi i dettagli del repository di seguito come mostrato e fai clic su Crea repository . Imposta l'accesso su Privato o Pubblico. È meglio impostarlo come pubblico poiché poche funzioni dipendono da questo accesso.
Nota: l'utente che crea il repository è il proprietario del repository GitHub.
Il repository viene creato con un file README.
Aggiunta di collaboratori al repository GitHub
Vorremmo che il team lavorasse su questo repository. Per questo dovremo invitare i collaboratori a lavorare sul repository. Per aggiungere collaboratori, vai alla pagina principale del Repository e fai clic sul impostazioni icona.
Clicca su Collaboratori nel riquadro di sinistra e aggiungi i collaboratori che hanno un account Github. Verrà inviato un invito e i collaboratori dovranno accettare l'invito.
I collaboratori vengono aggiunti come mostrato di seguito. Successivamente, in questo tutorial, vedremo come i Collaboratori verranno aggiunti come revisori per la richiesta pull creata per unire il codice.
Esecuzione di un Basic C ommit
Apri il file README ed esegui un commit di base. Clicca sul Icona Modifica per iniziare a modificare il file.
Modificare il file, aggiungere un commento e fare clic su Commettere .
Il file viene salvato (modifiche salvate) nel repository Github.
Verranno visualizzate poche operazioni per creare cartelle e file all'interno del Repository.
Per creare la cartella e un file all'interno: Clicca sul Crea nuovo file pulsante a livello di repository. Digitare il nome della directory seguito da / e il nome del file come mostrato di seguito.
Clicca su Commettere in fondo. La cartella e il file vengono creati come mostrato. Pertanto, i file e le cartelle vengono creati in maestro branch che è il ramo di integrazione principale e principalmente dove è possibile creare le versioni del software.
Gli sviluppatori normalmente lavorano all'attività assegnata loro su un ramo separato e uniscono le modifiche al ramo principale. Per esempio, È possibile creare rami per lo sviluppo di funzionalità o risolvere bug o lavorare su miglioramenti, ecc. Pertanto, creando un ramo il lavoro viene isolato senza disturbare gli altri rami.
Nel passaggio successivo, possiamo esaminare come creare i rami e definire le richieste pull per rivedere e unire il codice nel ramo principale.
Spostare un file
Per spostare un file in un'altra cartella, procedere come segue. Per esempio, per spostare il file rules.txt in una cartella doc. Fare clic sul file.
Fare clic sull'icona per modificare il file.
Aggiungi il percorso doc / prima del file rules.txt . Clicca su Effettua modifiche.
Il percorso è ora aggiornato.
Creazione di un ramo GitHub
Vai alla pagina principale del Repository e digita per creare un file caratteristica ramo come mostrato. Clicca su Crea ramo.
Ora siamo in caratteristica ramo. I file sono gli stessi. Apporteremo ora alcune modifiche ai file in caratteristica branch e creare una richiesta pull per esaminare le modifiche e unire il codice nel file maestro ramo.
Apporta modifiche ai file nel ramo delle funzionalità.
Apri il file Java nella cartella Src e aggiungi del codice e salva la modifica.
Crea una richiesta pull di GitHub
Nella sezione precedente, abbiamo creato un ramo caratteristica e ha apportato alcune modifiche a un file. Le modifiche non sono in maestro ramo. Per questo, dobbiamo creare una richiesta pull in base alla quale l'utente propone che alcune modifiche vengano riviste e unite al file maestro ramo.
La creazione di una richiesta pull mostrerà le differenze tra il ramo di origine e quello di destinazione e sarà richiesto per risolvere eventuali conflitti.
Clicca su Confronta e richiama nella pagina principale del repository.
Puoi vedere che le modifiche su entrambi i rami possono essere unite. Clicca su Crea richiesta pull.
Clicca su Unisci richiesta pull e Confermare per completare l'unione.
Le modifiche sono state unite con successo nel file maestro ramo. La nostra prima richiesta di pull è stata completata con successo.
Assegna revisori con richieste pull e revisione del codice
Github ha una buona caratteristica di utilizzare un file CODEOWNERS in cui possiamo selezionare le persone responsabili del codice sorgente nel repository. I proprietari del repository possono creare questo file e tutti gli utenti definiti nel file vengono richiesti per impostazione predefinita per la revisione durante la creazione della richiesta pull.
Per utilizzare questa funzionalità, è necessario utilizzare la versione GitHub Pro o rendere pubblico il repository.
Nella radice del repository, crea questo file nel seguente formato e salva il file.
* @username o @orgname o @teamname
* significa principalmente tutti i file nel repository. È inoltre possibile specificare estensioni specifiche come * .java o * .js ecc. Agli utenti definiti nel file verrà inviata automaticamente una richiesta di revisione. Con il file CODEOWNERS definito, non è necessario aggiungere esplicitamente revisori manualmente e ha un po 'più di flessibilità nella scelta dei file da rivedere.
Di nuovo in caratteristica branch apporta una piccola modifica al file Java e crea una richiesta pull. Nella schermata Pull Request assegnare un revisore sul lato destro. Clicca su Crea richiesta pull.
Puoi vedere nella schermata sopra che i revisori possono essere assegnati manualmente ma i revisori sono definiti nel file CODEOWNERS che riceveranno automaticamente una richiesta per rivedere le modifiche al codice.
Comunque, per ora, andiamo Accedere come revisore e approva le modifiche. Accedi come utente vniranjan2512 per approvare le modifiche.
C'è una richiesta per approvare / rifiutare le modifiche, sotto Richiesta pull.
Fare clic sulla richiesta di pull e Aggiungi la tua recensione.
Puoi fare clic sul file + firmare e aggiungere commenti di revisione per la riga di codice aggiunto / modificato / eliminato, nella schermata che viene visualizzata.
Clicca su Avvia una revisione.
Clicca su Termina la tua revisione. Approva come mostrato e invia recensione .
Di nuovo come l'utente originale che ha sollevato una richiesta pull, puoi aggiungere un commento e risolvere o chiudere la conversazione.
La richiesta pull Merge può ora essere completata.
Le modifiche vengono unite con successo nel file maestro il ramo pubblica la revisione e unisce la richiesta pull.
Quindi, per riassumere in questa fase, abbiamo visto che gli sviluppatori lavorano su caratteristica branch e quindi sollevare una richiesta pull per unire le modifiche al file maestro ramo. Quanto sopra era uno scenario in cui i conflitti non c'erano. Nella sezione successiva, vedremo i modi per risolvere i conflitti manualmente se i file vengono modificati in più rami.
Risoluzione dei conflitti
È possibile che gli stessi file in più rami vengano modificati. In questo caso, ci sarebbero conflitti e devono essere risolti tramite la richiesta pull generata.
Per esempio, apportare modifiche al file Java in entrambi i file maestro e caratteristica si dirama e solleva una richiesta pull.
Il messaggio di richiesta pull mostrato è che le modifiche non possono essere unite automaticamente. Quindi i conflitti devono essere risolti. Procedi alla creazione di una richiesta pull.
Una volta che la richiesta di pull viene sollevata, i conflitti dovranno essere risolti facendo clic sul Risolvi i conflitti pulsante.
Rimuovere i contrassegni che essenzialmente risolvono i conflitti manualmente e fare clic su Contrassegna come risolto e Commit merge.
La vista finale del file dopo la rimozione dei contrassegni.
La richiesta di unione pull può essere completata. Il maestro e caratteristica i rami saranno ora identici.
È ancora possibile vedere nella schermata sopra che la revisione è richiesta ma non obbligatoria. Nella sezione successiva, vedremo le regole di protezione del ramo in cui il proprietario del repository può richiedere obbligatoriamente una revisione e proteggere anche il maestro branch dal commit direttamente su di esso ma solo tramite una richiesta pull.
Regole di protezione dei rami
Nelle sezioni precedenti, abbiamo visto le richieste pull di Github e anche la richiesta di revisioni che non erano obbligatorie o facoltative. Nel tipico codice di scenari di progetto, le revisioni sono un must e una parte del processo di sviluppo.
Vediamo come applicarlo.
In github.com questa funzionalità può essere impostata solo per i repository pubblici o utilizzando la versione Github pro. Nella pagina principale del repository vai a impostazioni e fare clic sul file Rami categoria a sinistra.
Clicca su Aggiungi regola sotto il Regole di protezione dei rami. La regola ha aggiunto richieste di revisioni di richieste pull obbligatorie da parte dei proprietari del codice prima dell'unione per maestro ramo.
Ciò garantirà anche che il file ramo principale è protetto e nessun commit diretto può essere eseguito su questo ramo e può essere eseguito solo tramite le richieste pull dopo un'attenta revisione. Questa impostazione è impostata dal proprietario del repository.
Una grande caratteristica davvero !!!
Clicca su Creare una volta fatto. Per testare questo scenario, apportare una modifica a un file in caratteristica branch e creare una richiesta pull.
La schermata seguente mostra che una revisione è obbligatoriamente richiesta dai proprietari del codice.
Pubblica la revisione dai proprietari del codice, la richiesta pull può essere unita.
In qualità di collaboratore del repository, se apporti modifiche a uno qualsiasi dei file, a causa delle regole dei rami protetti creati, non sarai in grado di eseguire il commit direttamente sul ramo master ma solo tramite una richiesta di pull dopo aver creato un ramo come mostrato sotto.
Trasferimento di un repository a un altro account utente
Normalmente, un repository utente personale ha un unico proprietario e tutti gli altri sono collaboratori. Quindi, in un certo senso, non puoi avere più proprietari in un repository di account utente. Ma la proprietà può essere trasferita a un altro account utente. Al termine, il proprietario del repository originale diventa automaticamente collaboratori nel nuovo repository dell'account utente.
Il nuovo proprietario può quindi iniziare ad amministrare gli elementi, i problemi, le richieste pull, i progetti, i rilasci e le impostazioni.
Normalmente, quando comandi come 'git clone' o 'git push' vengono eseguiti nel repository locale, i comandi verranno reindirizzati al nuovo repository. Ma quando esegui il comando 'git remote -v', verrà comunque visualizzato l'URL del repository originale. Per evitare confusione, passare al nuovo URL remoto invia il trasferimento del repository utilizzando il comando 'git remote set-url'.
Per trasferire un repository, vai alla scheda Impostazioni del repository e in Opzioni? Fare clic su Zona di pericolo Trasferimento
Immettere il nome del repository e il nuovo account utente a cui deve essere trasferita la proprietà.
Fai clic su Capisco, trasferisci questo repository
Dovresti vedere un messaggio che indica che il repository è stato trasferito al nuovo proprietario.
Verrà inviata una mail al proprietario originale del repository per approvare il trasferimento. Una volta approvato il trasferimento, il repository verrà trasferito al nuovo proprietario e il proprietario originale del repository verrà aggiunto come collaboratore.
Ora imposta il nuovo URL del repository nella macchina in cui è stato clonato il vecchio repository. I seguenti comandi devono essere impostati in tutte le macchine in cui è stato clonato il vecchio repository.
Tutte le richieste pull, i problemi e il wiki verranno trasferiti. Le assegnazioni dei problemi rimarranno intatte.
Alcuni utili comandi Git
Ci sono alcuni dei comandi Git di base da configurare inizialmente sulla tua macchina locale una volta che il client Git è installato sulla tua macchina Linux o Windows. Gli sviluppatori lavorano localmente, senza connessione al repository su GitHub, sulla copia completa del codice sorgente disponibile su GitHub e si sincronizzano con esso.
In primo luogo, imposta il tuo nome utente e indirizzo email per assicurarti che tutti i commit che utilizzi utilizzino queste informazioni.
git config –global user.name 'UserName'
git config - user.email globale 'myemail@myemail.com'
Quando è necessario aggiungere un messaggio durante i commit, è anche possibile configurare l'editor necessario per lo stesso.
lista doppiamente concatenata codice c ++
git config –global core.editor notepad
Ottieni un elenco di tutti i valori di configurazione impostati.
git config –list
A volte le organizzazioni dispongono di server proxy per la connessione a Internet. In tal caso, sarà necessario specificare un server proxy e un numero di porta per accedere a tutti i repository su GitHub.
git config –global http.proxyhttp: // Username: Password @ proxyserver: port
Clona o crea una copia locale del repository. Ottieni l'URL clone del repository in GitHub ed esegui il comando git.
Conclusione
In questo tutorial, abbiamo visto come uno sviluppatore può iniziare a lavorare su GitHub, direttamente dalla creazione di un repository GitHub, ramo, richiesta di pull, protezione di un ramo e alcuni comandi Git di base.
Nel nostro prossimo tutorial, vedremo le altre funzionalità di GitHub principalmente su come creare organizzazioni, team, fork di un repository, creare problemi, pietre miliari e associazione con richieste pull, wiki e i loro usi e pochi altri comandi Git avanzati che saranno utili agli sviluppatori.
Lettura consigliata
- Tutorial Java Reflection con esempi
- Git vs GitHub: esplora le differenze con esempi
- Tutorial Python DateTime con esempi
- Integrazione del selenio con GitHub utilizzando Eclipse
- Una rapida guida SoapUI per memorizzare i dati di richiesta e risposta in un file - Esercitazione SoapUI # 15
- Tutorial Bugzilla: Tutorial pratico dello strumento di gestione dei difetti
- 20+ Tutorial MongoDB per principianti: corso MongoDB gratuito
- Tutorial sullo sharding di MongoDB con esempio