Escribindo as súas propias historias con git

Ola a todos 🙂 Antes de continuar cos textos da lista de pedidos, quero celebrar o lanzamento de git 2.16 agradecendo a cada un dos que enviaron un parche e a cada un dos usuarios, en total tivemos como 4000 liñas entre actualizacións e correccións , que non fala moi ben da miña primeira versión, pero si da túa amabilidade 🙂 Grazas! Agora, vouvos contar un pequeno segredo, ata agora non houbo un tempo no que non me sentei a escribir un artigo e pensei moito nel, normalmente só escribo seguido e entón o bo lagarto ten a amabilidade de corrixe os meus erros de escritura 🙂 así que grazas a el tamén.

Isto non é o mellor cando falamos de escribir artigos, supostamente debería ter un obxectivo e construír unha estrutura, e marcar pequenos puntos e críticas, etc etc ... Agora, isto non só se aplica aos blogs en xeral, senón que é esencial nun software que pretende ser bo 🙂 Para esta tarefa e despois dalgúns problemas co software de control de versións que se usou no desenvolvemento do kernel hai uns anos, naceu git 🙂

Onde aprender git?

A cantidade de documentación en torno a git é asombrosa, aínda que tomásemos as páxinas de man que viñeron coa instalación, teríamos unha cantidade inmensa de lectura. Persoalmente atopo o libro git moi ben deseñado, aínda que teña traducido algúns dos segmentos da sección 7, aínda teño algúns, pero dame tempo 😛 quizais neste mes poida traducir o que queda desa sección.

Que fai git?

Git está deseñado para ser rápido, eficiente, sinxelo e para soportar gran cantidade de información, ao cabo, a comunidade do núcleo creouna para o seu software, que é un dos traballos conxuntos de software libre máis grandes do mundo e ten centos de contribucións por hora nunha base de código que supera o millón de liñas.

O interesante de git é a súa forma de manter versións de datos. Antigamente (outros programas de control de versións) tomaban compresas de todos os ficheiros existentes nun momento da historia, como facer un backup. Git adopta un enfoque diferente cando realiza un commit un punto da historia está marcado, ese punto da historia ten unha serie de modificacións e obras, ao final do día, xúntanse todas as modificacións co paso do tempo e os ficheiros obtéñense para poder comprimir ou marcar como fitos de versións. Como sei que todo isto soa complicado, vouche levar a unha viaxe máxica cun exemplo súper básico.

Pequeno proxecto de calculamática

A calculamática será un programa que atopará os cadrados dun número determinado, farémolo en C e será o máis sinxelo posible, así que non esperes moitos controis de seguridade de min. Primeiro imos crear un repositorio, vou facelo con Github para matar dous paxaros cunha soa pedra:

Propio. Christopher Díaz Riveros

Engadimos un par de cousas bastante sinxelas como a licenza (moi importante se queres protexer o teu traballo, no meu caso, obrigalos a compartir os resultados se queren usalo como base: P)

Agora imos ao noso querido terminal, git clone é o comando que se encarga de descargar o repositorio situado no url asignado e crea unha copia local no noso ordenador.

Propio. Christopher Díaz Riveros

Agora imos comprobar con git log o que pasou na historia do noso proxecto:

Aquí temos moita información en diferentes cores try intentemos explicalo:

a primeira liña amarela é o "código de barras de confirmación". Cada confirmación ten o seu propio identificador único co que podes facer moitas cousas, pero gardarémolo para máis adiante. Agora temos HEAD de celeste e master verde. Estes son "punteiros" a súa función é sinalar a situación actual da nosa historia (HEAD) e a rama na que estamos a traballar no noso ordenador (master).

origin/master é a contraparte de internet, origin é o nome predeterminado que foi asignado ao noso URLE master é a rama na que está a traballar ... para simplificalo, os que teñen un / son os que non están no noso equipo, pero son referencias ao que hai en internet.

