Tutorial Git para iniciantes

Desenvolvimento de software é um trabalho colaborativo. Como engenheiro de software, você precisa compartilhar seu trabalho com outras pessoas. Mas compartilhar código e colaboração pode ficar complicado. É difícil acompanhar várias mudanças que acontecem durante o ciclo de vida de um software. Portanto, as equipes de desenvolvimento dependem das ferramentas de controle de versão para ajudar no processo de colaboração de software. O Git é uma das ferramentas de controle de versão mais proeminentes da indústria de software.

Dica: Neste tutorial, você aprenderá a usar os fundamentos do Git. Cada seção termina com algumas perguntas. Você pode ler as perguntas antes de começar a ler a seção. Isso ajudará você a entender e prestar atenção aos pontos importantes.

Divirta -se aprendendo git!

Git: Uma breve visão geral

Git é um sistema de controle de versão distribuído. Ele mantém o controle de todas as alterações que você faz em seus arquivos e pastas. Torna mais fácil salvar seu trabalho em andamento. Se houver um problema, você pode verificar facilmente uma versão anterior do arquivo ou pasta. Se necessário, você pode até reverter toda a sua base de código para uma versão mais antiga.

O desenvolvimento do Git começou em 2005. O grupo Linux Kernel usado para manter seu código no Bitkeeper, um sistema de controle de versão distribuída proprietária. No entanto, o Bitkeeper retirou seu uso livre do produto. Assim, Linus Torvalds, criador e desenvolvedor principal do Linux, projetou um novo sistema de controle de versão distribuída de código aberto que atenderia aos requisitos da comunidade de desenvolvimento Linux. E Git nasceu.

Como um sistema de controle de versão distribuída, o Git não requer uma autoridade centralizada para acompanhar o código. Controles de versão centralizada mais antigos, como CVs, SVN ou Perforce, requerem servidores centrais para manter o histórico de mudanças. O Git pode acompanhar todas as alterações localmente e trabalhar ponto a ponto. Portanto, é mais versátil do que os sistemas centralizados.

Questões:

• Por que você deveria usar o git?
• Qual é o benefício do controle da versão distribuída?

Instalando o git

Para sistemas Linux, instalando o git é fácil. Se você estiver usando uma distribuição baseada no Debian como o Ubuntu, poderá usar o APT Instale:

$ sudo apt install git-all

Para Fedora, Rhel ou CentOS, você pode usar:

$ sudo dnf install git-all

Você pode verificar se o Git foi instalado, usando o seguinte comando:

$ git -versão

Ele deve mostrar a versão do Git que você instalou, por exemplo:

Git versão 2.17.0

Depois de instalar o Git, é hora de configurar seu nome de usuário e e -mail:

$ Git Config -Usuário global.Nome "Yourusername"
$ Git Config -Usuário global.Email "[email protected] "

Você pode verificar se as configurações foram definidas corretamente usando o seguinte comando:

$ git config -lista
do utilizador.Nome = YourUsername
do utilizador.email = [email protected]

Dica: É importante definir o usuário.nome e usuário.E -mail porque essas configurações são usadas para rastrear suas alterações.

Questões

• Qual é o comando para instalar o git no seu sistema Linux?
• Por que você deveria configurar o usuário.nome e usuário.Configuração de email? Como você os configura?

Entendendo o git conceitualmente

Para usar o Git, primeiro você precisa entender esses quatro conceitos:

• Diretório de trabalho
• Área de preparação
• Repositório
• Repositório remoto

O diretório de trabalho, a área de preparação e o repositório são locais para sua máquina. O repositório remoto pode ser qualquer outro computador ou servidor. Vamos pensar nesses conceitos como quatro caixas que podem manter papéis A1 padrão.

Suponha que você esteja escrevendo um documento manualmente em um papel A1 em sua mesa. Você mantém este documento na caixa de diretório de trabalho. Em um certo estágio do seu trabalho, você decide que está pronto para manter uma cópia do trabalho que já fez. Então você faz uma fotocópia do seu papel atual e o coloca na caixa de estadiamento.

A caixa de estadiamento é uma área temporária. Se você decidir descartar a fotocópia na caixa de estadiamento e atualizá -la com uma nova cópia do documento do diretório de trabalho, não haverá registro permanente desse documento encenado.

Suponha que você tenha certeza de que deseja manter o registro permanente do documento que você tem na caixa de estadiamento. Então você faz uma fotocópia do documento da caixa de estadiamento e move -o para a caixa de repositório.

Quando você o move para a caixa de repositório, duas coisas acontecem:

