
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:
-
Abra o IntelliJ IDEA e selecione "Obter do controle de versão":
-
Copie e cole o endereço do projeto:
-
Você será solicitado a criar um projeto IntelliJ IDEA. Aceite a oferta:
-
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 :
-
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.



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 :

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 .
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:


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:



- 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.

- 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.

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:

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:

GO TO FULL VERSION