lfreneda/git_guide_what_should_I_do

## git_guide_what_should_I_do
1. Criando um repositório remoto

O Git possui várias formas de se comunicar, protocolos, com os repositórios. Estamos usando o chamado [wiki:git_protocolo_local Protocolo Local].
Para criar um repositório remoto precisamos seguir os seguintes passos:

A. Abra o Bash do Git
B. Navegue até o local de criação

cd /x
cd dotnet

//Onde X é a letra correspondente ao mapeamento da pasta compartilhada com o servidor (meu X:)//
C. Crie uma pasta (padrão .git)
mkdir levelupgames.myproject.git
D. Inicialize um repositório bare

cd levelupgames.myproject.git
git --bare init

Por quê "bare" ?
Um //bare repository// contém informações de controle e não contém //working files//. Ele não contem o sub-diretório .git, ao invés disso contém o conteúdo (do sub-diretório .git) diretamente em sua raiz. Um repositório precisa necessariamente ser do tipo //bare// para aceitar //push//.

Clonando um repositório
Para criar um repositório local precisamos seguir os seguintes passos:

A. Abra o Bash do Git
B. Navegue até o local de seus projetos

cd /c
cd git/rep

C. Clonar

git clone file://x:/dotnet/levelupgames.myproject.git
OU
git clone /x/dotnet/levelupgames.myproject.git

//Onde X é a letra correspondente ao mapeamento da pasta compartilhada com o servidor (meu X:)//

~

2. Criar um novo repositório
Para criar um novo repositório basta ir até o servidor central, criar uma pasta e inicializar um repositório bare (sem arvore de trabalho).
Voltar para sua pasta de repositórios local e clonar esse repositório.

cd /<letra-mapeada>:/dotnet/ #acessa o servidor remoto, troque <letra-mapeada> pela sua letra (a minha é a f:)
mkdir levelupgames.nome_do_projeto.git
cd levelupgames.nome_do_projeto.git/
git init --bare
cd /c/git/rep/ #volta para sua pasta de repositórios local
git clone file://f:/dotnet/levelupgames.nome_do_projeto.git/


~

3. Começar uma feature
Para começar uma nova funcionalidade basta criar uma nova branch com o nome da sua funcionalidade a partir da branch master.
É importante atualizar sua master para garantir que você esteja criando sua branch a partir da ultima versão.

git checkout master
git pull --rebase origin master
git checkout -b <feature-branch>

~

4. É sempre bom deixar sua feature branch atualizada com o sistema em produção, evitando assim conflitos maiores na hora de colocar sua funcionalidade em produção.
Pode ser que foi adicionado uma nova funcionalidade ou até mesmo um hotfix no sistema em produção (master)
git checkout master
git pull --rebase origin master
git checkout <feature-branch>
git pull --rebase origin <feature-branch>
git rebase master

~

5. Compartilhando sua funcionalidade // Mais pessoas vão me ajudar nessa nova funcionalidade! （＾▽＾）／＼（＾▽＾）
Para tornar sua feature branch publica, basta empurrar (push) para o servidor central.
git push origin <feature-branch>

~

Acabei a Feature

6.1 Atualizando tudo
  git pull origin <feature-branch> # se a branch for publica
   # se algum confito foi encontrado seguir com fluxo de merge de rebase
   git checkout master
   git pull --rebase origin master
   # se algum confito foi encontrado seguir com fluxo de merge de rebase
   git checkout <feature-branch>
   git rebase master
   # se algum confito foi encontrado seguir com fluxo de merge de rebase


6.2 Reintegrando a branch da feature na master // colocando o sistema em produção
  git checkout master
   git merge <feature-branch>

Nenhum conflito deve ser encontrado, pois o rebase com a master já resolveu esses problemas

6.3 Excluindo branch da nova feature // limpando nossas sujeiras
  git branch -d <feature-branch>

Importante: sempre usar d (minusculo) D (maiusculo) força exclusão da branch
  git push origin :<feature-branch> # Para excluir branch remota
   # Nas outras máquina que possuirem a referencia para a branch remota deletada executr o seguinte comando
   git branch -rd origin/<feature-branch>


6.4 Criação de tags
Se for o caso é possível criar uma tag para marcar a nova versão em produção
  git tag -a v<numero.da.versao> -m 'Release <numero.da.versao>' #Cria a tag localmente
   git push origin --tags #Envia a tag para o remoto

~

Hotfix // Erros em produção
Importante: os camando devem ser executados com o VS FECHADO*