1. Um instantâneo do documento é salvo permanentemente.
2. Uma entrada de arquivo de log é feita para ir com o instantâneo.

A entrada do log ajudará você a encontrar esse instantâneo específico do seu documento, se precisar no futuro.

Agora, na caixa de repositório local, você tem um instantâneo do seu trabalho e uma entrada de log. Mas só está disponível para você. Então você faz uma cópia do seu documento de repositório local junto com o arquivo de log e o coloca em uma caixa na sala de suprimentos da empresa. Agora qualquer pessoa da sua empresa pode vir e fazer uma cópia do seu documento e levá -lo à mesa deles. A caixa na sala de suprimentos seria o repositório remoto.

O repositório remoto é como compartilhar seu documento usando o Google Docs ou Dropbox.

Questões:

• Você pode definir diretório de trabalho, estadiamento, repositório e repositório remoto?
• Você pode desenhar como os documentos se movem de um estágio para outro?

Seu primeiro repositório Git

Depois de instalar o Git, você pode começar a criar seus próprios repositórios Git. Nesta seção, você vai inicializar seu repositório Git.

Suponha que você esteja trabalhando em um projeto de desenvolvimento da web. Vamos criar uma pasta chamada Project_Helloworld e mudar para o diretório:

$ mkdir Project_helloworld
$ CD Project_helloworld

Você pode dizer ao Git para monitorar este diretório com o seguinte comando:

$ git init

Você deve ver uma saída como esta:

Repositório Git vazio inicializado em/usuários/zakh/_work/learngit/git_tutorial/
Project_helloworld/.git

Agora quaisquer arquivos e pastas dentro do Project_helloworld serão rastreados pelo Git.

Questões:

• Como você inicializa um diretório a ser rastreado por git?

Comandos básicos do Git: status, log, adicionar e comprometer

O comando de status mostra a condição atual do seu diretório de trabalho e o comando log mostra o histórico. Vamos tentar o comando de status:

$ git status
No mestre da filial
COMPRIMENTO INICIAL
Nada a comprometer (criar/copiar arquivos e usar "git add" para rastrear)

A saída do comando de status Git está dizendo que você está no ramo principal. Esta é a filial padrão que o Git inicializa. (Você pode criar seus próprios ramos. Mais sobre filiais depois). Além disso, a saída está dizendo que não há nada para se comprometer.

Vamos tentar o comando log:

$ git log
Fatal: o seu ramo atual 'mestre' ainda não tem nenhuma confirmação

Então, é hora de criar algum código. Vamos criar um arquivo chamado índice.html:

Olá Mundo

Você pode usar o editor de texto para criar o arquivo. Depois de salvar o arquivo, verifique o status novamente:

$ git status
No mestre da filial
COMPRIMENTO INICIAL
Arquivos não rastreados:
(Use "git add…" para incluir no que será comprometido)
índice.html
Nada adicionado para cometer, mas arquivos não rastreados presentes (use "git add" para rastrear)

Git está lhe dizendo que você tem um arquivo chamado índice.HTML em seu diretório de trabalho que está não rastreado.

Vamos garantir que o índice.HTML é rastreado. Você precisará usar o comando add:

$ git add Índice.html

Como alternativa, você pode usar o “.”Opção para adicionar tudo no diretório:

$ git add .

Agora vamos verificar o status novamente:

$ git status
No mestre da filial
COMPRIMENTO INICIAL
Mudanças a serem comprometidas:
(Use "Git RM -Cachado ..." para se soltar)
Novo arquivo: índice.html

O verde indica que o índice.O arquivo HTML está sendo rastreado pelo Git.

Dica: Conforme mencionado nas instruções acima, se você usar o comando:

$ Git RM -Índice Cachado.html

Seu índice.HTML voltará ao status não rastreado. Você terá que adicioná -lo novamente para trazê -lo de volta ao estadiamento.]

Vamos verificar o log novamente:

$ git log
Fatal: o seu ramo atual 'mestre' ainda não tem nenhuma confirmação

Portanto, mesmo que o Git seja Índice de Rastreamento.HTML, ainda não há nada no repositório Git sobre o arquivo. Vamos cometer nossas mudanças:

$ git Commit -m "Compromiting Index.html "
A saída deve parecer algo assim:
[Mestre (Compromisso Raiz) F136D22] Comprometter Index.html
1 arquivo alterado, 6 inserções (+)
criar modo 100644 Índice.html