Despois temos o autor, a data e a hora e o resumo da confirmación. Esta é unha pequena revisión do que pasou nese momento da historia, moi importante en moitos proxectos e hai moita información condenada. Vexamos de preto o que pasou no commit co comando git show <código-de-commit>

 

Propio. Christopher Díaz Riveros

O comando git show lévanos a esta pantalla en formato parche, onde podes ver o que se engadiu e o que se eliminou (se se eliminou algo) nese momento da historia, ata agora só nos mostra que o rexistros .gitignore,README.mdLICENSE.

Imos agora ao traballo, escribamos un ficheiro create crearemos o primeiro fito da nosa historia 😀:

Propio. Christopher Díaz Riveros

En breve, imos crear un programa que nos amose o número de argumentos pasados ​​ao executalo, sinxelo 🙂

Propio. Christopher Díaz Riveros

Foi fácil 🙂 agora vexamos o seguinte comando útil: git status

Propio. Christopher Díaz Riveros

Algunha alma de corazón amable traduciu o git para facelo máis doado de seguir. Aquí temos moita información útil, sabemos que estamos na rama principal, que estamos actualizados con origin/master(a rama Github), temos ficheiros sen rastrexar. e que para engadilos temos que empregalo git add, probemos try

Propio. Christopher Díaz Riveros

Agora temos un novo espazo verde no que se mostra o ficheiro que engadimos á área de traballo. Neste lugar podemos agrupar os nosos cambios para facer un commit, o commit consiste nun fito ao longo da historia do noso proxecto, imos crear o commit 🙂 git commit

Propio. Christopher Díaz Riveros

Breve explicado, a liña amarela é o título do noso commit, escribo main.c para unha mera referencia visual. O texto en negro é a explicación dos cambios realizados desde o commit anterior ata agora 🙂 gardamos o ficheiro e veremos o noso commit gardado no rexistro.

Propio. Christopher Díaz Riveros

Agora imos ver a historia do noso proxecto con git log

Propio. Christopher Díaz Riveros

De novo no rexistro, agora podemos ver que as liñas verdes e vermellas diferenciaron, iso é porque no noso ordenador somos un commit por encima dos almacenados en internet 🙂 imos continuar o traballo, supoño que agora quero amosar un mensaxe no caso de que o usuario poña máis dun argumento no programa (o que faría confundir a calculadora 🙂)

