O artigo de hoje é a extensão lógica do meu artigo sobre Git . No artigo sobre Git, descrevi como trabalhar com Git na linha de comando. Hoje vou mostrar como fazer tudo isso no IntelliJ IDEA. No início da minha jornada como desenvolvedor, usei a linha de comando e pensei que não precisava de uma GUI para isso. Afinal, tudo estava claro como estava... Mas isso foi até o momento em que comecei a usar o Git no IntelliJ IDEA... Desde já, quero dizer que estou descrevendo minha experiência pessoal. Existem várias maneiras de resolver qualquer problema no IntelliJ IDEA. Se você conhece uma maneira melhor do que a descrita no artigo, escreva-a nos comentários e nós a discutiremos.
Entradas necessárias:
- Leia, acompanhe e entenda meu artigo sobre Git . Isso ajudará a garantir que tudo esteja configurado e pronto para uso.
- Instale o IntelliJ IDEA.
- Aloque uma hora de tempo pessoal para atingir o domínio completo.
Clone o projeto localmente
Existem duas opções aqui:- Se você já possui uma conta do GitHub e deseja enviar algo posteriormente, é melhor fazer um fork do projeto e clonar sua própria cópia.
- Clone meu repositório e faça tudo localmente sem a capacidade de enviar tudo para o servidor. Afinal, este é o meu repositório :)
-
Copie o endereço do projeto:
![Uma combinação perfeita: Git e IntelliJ IDEA - 2]()
-
Abra o IntelliJ IDEA e selecione "Obter do controle de versão":
![Uma combinação perfeita: Git e IntelliJ IDEA - 3]()
-
Copie e cole o endereço do projeto:
![Uma combinação perfeita: Git e IntelliJ IDEA - 4]()
-
Você será solicitado a criar um projeto IntelliJ IDEA. Aceite a oferta:
![Uma combinação perfeita: Git e IntelliJ IDEA - 5]()
-
Como não há sistema de compilação e isso está além do escopo deste artigo, selecionamos Criar projeto a partir de fontes existentes :
![Uma combinação perfeita: Git e IntelliJ IDEA - 6]()
-
Em seguida, você verá esta bela tela:
Agora que descobrimos a clonagem, você pode dar uma olhada.
Primeira olhada no IntelliJ IDEA como uma interface do Git
Dê uma olhada no projeto clonado: você já pode obter muitas informações sobre o sistema de controle de versão. Primeiro, temos o painel Controle de versão no canto inferior esquerdo. Aqui você pode encontrar todas as alterações locais e obter uma lista de commits (análogo a "git log"). Vamos passar para uma discussão sobre Log . Existe uma certa visualização que nos ajuda a entender exatamente como o desenvolvimento ocorreu. Por exemplo, você pode ver que uma nova ramificação foi criada com um cabeçalho adicionado ao txt commit, que foi mesclado na ramificação principal. Se você clicar em um commit, poderá ver no canto direito todas as informações sobre o commit: todas as suas alterações e metadados.
Além disso, você pode ver as mudanças reais. Vemos também que ali foi resolvido um conflito. IDEA também apresenta isso muito bem. Se você clicar duas vezes no arquivo que foi alterado durante este commit, veremos como o conflito foi resolvido: Observamos
que à esquerda e à direita temos as duas versões do mesmo arquivo que precisava ser mesclado em um. E no meio, temos o resultado final da mesclagem. Quando um projeto tem muitos branches, commits e usuários, você precisa pesquisar separadamente por branch, usuário e data:
A última coisa que quero explicar antes de começarmos é como entender em qual branch estamos. um minuto para descobrir... Você encontrou? Desistir? :D No canto inferior direito, há um botão chamado Git: master. O que vem depois de "Git:" é o branch atual. Se você clicar no botão, poderá fazer muitas coisas úteis: alternar para outra ramificação, criar uma nova, renomear uma existente e assim por diante.
Trabalhando com um repositório
Teclas de atalho úteis
Para trabalhos futuros, você precisa se lembrar de algumas teclas de atalho muito úteis:- CTRL+T — Obtenha as alterações mais recentes do repositório remoto (git pull).
- CTRL+K — Criar um commit/ver todas as alterações atuais. Isso inclui arquivos não rastreados e modificados (veja meu artigo sobre git, que explica isso) (git commit).
- CTRL+SHIFT+K — Este é o comando para enviar alterações para o repositório remoto. Todos os commits criados localmente e ainda não no repositório remoto serão enviados (git push).
- ALT+CTRL+Z — Reverte alterações em um arquivo específico para o estado do último commit criado no repositório local. Se você selecionar todo o projeto no canto superior esquerdo, poderá reverter as alterações em todos os arquivos.
O que queremos?
Para fazer o trabalho, precisamos dominar um cenário básico que é usado em todos os lugares. O objetivo é implementar uma nova funcionalidade em uma ramificação separada e, em seguida, enviá-la para um repositório remoto (você também precisa criar uma solicitação pull para a ramificação principal, mas isso está além do escopo deste artigo). O que é necessário para fazer isso?-
Obtenha todas as alterações atuais na ramificação principal (por exemplo, "mestre").
-
A partir desta ramificação principal, crie uma ramificação separada para o seu trabalho.
-
Implemente a nova funcionalidade.
-
Vá para a ramificação principal e verifique se houve novas alterações enquanto estávamos trabalhando. Se não, então está tudo bem. Mas se houve alterações, fazemos o seguinte: vamos para o ramo de trabalho e rebase as alterações do ramo principal para o nosso. Se tudo der certo, ótimo. Mas é perfeitamente possível que haja conflitos. Acontece que eles podem ser resolvidos antecipadamente, sem perder tempo no repositório remoto.
Você está se perguntando por que deveria fazer isso? É uma boa educação e evita que ocorram conflitos depois de enviar sua ramificação para o repositório local (há, é claro, a possibilidade de que ainda ocorram conflitos, mas eles se tornam muito menores ).
- Envie suas alterações para o repositório remoto.
Obter alterações do servidor remoto?
Adicionei uma descrição ao README com um novo commit e quero obter essas alterações. Se as alterações foram feitas tanto no repositório local quanto no remoto, somos convidados a escolher entre uma mesclagem e um rebase. Nós escolhemos nos fundir. Digite CTRL+T :
Agora você pode ver como o README foi alterado, ou seja, as alterações do repositório remoto foram obtidas e, no canto inferior direito, você pode ver todos os detalhes das alterações que vieram do servidor.
Crie uma nova ramificação com base no mestre
Tudo é simples aqui.-
Vá para o canto inferior direito e clique em Git: master . Selecione + Nova filial .
![Uma combinação perfeita: Git e IntelliJ IDEA - 15]()
Deixe a caixa de seleção Filial do caixa marcada e digite o nome da nova filial. Para mim, será readme-improver .
Git: master mudará para Git: readme-improver .
Vamos simular um trabalho paralelo
Para os conflitos aparecerem, alguém tem que criá-los :D Vou editar o README com um novo commit pelo navegador, simulando assim o trabalho paralelo. É como se alguém tivesse feito alterações no mesmo arquivo enquanto eu trabalhava nele. O resultado será um conflito. Vou remover a palavra "fully" da linha 10.Implemente nossa funcionalidade
Nossa tarefa é alterar o README e adicionar uma descrição ao novo artigo. Ou seja, o trabalho no Git passa pelo IntelliJ IDEA. Adicione isto:
As mudanças estão feitas. Agora podemos criar um commit. Pressione CTRL+K , o que nos dá:
Antes de criar um commit, precisamos dar uma olhada no que esta janela oferece. Adicionei setas vermelhas para mostrar onde procurar. Tem muita coisa interessante aqui. Na seção Mensagem de confirmação , escrevemos o texto associado à confirmação. Então, para criá-lo, precisamos clicar em Commit. Ainda não descobri como fazer isso com uma tecla de atalho. Se alguém descobrir como, por favor, escreva-me - isso me deixaria muito feliz. Escrevemos que o README mudou e criamos o commit. Um alerta aparece no canto inferior esquerdo com o nome do commit:
Verifique se o ramo principal mudou
Concluímos nossa tarefa. Funciona. Nós escrevemos testes. Tudo está bem. Mas antes de enviar para o servidor, ainda precisamos verificar se houve alguma alteração no ramo principal nesse meio tempo. Como isso pode acontecer? Muito facilmente: alguém recebe uma tarefa depois de você e esse alguém a termina mais rápido do que você termina sua tarefa. Então, precisamos ir para o branch master. Para fazer isso, precisamos fazer o que é mostrado no canto inferior direito na captura de tela abaixo:
Na ramificação master, pressione CTRL+T para obter as últimas alterações do servidor remoto. Olhando para o que mudou, você pode ver facilmente o que aconteceu:
A palavra "fully" foi removida. Talvez alguém do marketing tenha decidido que não deveria ser escrito assim e deu aos desenvolvedores a tarefa de atualizá-lo. Agora temos uma cópia local da última versão do branch master. Volte para readme-improver . Agora precisamos rebasear as alterações do branch master para o nosso. Fazemos assim:
Se você fez tudo certo e me acompanhou, o resultado deve mostrar um conflito no arquivo README:
Aqui também temos muitas informações para entender e absorver. Aqui é mostrada uma lista de arquivos (no nosso caso, um arquivo) que possuem conflitos. Podemos escolher entre três opções:
- aceite o seu — aceite apenas as alterações do readme-improver.
- aceite as deles — aceite apenas alterações do mestre.
- mesclar — escolha você mesmo o que deseja manter e o que descartar.
Aqui podemos ver que existem três partes:
- Estas são as alterações do readme-improver.
- O resultado mesclado. Por enquanto, é o que existia antes das mudanças.
- As alterações da ramificação mestre.
Pronto! Resolvemos nosso primeiro conflito através do IntelliJ IDEA :D
Enviar alterações para o servidor remoto
A próxima etapa é enviar as alterações para o servidor remoto e criar uma solicitação pull. Para fazer isso, basta pressionar CTRL+SHIFT+K . Então obtemos:
À esquerda, haverá uma lista de commits que não foram enviados para o repositório remoto. À direita estarão todos os arquivos que foram alterados. E é isso! Pressione Push e você sentirá felicidade :) Se o push for bem-sucedido, você verá uma notificação como esta no canto inferior direito:
Parte bônus
A princípio, eu não queria adicionar a criação de uma solicitação pull a este artigo, mas não está completo sem ela. Então, vamos a um repositório GitHub (um que seja seu, claro :)) e vemos que o GitHub já sabe o que queremos:
Clique em Compare & pull request . Em seguida, clique em Criar solicitação pull . Como resolvemos os conflitos com antecedência, agora ao criar um pull request, podemos imediatamente fazer um merge dele:
E isso é tudo que eu queria dizer dessa vez. Claro, só abri um pouco a porta para você e mostrei uma pequena parte. Você aprenderá sobre o resto conforme necessário. Costumo convidar você a me seguir no GitHub, onde posto meus projetos envolvendo diversas tecnologias que utilizo no trabalho. Recentemente, fiz uma conquista pessoal: um dos meus projetos foi premiado com estrelas por mais de cem desenvolvedores. Há uma sensação incrível de alegria quando você sabe que o que fez está sendo usado por outra pessoa. E usando para o bem.





Agora que descobrimos a clonagem, você pode dar uma olhada.
GO TO FULL VERSION