O texto dentro das citações após o "-m" é um comentário que entrará no arquivo de log. Você pode usar o Git Commit sem "-m", mas o Git abrirá um editor de texto pedindo que você escreva os comentários. É mais fácil apenas colocar os comentários diretamente na linha de comando.

Agora vamos verificar nosso arquivo de log:

$ git log
COMIT F136D22040BA81686C9522F4FF94961A68751AF7
Autor: Zak H
Data: Seg 4 de junho 16:53:42 2018 -0700
Índice de Comprometimento.html

Você pode ver que está mostrando um commit. Você cometeu com sucesso suas alterações no seu repositório local. Se você quiser ver o mesmo log de maneira concisa, pode usar o seguinte comando:

$ git log --oneeline
F136D22 Compromitter Index.html

Avançando, usaremos esta forma do comando log porque facilita a compreensão do que está acontecendo.

Vamos começar a editar o índice.html. Abra o índice.Arquivo HTML em um editor e altere a linha "Hello World" para "Hello World! Sou eu!”E salve. Se você verificar o status novamente, verá que o GIT notou que está editando o arquivo:

$ git status
No mestre da filial
Mudanças não encenadas para comprometer:
(use "git add…" para atualizar o que será comprometido)
(Use "checkout git - ..." para descartar mudanças no diretório de trabalho)
modificado: índice.html
Nenhuma alteração adicionada ao comprometimento (use "git add" e/ou "commit git -a")

A mudança ainda está em seu diretório de trabalho. Você precisa empurrá -lo para a área de estadiamento. Use o comando add que você usou antes:

$ git add .

Verifique o status novamente:

$ git status
No mestre da filial
Mudanças a serem comprometidas:
(Use "Git Reset Head…" para se soltar)
modificado: índice.html

Agora suas mudanças estão na área de preparação. Você pode comprometê -lo com o repositório para salvar permanente:

$ git commit -m "ÍNDICE MODIFICADO.html para uma mensagem mais feliz "
[Mestre 0586662] Índice modificado.html para uma mensagem mais feliz
1 arquivo alterado, 1 inserção (+), 1 exclusão (-)

Você pode verificar o log para suas alterações permanentes:

$ git log --oneeline
0586662 ÍNDICE MODIFICADO.html para uma mensagem mais feliz
F136D22 Compromitter Index.html

Nesta seção, você aprendeu a usar o status, registrar, adicionar e confirmar comandos para acompanhar seus documentos no Git.

Questões:

• O que o status git faz?
• O que o Git Log faz?
• O que o git adiciona fazer?
• O que o Git Commit?

Voltando aos arquivos mais antigos usando checkout

Quando você compromete um arquivo no Git, ele cria um hash único para cada compromisso. Você pode usá -los como identificadores para retornar a uma versão mais antiga.

Suponhamos que você queira voltar à sua versão anterior do índice.html. Primeiro, vejamos o índice.HTML na condição atual:

$ CAT INDEX.html



Olá Mundo! Sou eu!

Você pode ver que tem a versão mais recente (“Olá mundo! Sou eu!”). Vamos verificar o log:

$ git log --oneeline
0586662 ÍNDICE MODIFICADO.html para uma mensagem mais feliz
F136D22 Compromitter Index.html

O hash para a versão anterior foi F136D22 ("Hello World"). Você pode usar o comando de checkout para chegar a essa versão:

$ git checkout f136d22
Nota: Verificando 'F136D22'.
Você está no estado de 'cabeça isolada'. Você pode olhar em volta, fazer mudanças experimentais
e cometê -los, e você pode descartar qualquer compromisso que fizer neste estado
sem impactar nenhum ramificador, realizando outro checkout.
Se você deseja criar uma nova filial para manter os compromissos que você cria, você pode
Faça isso (agora ou mais tarde) usando -b com o comando de checkout novamente. Exemplo:
checkout git -B
Head está agora em F136D22… Compromiting Index.html

Se você olhar para o conteúdo do índice.html, você verá:

$ CAT INDEX.html



Olá Mundo

Só tem "Hello World". Então seu índice.HTML mudou para a versão mais antiga. Se você verificar o status:

$ git status
Cabeça destacada em F136D22
nada para se comprometer, diretório de trabalho limpo

Git está basicamente dizendo que a cabeça não está no commit mais recente. Você pode voltar ao comprometimento mais recente, conferindo a filial mestre usando o seguinte comando:

$ git checkout mestre
A posição anterior da cabeça era F136D22… Compromissor.html
Mudou para a filial 'Mestre'

Agora, se você verificar o status:

$ git status
No mestre da filial
nada para se comprometer, diretório de trabalho limpo