7.1 Recuperando ultima versão do codigo de produção
  git checkout master # se não estiver na branch master
   git pull --rebase origin master
   # se algum confito foi encontrado seguir com fluxo de merge de rebase


7.2 Criando branch com o hotfix
  git checkout -b <hotfix-branch>

Essa branch deve ser privada, ou seja, não deve existir no remoto, apenas o dev que está codificando o hotfix deve ter acesso ao mesmo

7.3 Reintegrando hotfix
  git checkout master
   git pull --rebase origin master
   # se algum confito foi encontrado seguir com fluxo de merge de rebase
   git checkout <hotfix-branch>
   git rebase master
   # se algum confito foi encontrado seguir com fluxo de merge de rebase
   git checkout master
   git merge <hotfix-branch>


7.4 Excluindo branch do hotfix
  git branch -d <hotfix-branch>

Importante: sempre usar d (minusculo) D (maiusculo) força exclusão da branch

~

8. Merge rebase // CONFLITOS HELP!1!!! ヽ(●-`Д´-)ノ - (⊙_◎) - 「(°ヘ°)
Após o rebase algum conflito foi encontrado

Configurando kdiff3
http://naleid.com/blog/2012/01/12/how-to-use-kdiff3-as-a-3-way-merge-tool-with-mercurial-git-and-tower-app/

Resolvendo conflitos
  git mergetool

Após a respota do git tecle enter para iniciar a ferrmenta de merge
Lembrando que no Kdiff 3:
Local = arquivo feito por você
Remote = arquivo feito, provavelmente, por outra pessoa, veio do servidor
Base = Origem dos arquivos local e remote
Resolva todos os conflitos usando a ferramenta de merge e salve o arquivo
Se mais algum arquivo precisa de merge, o git vai informar e basta teclar enter para realizar o merge usando a ferramenta de merge.
Quando nenhum arquivo precisar de merge basta continuar o rebase
  git rebase --continue