Como podemos ver, o noso programa medrou moito 😀, agora temos a función imprimir_ayuda() que mostra unha mensaxe sobre como usar os cálculos e no bloque main() agora facemos unha revisión con if(Algo que veremos nun tutorial de programación noutro momento, polo de agora só é necesario saber que se se introducen máis de 2 argumentos na calculamática, o programa remata e se mostra a axuda. Executámolo:

Propio. Christopher Díaz Riveros

Como podes ver agora imprime o número entregado no canto do número de argumentos, pero que non che dixera antes 🙂 para os curiosos echo $? amosa o código de saída do último programa executado, que é 1 porque acabou nun erro. Agora repasemos como vai a nosa historia:

Propio. Christopher Díaz Riveros

Agora sabemos que estamos 1 commit por diante de Github, que o ficheiro main.c modificouse, imos crear o seguinte commit facendo git add main.c  e despois git commit🙂

Propio. Christopher Díaz Riveros

Agora fomos un pouco máis específicos, xa que implementamos unha función e cambiamos o código de validación. Agora que se gardou, imos revisar o noso último cambio. Podemos velo con git show HEAD

Propio. Christopher Díaz Riveros

Agora podes ver as liñas vermellas e verdes, engadimos a biblioteca stdlib.h, modificou gran parte do código e engadiu a función á nosa historia.

Agora imos ver o rexistro: (git log)

Propio. Christopher Díaz Riveros

Podemos ver que estamos dous commit por diante da versión de Github, imos igualar un pouco o marcador 🙂 para iso usamos git push origin master

Con isto dicimos, envíe os meus compromisos á url origin na póla master

Propio. Christopher Díaz Riveros

Parabéns! Agora os teus cambios están en Github, ¿non me cres? repasámolo 😉

Propio. Christopher Díaz Riveros

Agora temos os 3 commit en Github 🙂

Resumo

Tocamos os aspectos máis básicos de git, agora poden crear un fluxo de traballo sinxelo nos seus proxectos, isto case non é nada da gran variedade de cousas que se poden facer con git, pero sen dúbida é o máis práctico e cotián para un desenvolvedor ou blogueiro. Non chegamos ao final da calculadora, pero ímolo deixar por outra vez 😉 Moitas grazas por chegar aquí e espero que che axude a participar en varios proxectos 😀 Saúdos

 


O contido do artigo adhírese aos nosos principios de ética editorial. Para informar dun erro faga clic en aquí.

7 comentarios, deixa os teus

Deixa o teu comentario

Enderezo de correo electrónico non será publicado. Os campos obrigatorios están marcados con *

*

*

  1. Responsable dos datos: Miguel Ángel Gatón
  2. Finalidade dos datos: controlar SPAM, xestión de comentarios.
  3. Lexitimación: o seu consentimento
  4. Comunicación dos datos: os datos non serán comunicados a terceiros salvo obrigación legal.
  5. Almacenamento de datos: base de datos aloxada por Occentus Networks (UE)
  6. Dereitos: en calquera momento pode limitar, recuperar e eliminar a súa información.

  1.   Pablo dixo

    Ben ... non sei se ti, pero non podo ver as imaxes desta reportaxe ...

    lembranzas

  2.   Pablo dixo

    Foi un problema co meu navegador. Desculpe as molestias.

  3.   Tecprog Mundial dixo

    Aínda teño que lelo con máis detalle, son un novato.

  4.   Guillermo dixo

    Estupendo artigo para comezar con git, aínda que recomendo tomar notas para comprender o detalle.
    Un par de cousas non me quedaron claras:
    para que serve a opción Engadir .gitignore Caínda que supoño que o verei cando o practique,
    por que tes que refacer o git add main.c antes do seguinte commit de git, o main.c di a git que compare ese ficheiro coa versión de rede? Non compara automaticamente todos os ficheiros engadidos para o seu seguimento?

    1.    ChrisADR dixo

      Ola Guillermo: é bo que che resulte útil para responder ás túas preguntas:

      .gitignore é un ficheiro que indica a git que formatos ou patróns hai que ignorar, neste caso seleccionando C fai que se ignoren os ficheiros .o e outros que se xeran no momento da compilación, o que é bo porque se non, o teu git volvería tolo ao instante de cada compilación e seguimento 🙂 pode comprobar o gran número de formatos que git omite no seu modelo C facendo cat ou cun editor de texto.

      Aínda que git fará un seguimento de cada ficheiro engadido á árbore de traballo, é necesario seleccionar específicamente que ficheiros ingresarán ao seguinte commit, para darlle un exemplo, supoñamos que o seu traballo levou a modificar 5 ficheiros diferentes poder ver o resultado. Se queres ser un pouco máis específico e explicar o que se fai en cada un, podes facer git add file1; git commit; git add file2; git commit ... .3,4,5; git commit. Deste xeito a túa historia queda limpa e os cambios están ben definidos. E no caso de que teñas que cambiar algo ou revertir (temas máis avanzados) podes reverter cousas específicas ou engadir cousas específicas sen cambiar o resto.

      Espero que axude ings saúdos e grazas por preguntar

    2.    ChrisADR dixo

      PS: git add non di comparar coa versión na rede, pero co commit anterior na súa liña de traballo, se foi local (verde) compararao con aquel, se foi remoto (vermello) comparar con ese outro. Só para aclarar 😉

      1.    Guillermo dixo

        Perfecto, por suposto, aclara.