O aviso vermelho se foi. Além disso, se você verificar seu índice.HTML, você deve estar de volta à versão mais recente:

$ CAT INDEX.html


Olá Mundo! Sou eu!

O comando de checkout leva você a vários estados. Vamos aprender mais sobre o checkout na próxima seção.

Questões:

• Como você usa o comando git checkout para ir para uma versão mais antiga de um arquivo?
• Como você usa o checkout git para voltar à versão mais recente do arquivo?

Checkout, ramificação e fusão

A ramificação é um dos melhores recursos do Git. Ajuda você a separar seu trabalho e experimentar mais. Em outros sistemas de controle de versão, a ramificação era demorada e difícil. Git facilitou a ramificação e a fusão.

Como você notou no comando de status, quando você cria um novo repositório Git, você está no ramo mestre.

$ git status
No mestre da filial
nada para se comprometer, diretório de trabalho limpo

Suponha que você esteja fazendo um site para seu amigo David. Você quer reutilizar o código do seu próprio site. Ramificação é uma ótima solução. Vamos chamar o ramo de David_website.

Você pode emitir o seguinte comando:

$ git ramo David_website

Você pode usar o seguinte comando para ver todos os ramos:

$ Git Branch -Lista
David_Website
* mestre

A estrela (*) ao lado do Mestre significa que você ainda está no ramo mestre. Você pode conferir o ramo David_Website com o seguinte comando:

checkout de $ git David_website
Mudou para o ramo 'David_website'

Agora, se você verificar novamente a lista de filiais, você vê:

$ Git Branch -Lista
* David_Website
mestre

Então você está no ramo David_Website.

Vamos mudar o índice.html de “Hello World! Sou eu!"Para" Hello World! É David!”E então encene e cometê -lo:

$ git add .
$ git Commit -m "Site alterado para David"

Se você verificar os logs, você deve ver:

$ git log --oneeline
345c0f4 alterou o site para David
0586662 ÍNDICE MODIFICADO.html para uma mensagem mais feliz
F136D22 Compromitter Index.html

E seu arquivo de índice deve ficar assim:

$ CAT INDEX.html



Olá Mundo! É David!

Agora vamos conferir o ramo mestre novamente:

$ git checkout mestre
Mudou para a filial 'Mestre'

Se você verificar o status e o log:

$ git status
No mestre da filial
nada para se comprometer, diretório de trabalho limpo
$ git log --oneeline
0586662 ÍNDICE MODIFICADO.html para uma mensagem mais feliz
F136D22 Compromitter Index.html

Observe que você não tem seu terceiro compromisso no mestre. Porque esse compromisso é mantido apenas no ramo David_Website.

Isso é o que aconteceu

Suponha que nesta fase você decide, você não deseja continuar seu site. Você será apenas o desenvolvedor de David. Então você deseja mesclar as mudanças na filial de David_website para o mestre. Na filial mestre, você só precisa emitir os seguintes comandos (o comando de status é usado para verificar se você está no lugar certo):

$ git status
No mestre da filial
nada para se comprometer, diretório de trabalho limpo
$ git mesclar David_website
Atualizando 0586662… 345C0F4
Avanço rápido
índice.html | 2 +-
1 arquivo alterado, 1 inserção (+), 1 exclusão (-)

Dica: Você está puxando mudanças de David_Website para Master. Você tem que estar no mestre para conseguir isso.

Agora, se você verificar o log no mestre, verá o terceiro compromisso está lá:

$ git log --oneeline
345c0f4 alterou o site para David
0586662 ÍNDICE MODIFICADO.html para uma mensagem mais feliz
F136D22 Compromitter Index.html

Você fundiu com sucesso o ramo David_Website em mestre. E seu índice.HTML for Master Branch parece idêntico a David_Website Branch:

$ CAT INDEX.html



Olá Mundo! É David!

Você pode manter o ramo David_Website:

$ Git Branch -Lista
David_Website
* mestre

Ou você pode excluí -lo:

$ git ramo -d David_website
Filial excluído David_Website (era 345c0f4).

Após a exclusão, você não deve mais ver o ramo David_Website:

$ Git Branch -Lista
* mestre

Dica: Durante uma mesclagem, se o git não puder se fundir automaticamente, isso lhe dará erros de conflito de mesclagem. Nesse caso, você deve resolver manualmente os problemas de mesclagem.

Questões:

• Por que você precisa de ramificação?
• Como você ramifica e mescla arquivos e pastas?

Repositório remoto

