advanced git commands
Aquest tutorial explora comandaments Git útils com Git Stash, Git Reset, Git Cherry Pick, Git Bisect i explica com integrar GitHub amb Jira:
En els nostres tutorials anteriors d’aquesta sèrie, hem vist la majoria de les funcions de GitHub.
En aquest tutorial, veurem el següent:
- Creació de llançaments
- Integració amb Atlassian Jira
- Ordres Git més utilitzades per a desenvolupadors
- Git Stash
- Git Cherry Pick
- Restabliment de Git
- Git Bisect
=> Mireu aquí la guia de GitHub.
converteix diversos vídeos de youtube a mp3
Què aprendreu:
- Creació de llançaments
- Integració de GitHub amb Jira
- Comandaments avançats de Git per a desenvolupadors
- Conclusió
- Lectura recomanada
Creació de llançaments
Les versions de GitHub s’utilitzen per agrupar el vostre programari, afegir notes de versió i fitxers binaris (fitxers WAR, EAR, JAR) perquè els clients i les persones facin servir el mateix.
Per crear una versió, aneu a la pàgina principal del dipòsit i feu clic a Estrenes pestanya a sota Gestionar temes.
Fer clic a Creeu una versió nova.
Proporcioneu una etiqueta i un títol de llançament. Els fitxers binaris també s’afegeixen a la versió. Un cop fet, feu clic a Publica el llançament.
La versió ja està llesta amb el codi font i els fitxers binaris.
Integració de GitHub amb Jira
Un dels aspectes importants de la traçabilitat és fer referència al problema de Jira amb els commit en GitHub. GitHub es pot integrar amb Jira no només per fer referència al problema, sinó també per ajudar a crear sucursals i Pull Request des de Jira.
Normalment, una vegada que el desenvolupador comença a treballar en la tasca o els errors, ell crea una branca. Per publicar el desenvolupament o resoldre els errors, es pot crear una sol·licitud d'extracció de Jira per combinar-la amb la principal mestre branca. La sucursal creada pel desenvolupador es pot suprimir.
Per configurar la integració, hem utilitzat un complement Integració de Git per a Jira. Es tracta d’un complement comercial. El connector es pot descarregar des de aquí
Instal·leu el connector a Jira des de Administrador -> Complements.
Un cop instal·lat el connector, aneu a Aplicació -> Dipòsits Git i connecteu-vos a GitHub.
Introduïu el nom d'usuari i la contrasenya de GitHub. Feu clic a Connecteu-vos .
Es mostraran els dipòsits esmentats per al compte d'usuari. Fer clic a Importar dipòsits per acabar la configuració de la integració.
Compromís de GitHub amb el problema de Jira
Com a part del missatge de confirmació, entreu com es mostra a continuació. Fer clic a Fer canvis .
Exemple 1: A continuació es mostra un exemple de Compromís intel·ligent que permet als desenvolupadors realitzar accions sobre els problemes de Jira des del missatge de confirmació. Una d'aquestes ordres és la #comentari juntament amb la clau Problema que afegeix el comentari al número Jira, tal com es mostra a continuació.
S'ha actualitzat la secció de comentaris.
Exemple 2: Assigneu-ho a un usuari i actualitzeu el temps dedicat a 4 h.
Utilitzar el #assignar i #temps ordre smart commit al missatge de commit.
Totes dues accions s'han completat.
Exemple 3: Canvieu l'estat del problema a En progrés .
Crea una sucursal
Com que les tasques i els errors s’assignen als desenvolupadors, han de començar a treballar en el desenvolupament. Per a això, creen una branca per al tema en què estan treballant, fan les activitats de desenvolupament i plantegen una sol·licitud de tracció per fusionar-la a la branca mestra.
Al número de Jira, a la part inferior, feu clic a Crea una sucursal.
Fer clic a Crea una sucursal.
A GitHub, feu un canvi al fitxer de la branca creada anteriorment i cometeu el mateix.
A mesura que es completa el desenvolupament, l'usuari pot generar una sol·licitud d'extracció de Jira.
Feu clic a la part inferior del número Crea una sol·licitud d'extracció.
Fer clic a Crear. La sol·licitud d'extracció es mostrarà com a Oberta.
El següent pas és combinar la sol·licitud d'extracció a GitHub.
L'estat s'actualitza en conseqüència a Jira.
Comandaments avançats de Git per a desenvolupadors
En aquesta última secció, veurem algunes de les ordres Git més utilitzades per als desenvolupadors. Res a veure amb GitHub, però ajudarà els desenvolupadors abans que introdueixin els canvis a GitHub.
Git Stash
En la majoria dels escenaris del projecte quan esteu treballant en una nova característica o millora, de sobte caldria que treballeu en un defecte urgent que s’hagi informat i que sigui un tap. Com que esteu a mig camí del vostre nou treball i no l'heu acabat, no té cap sentit comprometre els canvis que s'han fet a mig fer.
Per tant, és millor suspendre o desar temporalment el treball mig fet, treballar l’error i tornar a treballar amb la nova característica o millora. Git stash proporciona una solució a això. Podeu canviar fàcilment el context de fer canvis ràpidament.
Exemple 1 :Suposem que esteu treballant en una tasca que se us ha assignat i, quan mireu l'estat, es mostra que no es fa un seguiment a partir d'ara.
De sobte, se us ha assignat un error d'alta prioritat. Per tant, hem de desar o guardar temporalment el treball que s'està treballant actualment.
Executeu l'ordre següent.
git stash save 'Missatge'
En aquest moment, el directori de treball està net. Es poden fer compromisos nous i, si hi ha errors, podeu canviar de sucursal per treballar-hi, etc.
Quan vulgueu tornar a aplicar els canvis on us quedaven, utilitzeu l'ordre.
git stash pop
L'ordre anterior eliminarà la memòria cau de la llista i aplicarà l'últim estat desat.
També podeu utilitzar:
s'aplica git stash
L'ordre anterior mantindrà els canvis a la memòria cau i no els eliminarà.
Ara els canvis es tornen a aplicar i podeu modificar-los.
Exemple 2: Emmagatzemeu els canvis, canvieu de sucursal i combineu els canvis.
Feu el canvi al fitxer Html del fitxer mestre canvis de sucursals i guardamobles.
El següent és canviar a error ramificar, fer canvis i fer canvis.
git checkout -b error
Feu canvis al fitxer HTML.
git commit -a -m 'Problema de correu electrònic solucionat'
Torneu al fitxer mestre ramifiqui i torneu a aplicar els canvis des de guardar.
Ara fusioneu-vos des del fitxer error branca cap al mestre branca. Comproveu els canvis després de la combinació.
Exemple 3: Treballar amb Stash múltiple.
A la reposició local, hi ha 2 fitxers HTML. Per tant, és possible que diversos desenvolupadors treballin en diversos fitxers i eliminin els canvis necessaris per treballar en les sol·licituds urgents que s’acostin a solucionar els canvis.
El desenvolupador 1 funciona a hello.html i el desenvolupador 2 funciona a index.html.
Desenvolupador 1
La llista Stash té 1 entrada ara.
Desenvolupador 2
La llista Stash ara té 2 entrades. El darrer stash és el primer de la pila, que és stash @ {0}. Ara els dos desenvolupadors poden fer qualsevol altre compromís amb urgència o treballar en alguna altra branca i tornar al mestre branca i apliqueu els canvis d'emmagatzematge.
Per aplicar l'última memòria oculta, només podeu executar
git stash pop
Per aplicar una memòria específica a la pila, executeu l'ordre següent.
git stash pop stash @ {1}
Apliquem la segona memòria que és guardar @ {1}
De la mateixa manera, es pot aplicar l'altra reserva.
Git Cherry Pick
Avui en dia, els desenvolupadors treballen en diverses branques com ara funcions, millores, errors, etc.
Hi ha situacions en què només cal seleccionar un parell de compromisos específics i no fusionar tota la branca en una altra branca. Això s’anomena Cherry Pick. Aquest procés us permet escollir arbitràriament qualsevol compromís de Git de les altres branques i afegir-lo al capçal actual de l'arbre de treball.
Exemple 1:
Al dipòsit local de git, tenim els 6 fitxers següents.
S'ha suprimit un fitxer, per exemple, file5.txt.
Comprometeu els canvis.
Mireu el registre ara. S'ha suprimit File5.txt.
Per tant, volem Cherry-Pick el commit on hem afegit file5.txt. Hem de trobar l’identificador de commit de file5.tx i executar l’ordre.
git cherry-pick
En aquest cas, l’identificador de commit de quan es va afegir file5.txt és a2f0124
Ara File5.txt es restaura. Hem seleccionat el compromís.
Exemple 2:
Simplement modificem file6.txt i comprometre els canvis a mestre branca.
Mireu la segona línia de file6.txt on el correu electrònic no s’especifica correctament.
Creeu una branca d'errors i solucioneu el problema. Al mateix temps, també modifiqueu file5.txt de manera que tinguem diverses confirmacions realitzades a la branca d'errors, però Cherry-Pick només farà les commit realitzades a file6.txt.
Fitxer 6 modificat a error branca.
Per tant, en general hem fet canvis a fitxer5 i fitxer6 a la branca Bug.
Tornem ara a mestre branch i Cherry-Pick el commit realitzat només per a file6.txt.
Com podeu veure, en lloc de fusionar el fitxer error branca a la mestre branca, només hem fet un Cherry-Picked només per a una confirmació específica i aplicada a la branca mestra.
Restabliment de Git
Git reset és una poderosa ordre per desfer els canvis locals. Per tant, per desencadenar tots els fitxers en fase que s’utilitzen amb aquesta ordre.
Exemple
Modifiqueu un fitxer i afegiu-lo a la prova. Restableix mitjançant l'ordre tal com es mostra quan els canvis en etapes no estan en estat.
Paràmetres de restabliment de git comandament.
–Suau: Aquest paràmetre dirigirà el HEAD cap a una altra confirmació. Tots els fitxers es canvien entre el capçal original i la confirmació es posarà en escena. El directori de treball està intacte.
Mireu la ubicació actual de HEAD.
Tornem enrere 5 compromisos a la història.
Torneu a comprometre els canvis.
–Mesclada: L’opció és similar al paràmetre soft. Normalment, quan hi ha algunes confirmacions errònies, les elimineu i les solucioneu més tard i les torneu a fer. Per tant, bàsicament, hem d’afegir a l’índex mitjançant git add i llavors git commit. Es deixen canvis a l'arbre de treball.
Tornem enrere 2 confirmacions a l'historial i comprovem que no es fa un seguiment dels fitxers.
Ara afegiu els fitxers a la prova i confirmeu els canvis.
–Dur: Aquest paràmetre restarà fins a un punt on existís un fitxer concret. Els canvis no estaran disponibles a l'arbre de treball.
Si mirem el registre anterior, podem tornar al punt en què només es va comprometre el fitxer 1, és a dir, l’última entrada.
Utilitzant git reset –hard
Git Bisect
Cerqueu la confirmació exacta que va trencar el codi (Tots som humans després de tot). Sovint, durant la prova de l'aplicació, els nostres provadors escolten que hi ha un error o que la funció no funciona i que, com a desenvolupador, dirà que va funcionar la setmana passada. Llavors, què va passar i per què va aparèixer aquest error?
De vegades, un canvi en l’altre codi podria haver afectat la vostra funció. Heu de passar temps passant per la història, on hi ha molts compromisos que requereixen molt de temps i són difícils de rastrejar, quin canvi va fer que el codi es trenqués.
Git Bisect és l'ordre per trobar la confirmació exacta quan es va introduir l'error. Amb Git bisect, heu de triar dues confirmacions, una bona i una altra dolenta. Es comprovarà aproximadament a mig camí entre ambdues confirmacions. Comproveu que cada comissió sigui dolenta o bona fins que es trobi la confirmació que ha provocat la ruptura de l'error o del codi.
Exemple:
- Creeu un nou dipòsit local de git i creeu un fitxer anomenat index.html
- Contingut inicial del fitxer tal com es mostra.
- Afegiu-ho a la fase de prova i envieu-lo al repositori.
- Creeu un historial de confirmacions com es mostra, de manera que puguem triar entre les confirmacions bones i les negatives. Ara, a mesura que es fa la confirmació inicial, feu els altres canvis tal com es mostra i cometeu-la de la mateixa manera. En general, farem 7 compromisos.
Segon canvi
Tercer canvi
Quart canvi
Cinquè canvi
Sisè canvi
Setè canvi
Parem aquí. Per tant, tenim set compromisos.
Si mireu la pàgina HTML, les línies després de 'Tots els 4 esdeveniments ...' són incorrectes i, per tant, la documentació no és correcta. Per tant, hem de trobar el commit on s’ha introduït l’error per poder recolzar el HEAD en aquest commit.
Vegem el registre i esbrinem el dolent i bon compromís.
L’últim commit no és correcte, de manera que pot ser un commit negatiu. El commit s'ha introduït després del tercer commit, de manera que podem tenir el Tercer canvi com els bons es comprometen.
El procés de la divisió comença per git bisect start i acaba amb restabliment de bisect git.
git bisecta malament // Com que l'últim commit és dolent. No cal proporcionar l’identificador de confirmació.
git bisecta bé
Ara podeu veure que HEAD està ara entre la meitat del compromís dolent i bo.
Mireu el contingut d’index.html i comproveu si hi ha una bona confirmació. Si no, l'error encara no es troba.
No és realment que l’error encara existeixi. L’última línia és incorrecta. Per tant, correm ‘ git bisecta malament ’. Encara hi ha una mala publicació i el contingut actual no és acceptable.
El contingut anterior és correcte i acceptable.
Executeu 'git log –oneline' i 'git bisect good'.
Doncs el Cinquè canvi va ser el primer compromís dolent i realment així. S'ha identificat l'error.
El contingut actual hauria de figurar a la documentació final.
A mesura que s'identifica la confirmació errònia, podeu informar el desenvolupador que corregisca els canvis que podrien tenir per restablir el cap al quart canvi que va ser l'últim compromís correcte.
Correr ' restabliment de bisect git ’Per acabar el procés.
Conclusió
En aquest manual pràctic de GitHub, hem intentat cobrir tot el que hauria de treballar un desenvolupador, és a dir, des del punt de vista del control de versions i del seguiment.
En els tres primers tutorials de la sèrie GitHub hem conegut les activitats de control de versions, la creació de repositoris, la sol·licitud d’extracció, les sucursals, les ressenyes de codis, les organitzacions i els equips, la bifurcació d’un dipòsit, les etiquetes, les fites, els problemes, els taulers de projectes, els wikis, les versions, la integració amb Jira i algunes ordres Git d'ús habitual per a desenvolupadors.
Realment esperem que tots els desenvolupadors trobin útil aquest enfocament pràctic per a GitHub i les ordres de Git en els seus projectes.
=> Llegiu la sèrie de formació Easy GitHub.
Lectura recomanada
- GitLab Jira Integration Tutorial
- Ordres Unix: ordres bàsiques i avançades Unix amb exemples
- Integració de seleni amb GitHub mitjançant Eclipse
- Tutorial d’integració de JIRA i SVN
- Git contra GitHub: exploreu les diferències amb exemples
- Tutorial de Cogombre Selenium: Integració de Cogombre Java Selenium WebDriver
- Tutorial de GitHub per a desenvolupadors | Com s'utilitza GitHub
- Tutorial Unix Pipes: Pipes a la programació Unix