Quando concluir o rebase o git retornar a branch de origem, porém com as alterações da outra branch utilizada no rebase. Utilize o seguinte comando para verificar como ficou a arvore do git:
  gitk --all &
	1. Criando um repositório remoto

	O Git possui várias formas de se comunicar, protocolos, com os repositórios. Estamos usando o chamado [wiki:git_protocolo_local Protocolo Local].
	Para criar um repositório remoto precisamos seguir os seguintes passos:

	A. Abra o Bash do Git
	B. Navegue até o local de criação

	cd /x
	cd dotnet

	//Onde X é a letra correspondente ao mapeamento da pasta compartilhada com o servidor (meu X:)//
	C. Crie uma pasta (padrão .git)
	mkdir levelupgames.myproject.git
	D. Inicialize um repositório bare

	cd levelupgames.myproject.git
	git --bare init

	Por quê "bare" ?
	Um //bare repository// contém informações de controle e não contém //working files//. Ele não contem o sub-diretório .git, ao invés disso contém o conteúdo (do sub-diretório .git) diretamente em sua raiz. Um repositório precisa necessariamente ser do tipo //bare// para aceitar //push//.

	Clonando um repositório
	Para criar um repositório local precisamos seguir os seguintes passos:

	A. Abra o Bash do Git
	B. Navegue até o local de seus projetos

	cd /c
	cd git/rep

	C. Clonar

	git clone file://x:/dotnet/levelupgames.myproject.git
	OU
	git clone /x/dotnet/levelupgames.myproject.git

	//Onde X é a letra correspondente ao mapeamento da pasta compartilhada com o servidor (meu X:)//

	~

	2. Criar um novo repositório
	Para criar um novo repositório basta ir até o servidor central, criar uma pasta e inicializar um repositório bare (sem arvore de trabalho).
	Voltar para sua pasta de repositórios local e clonar esse repositório.

	cd /<letra-mapeada>:/dotnet/ #acessa o servidor remoto, troque <letra-mapeada> pela sua letra (a minha é a f:)
	mkdir levelupgames.nome_do_projeto.git
	cd levelupgames.nome_do_projeto.git/
	git init --bare
	cd /c/git/rep/ #volta para sua pasta de repositórios local
	git clone file://f:/dotnet/levelupgames.nome_do_projeto.git/


	~

	3. Começar uma feature
	Para começar uma nova funcionalidade basta criar uma nova branch com o nome da sua funcionalidade a partir da branch master.
	É importante atualizar sua master para garantir que você esteja criando sua branch a partir da ultima versão.

	git checkout master
	git pull --rebase origin master
	git checkout -b <feature-branch>

	~

	4. É sempre bom deixar sua feature branch atualizada com o sistema em produção, evitando assim conflitos maiores na hora de colocar sua funcionalidade em produção.
	Pode ser que foi adicionado uma nova funcionalidade ou até mesmo um hotfix no sistema em produção (master)
	git checkout master
	git pull --rebase origin master
	git checkout <feature-branch>
	git pull --rebase origin <feature-branch>
	git rebase master

	~

	5. Compartilhando sua funcionalidade // Mais pessoas vão me ajudar nessa nova funcionalidade! （＾▽＾）／＼（＾▽＾）
	Para tornar sua feature branch publica, basta empurrar (push) para o servidor central.
	git push origin <feature-branch>

	~

	Acabei a Feature

	6.1 Atualizando tudo
	git pull origin <feature-branch> # se a branch for publica
	# se algum confito foi encontrado seguir com fluxo de merge de rebase
	git checkout master
	git pull --rebase origin master
	# se algum confito foi encontrado seguir com fluxo de merge de rebase
	git checkout <feature-branch>
	git rebase master
	# se algum confito foi encontrado seguir com fluxo de merge de rebase


	6.2 Reintegrando a branch da feature na master // colocando o sistema em produção
	git checkout master
	git merge <feature-branch>

	Nenhum conflito deve ser encontrado, pois o rebase com a master já resolveu esses problemas

	6.3 Excluindo branch da nova feature // limpando nossas sujeiras
	git branch -d <feature-branch>

	Importante: sempre usar d (minusculo) D (maiusculo) força exclusão da branch
	git push origin :<feature-branch> # Para excluir branch remota
	# Nas outras máquina que possuirem a referencia para a branch remota deletada executr o seguinte comando
	git branch -rd origin/<feature-branch>


	6.4 Criação de tags
	Se for o caso é possível criar uma tag para marcar a nova versão em produção
	git tag -a v<numero.da.versao> -m 'Release <numero.da.versao>' #Cria a tag localmente
	git push origin --tags #Envia a tag para o remoto

	~

	Hotfix // Erros em produção
	Importante: os camando devem ser executados com o VS FECHADO*

	7.1 Recuperando ultima versão do codigo de produção
	git checkout master # se não estiver na branch master
	git pull --rebase origin master
	# se algum confito foi encontrado seguir com fluxo de merge de rebase


	7.2 Criando branch com o hotfix
	git checkout -b <hotfix-branch>

	Essa branch deve ser privada, ou seja, não deve existir no remoto, apenas o dev que está codificando o hotfix deve ter acesso ao mesmo

	7.3 Reintegrando hotfix
	git checkout master
	git pull --rebase origin master
	# se algum confito foi encontrado seguir com fluxo de merge de rebase
	git checkout <hotfix-branch>
	git rebase master
	# se algum confito foi encontrado seguir com fluxo de merge de rebase
	git checkout master
	git merge <hotfix-branch>


	7.4 Excluindo branch do hotfix
	git branch -d <hotfix-branch>

	Importante: sempre usar d (minusculo) D (maiusculo) força exclusão da branch

	~

	8. Merge rebase // CONFLITOS HELP!1!!! ヽ(●-`Д´-)ノ - (⊙_◎) - 「(°ヘ°)
	Após o rebase algum conflito foi encontrado

	Configurando kdiff3
	http://naleid.com/blog/2012/01/12/how-to-use-kdiff3-as-a-3-way-merge-tool-with-mercurial-git-and-tower-app/

	Resolvendo conflitos
	git mergetool

	Após a respota do git tecle enter para iniciar a ferrmenta de merge
	Lembrando que no Kdiff 3:
	Local = arquivo feito por você
	Remote = arquivo feito, provavelmente, por outra pessoa, veio do servidor
	Base = Origem dos arquivos local e remote
	Resolva todos os conflitos usando a ferramenta de merge e salve o arquivo
	Se mais algum arquivo precisa de merge, o git vai informar e basta teclar enter para realizar o merge usando a ferramenta de merge.
	Quando nenhum arquivo precisar de merge basta continuar o rebase
	git rebase --continue

	Quando concluir o rebase o git retornar a branch de origem, porém com as alterações da outra branch utilizada no rebase. Utilize o seguinte comando para verificar como ficou a arvore do git:
	gitk --all &