o objetivo deste repositório é somente aprender como o github trabalha.
Este guia supõe que você tem algum conhecimento básico sobre o GIT:
-
Conhece os seguintes conceitos:
- O que é um branch
- Uso básico do checkout
- Uso básico do commit
- Uso básico do pull
- Uso básico do push
- Uso básico do log
- Uso básico do editor de textos vi
-
Tem instalado o GIT em seu computador.
- Antes de qualquer coisa, é preciso fazer um fork do projeto na sua conta do github para trabalhar. Isso pode ser feito no canto superior direito da sua tela (em baixo da foto do seu perfil).
- Depois de ter feito o fork, você terá uma cópia do projeto na sua conta do github. Da sua conta do github clone o projeto no seu HD local:
git clone https://github.com/sua_conta_do_github/nome_do_repositorio.git
Ao longo do processo de desenvolvimento, após a primeira clonagem, é provavel que você não precise repetiro que foi feito acima. Em vez disso, sempre que for fazer qualquer alteração (passos abaixo), antes você deve trazer, para o seu HD (repositório local) as últimas modificações feitas no repositório original:
git pull https://github.com/conta_original_do_projeto_no_github/nome_do_repositorio.git master:master
Como essa é uma operação que costuma ser feita com certa frequência, você pode configurar um remote para reduzir o comando acima. Por padrão, ao clonar o projeto no seu HD (git clone...) você já criou um remote chamado origin, "ligando" o ramo master remoto da SUA CONTA do github . Assim, toda vez que você estiver no ramo master e fizer um git pull, você irá sincronizar o seu master com o master remoto (da SUA CONTA). O que vamos fazer agora é criar um remote de ligação com o ramo master da conta original. Vamos chamar nosso novo remote de upstream:
git remote add upstream https://github.com/conta_original_do_projeto_no_github/nome_do_repositorio.git
Agora, quando quiser sincronizar o seu ramo master com o ramo remoto ORIGINAL, basta:
git pull upstream master:master ou, se já estiver no seu ramo master local: git pull upstream master
Se desejar sincronizar o repositório remoto do github (clonado na sua conta) com o repositório remoto original, após o comando acima, você deve fazer:
git push -f
Não tenha receio de criar branches em sua cópia local do repositório. O trabalho com o GIT pressupõe que você irá criar, localmente, branches para tudo o que desejar. É comum, em uma fábrica de software, que um desenvolvedor crie vários branches locais em um único dia.
Para criar um branch e poder trabalhar, é simples:
git checkout -b nome_do_meu_novo_branch
Trabalhe à vontade no seu novo branch, fazendo quantos commits você precisar.
Uma vez que a sua funcionalidade esteja pronta, após você ter feito vários commits locais, você deve arrumar o seu trabalho antes de enviá-lo para a sua conta do github.
No seu processo de trabalho você terá feito muitos commits no ramo local criado para implementar uma funcionalidade ou corrigir um bug qualquer. Esse processo gera um histórico de alterações que não precisa (apesar de poder) ficar disponível para consultas. Muitos commits são extremamente desnecessários, como nesse exemplo:
- Você faz um commit e percebe, logo depois que o programa não está compilando porque "Faltou um ponto-e-vírgula"
- Então você faz outro commit com a adição do ponto-e-vírgula e a seguinte mensagem: "Adição de ponto-e-vírgula"
Esse commit é interessante no seu repositório local durante o seu trabalho. Depois de finalizado, é algo completamente dispensável saber que existe um commit no histórico que guarda o código com a adição do ponto-e-vírgula e que, antes dele, o commit anterior não tem o referido ponto-e-vírgula.
Para resolver isso, temos a regra do squash
O squash é uma operação do git que permite a você colabar os N últimos commits em um único commit, resumindo assim a história detalhada dos vários commits intermediários que foram feitos durante o seu trabalho.
Exemplo: Suponha que em determinado momento seu histórico esteja assim:
e3c060b adicionei outro ponto-e-vírgula
5ca981c adicionei o ponto-e-vírgula
1453368 alteração importante
Note que a intenção acima era fazer um único commit com a mensagem "alteração importante" (commit 1453368). Por um acidente você foi obrigado a fazer mais 2 commits com alterações mínimas (commits 5ca981c e e3c060b). Então, estando no seu ramo de trabalho, você deseja que as alterações feitas nos commits extras estejam no commit "alteração importante": os 3 últimos commits precisam ser colabados. O comando que você deseja é:
git rebase -i HEAD~3
Ao executar esse comando, você entrará em um modo interativo de ajustes. A primeira coisa que o GIT irá exigir é que você escolha o que deseja fazer (quais commits devem ser preservados - pick - e quais devem ser colabados - squash).
Isso (resultado do comando git rebase -i HEAD~3):
pick 1453368 alteração importante
pick 5ca981c adicionei o ponto-e-vírgula
pick e3c060b outro ponto-e-vírgula
deve ficar assim:
pick 1453368 alteração importante
squash 5ca981c adicionei o ponto-e-vírgula
squash e3c060b outro ponto-e-vírgula
Após fazer as alterações conforme as instruções, salvar e sair, o GIT continuará o processo de squash, te dando uma oportunidade de editar uma mensagem de commit:
alteração importante
# This is the commit message #2:
adicionei o ponto-e-vírgula
# This is the commit message #3:
outro ponto-e-vírgula
Se quiser alterar, faça-o. Senão, salve e saia do vi para que o GIT finalize o processo. Após isso, o comando git log irá mostrar o seu histórico assim:
862c326 alteração importante
Neste ponto você já:
- Criou um ramo
- Trabalho no seu ramo, fazendo várias alterações e vários commits
- Finalizou o trabalho fazendo o squash dos commits, se necessário
E agora precisa enviar o resultado para o github:
git push -u origin nome_do_meu_novo_branch
Esse comando cria uma cópia do seu ramos local (chamado "nome_do_meu_novo_branch") na sua conta do github, em um branch de igual nome (ou seja, não altera o branch master no seu repositório remoto).
O próximo e último passo agora é fazer um pull request (PR) para o projeto original, com a intenção de fundir suas alterações ao ramo master (ou outro definido pela equipe) do projeto original.
