Desenvolvedores: Tutorial básico de GIT

[_Virtual_Adept_]

Bem, já que vamos usar o GIT, vamos às informações primordiais sobre ele:

Instalação
Ambiente Windows

SPOILER: EXIBIR

Baixem o GIT Aqui
Apertem sempre next, sem alterar opções.
Para usar o GIT, usem o GIT Bash. Existe uma versão visual, mas eu tenho que ser sincero: eu não faço ideia de como ela é usada. Pelas opções dadas, o GIT não vai funcionar no Prompt de Comando do Windows (acreditem, é melhor assim).

Ambiente Linux (Ubuntu)

SPOILER: EXIBIR

sudo apt-get install git-core git-doc git-gui gitk
(Também podem instalar o git-svn, se vocês se interessarem pelo GIT e quiserem importar um repositório SVN para ele)
É só isso. Vocês podem usar o comando git no terminal.

Configurações iniciais
Windows

SPOILER: EXIBIR

Abram o GIT Bash. Vão inserindo os comandos a seguir, de um por um:
git config --global core.autocrlf true
git config --global user.name "Seu nome"
git config --global user.email seuemail@seudominio.com

Linux

SPOILER: EXIBIR

Abram o terminal. Insiram, de um por um, os comandos a seguir:
git config core.autocrlf input
git config --global user.name "Seu nome"
git config --global user.email seuemail@seudominio.com

Copiando o Repositório

SPOILER: EXIBIR

Para copiar o repositório é fácil. Abram o Terminal ou o GIT Bash, vão até a pasta onde desejam que fique o diretório da aplicação, e digitem:
git clone endereço_do_servidor
O servidor ainda não tem endereço (só vamos decidir isso depois que a questão do GitHub for resolvida). Vou substituir aqui, depois disso

Atenção: A partir daqui, tudo só poderá ser feito DEPOIS de clonar o servidor. Todos os comandos deverão ser executados no diretório-raíz do projeto

Abrindo um "ramo"

SPOILER: EXIBIR

O Git, como todo sistema de gerenciamento, possui um "tronco" de desenvolvimento, onde as alterações finais vão ser colocadas, e vários "galhos" (branches), onde trabalharemos (dessa forma, impedimos que alterações que não gostamos atrapalhem o desenvolvimento). Não trabalharemos no tronco (a branch master). Então, cada um abra sua(s) própria(s) branch(es).

Vocês podem ter quantas branches quiserem localmente, podem apagá-las e criá-las à vontade, de acordo com a necessidade. Se, por exemplo, tiverem alguma ideia legal, mas que é muito experimental e vocês não souberem que vai dar certo, podem abrir uma nova branch, e se não gostarem do resultado, apagá-la.

O comando para abrir uma nova branch é esse:
git branch nome_da_branch

Para mudar a branch:
git checkout nome_da_branch

Depois que você abre uma branch nova, ela NÃO muda automaticamente. Então você deve fazer o checkout.

Apagando uma branch

SPOILER: EXIBIR

git branch nome_da_branch -D

"Confirmando" alterações locais

SPOILER: EXIBIR

Quando você tem uma alteração que você sabe que funciona, você faz um "commit". Um commit cria uma versão nova, armazenando no GIT todas as alterações que você fez (mas apenas na branch atual). Se você tiver criado um arquivo novo, é MUITO IMPORTANTE adicioná-lo ao repositório, antes de fazer o commit, ou o GIT não reconhecerá o arquivo. Para adicionar um arquivo, use o comando:
git add .

Para, efetivamente, fazer o commit, use o comando:
git commit -a

No Windows, esse comando abrirá o vi. Aperte "insert" para fazer alterações no texto, digite uma descrição de que alteração você fez (por exemplo: inserindo novo banner no site). Você PRECISA digitar essa descrição, ou o git abortará o commit (o que é bom, caso você tenha começado a fazer um commit e se arrependa, basta não digitar nada na descrição e fechar o vi).

Depois que a descrição foi digitada, aperte ESC, :wq e ENTER. Isso salvará o arquivo e fechará o vi.


No Linux, esse comando abrirá o nano. Digite a descrição, aperte Ctrl+O e depois Ctrl+X. Você pode abertar só Ctrl+X para cancelar o commit.

Revertendo a branch atual para o último commit feito

SPOILER: EXIBIR

Se você estava fazendo alterações, não gostou delas, mas não quer apagar a branch porque os commits anteriores estavam bons, use o comando
git reset --hard

Juntando branches

SPOILER: EXIBIR

Quando você tem duas branches separadas, pode querer juntar a funcionalidade de ambas. Faça o checkout para a branch que você quer que fique com as alterações de ambas. Depois, execute o comando.

git merge nome_da_outra_branch

Caso dê algum conflito (por exemplo: um arquivo foi editado de uma maneira em uma branch, e foi editado de outra maneira em outra branch), o GIT avisará qual arquivo está com conflito. Abra o arquivo, faça a edição para resolver o conflito, depois faça o commit do resultado. Não será necessário fazer uma descrição do commit, nesse caso en específico, o GIT o fará automaticamente.

No Windows, apenas digite :wq ENTER quando o vi abrir.

No Linux, apenas digite Ctrl+X quando o nano abrir.

Enviando alterações para o servidor

SPOILER: EXIBIR

Quando você estiver com uma branch com uma funcionalidade nova completa, você pode enviar as alterações para o repositório principal com o comando
git push origin nome_da_branch

NÃO enviem alterações diretamente da master. O GIT vai retornar um erro. Façam sempre alterações numa branch separada.

Atualizando o repositório local

SPOILER: EXIBIR

Quando você quiser receber as alterações que os outros desenvolvedores colocaram no servidor, use o comando
git push

As alterações que realmente importarem estarão na branch origin/master. Então, para você efetivamente atualizar sua branch, terá que fazer o merge com a origin/master.
git merge origin/master

Como em qualquer merge, podem ocorrer conflitos. Resolva os conflitos normalmente.

Quando aparecerem maiores dúvidas (aparecerão, quando realmente começarmos a programar), podem perguntar para mim.

[Vincer]

Esse é o tipo de coisa que eu colocaria num groups(google ou qualquer outro), aberto a qualquer um entrar, para o pessoal que realmente vai lidar com essas ferramentas debater. Só eu acho estranho/deslocado/errado posts técnicos sobre backend no meio do fórum onde o assunto é RPG? Debates sobre admnistração é uma coisa, pedir opniões antes de implantar algo também faz parte... mas isso me parece meio deslocado para o fórum.

Fora isso, valeu pelo tutorial. Eu particularmente não sou bom na programação (CSS), em parte por preguiça, mas também porque minha área pressupõe que designers trabalhem lado a lado com os programadores(ou seja, desenhando um visual/identidade, repassando os elementos estáticos, bitmaps e especificações para outra parte da equipe implementar[código]).

Então ainda não sei se vou upar versões(ter de lidar com o GIT), a não ser que não tenha outro jeito(pessoal mais habilitado em CSS).