Até agora, todo o seu trabalho tem sido local. Você tem cometeu suas mudanças em um repositório local. Mas é hora de compartilhar seu trabalho com o mundo.

O repositório remoto do Git é basicamente outra cópia do seu repositório local que pode ser acessado por outros. Você pode configurar um servidor e torná -lo o repositório remoto. Mas a maioria das pessoas usa Github ou Bitbucket para esse fim. Você pode criar repositórios públicos gratuitamente lá, que podem ser acessados ​​por qualquer pessoa.

Vamos criar um repositório remoto no Github.

Primeiro, você precisa criar uma conta do GitHub []. Depois de ter a conta, crie um novo repositório usando o botão "novo repositório". Use "Project_Website" como o nome do repositório (você pode escolher outra coisa, se quiser).

Você deve ver uma guia de código com instruções como estas:

… Ou crie um novo repositório na linha de comando

eco "# project_website" >> leia.MD
git init
git add readme.MD
Git Commit -M "Primeiro Commits"
git remoto adicionar origem [email protected]: yourusername/project_website.git
Git Push -u Origin Master

Copie o seguinte comando "Git Remote Add Origin" e execute -o no seu diretório de trabalho:

$ git remoto adicionar origem [email protected]: yourusername/project_website.git

NOTA: No seu caso, seu nome de uso deve ser o que você usou para criar sua conta do github.

No comando acima, você instruiu a localização do repositório remoto. O comando está dizendo ao Git que a "origem" do seu diretório de trabalho do Project_Helloworld será "[email protected]: yourusername/project_website.git ”.

Agora empurre seu código de sua filial mestre para origem (repositório remoto):

$ Git Push Origin Master
Contando objetos: 9, feito.
Compressão delta usando até 4 threads.
Objetos de compactação: 100% (6/6), feito.
Objetos de escrita: 100% (9/9), 803 bytes | 0 bytes/s, feito.
Total 9 (Delta 2), reutilizado 0 (delta 0)
Remoto: resolvendo deltas: 100% (2/2), feito.
Para [email protected]: yourusername/project_website.git
* [New Branch] Mestre -> Mestre

Se você refrescar seu navegador no Github, deve ver que o índice.o arquivo html está lá em cima. Portanto, seu código é público e outros desenvolvedores podem verificar e modificar o código no repositório remoto.

Como desenvolvedor, você estará trabalhando com o código de outras pessoas. Então vale a pena tentar verificar o código do github.

Vamos para um novo diretório onde você não tem nada. No lado direito do repositório do GitHub, você notará o botão "Clone ou Download". Se você clicar nele, ele deve lhe dar um endereço SSH. Execute o seguinte comando com o endereço SSH:

$ git clone [email protected]: yourusername/project_website.git

A saída deve ficar assim:

$ git clone [email protected]: yourusername/project_website.git
Clonando em 'Project_website'…
Remoto: contando objetos: 9, feito.
Remoto: Compressioning Objetos: 100% (4/4), feito.
Remoto: Total 9 (Delta 2), reutilizado 9 (Delta 2), Reilvatou 0
Objetos recebidos: 100% (9/9), feito.
Resolução Deltas: 100% (2/2), feito.
Verificando a conectividade ... feita.

Ele criará um project_website em sua pasta limpa. Se você entrar, você deve ver o índice.HTML do seu Project_Helloworld.

Então você alcançou o seguinte:

• Criou e fez mudanças no Project_helloworld
• Carregou o código para o GitHub em Project_Website
• Baixou o código do github

Vamos outro arquivo do novo diretório de trabalho Project_Website:

$ touch readme.MD
$ git add .
$ git Commit -m "Adicionado readme.md "
$ Git Push Origin Master

Se você atualizar a página do GitHub Project_Website, você verá o ReadMe.arquivo md lá.

Nota: Quando você baixará o código do GitHub, o diretório de trabalho sabe automaticamente a origem. Você não precisa defini -lo com o comando "git remoto add orig Origin".

Questões:

• Por que você precisa usar repositórios remotos?
• Como você configura seu repositório local atual para se conectar ao repositório remoto?
• Como você clona repositórios remotos para o seu computador local?

Conclusão

Você pode encontrar mais informações sobre todos os comandos nos documentos git []. Embora existam ferramentas de interface do usuário disponíveis, a linha de comando é a melhor maneira de dominar o git. Isso lhe dará uma base mais forte para o seu trabalho de desenvolvimento.

Um estudo mais aprofundado:

• https: // git-scm.com/docs
• https: // git-scm.com/livro/en/v2
• https: // git-scm.com/vídeos