do projeto com o VSCODE 3) Inicializar o repositório (comando: git init) 4) Configuração de usuário local: a) git config --global user.name "seu username" b) git config --global user.email “[email protected]” (criar conta, realizar o set up de usuário e inicializar o repositório local) 3
branch que você está, além de listar os arquivos que foram modificados na “WORKING TREE” (separados por estágios) git status ADD: apresenta o nome da branch que você está, além de listar os arquivos que foram modificados na “WORKING TREE” git add -A
do seu projeto git commit -m “mensagem clara e curta” -- AMEND: adiciona os arquivos alterados (ou novos) que estão na staging area ao último commit git commit --amend
a “STAGING AREA” git reset HEAD --HARD: acrescentando esse parâmetro, faz a reversão do estágio do(s) arquivo(s) para a “WORKING AREA” git reset --hard HEAD BLAME: quem realizou as alterações em um determinado arquivo e quando git blame <<arquivo>>
comando git status (arquivo do tipo .txt deverá aparecer na “WORKING AREA”) 3) Criar o arquivo .gitignore 4) Editar o arquivo .gitignore e colocar o seguinte texto: *.txt 5) Executar o comando git status (o arquivo txt não deverá aparecer na “WORKING AREA”) 6) Adicionar o arquivo .gitignore para a STAGING AREA (git add -A) 7) Realizar o commit com a seguinte frase: “Ignorando arquivos txt da pasta raiz” (realizar o primeiro commit) 10
um alias git remote add origin <<url_do_repositório>> PUSH: empurra as alterações para a nuvem git push origin master PULL: “puxa” as atualizações existentes em relação a branch que você referenciar git pull origin master
Copiar o link com o protocolo https 4) Adicionar o host remoto (git remote add origin <<link>>) 5) Realizar o push da branch master para a nuvem 6) Atualizar o repositório remoto e verificar se o código está lá. (disponibilizar o código na nuvem) 10
uma branch nova (localmente) com base na branch que você está “checado” git branch <<nome_da_branch>> -D: remove a branch (é necessário dar checkout da mesma, ou seja, não estar nela) localmente git branch -D <<nome_da_branch>>
checkout 1.1 Possui branch e permite o checkout 1.2.1 possui branch e permite checkout 1.2 não possui branch localmente 1.2.2 não possui branch e não permite checkout
remoto git fetch CHECKOUT: sai de uma branch e vai para outra git checkout <<nome_da_branch>> STASH: guarda todo o conteúdo da “WORKING AREA” e da “STAGING AREA” em uma pilha (stash) git stash
Criar um arquivo novo com algum conteúdo dentro 3) Realizar o commit deste arquivo 4) Dar checkout novamente para a master 5) Realizar o merge da branch feature/1 na master (localmente) 6) Verificar com o comando log se o commit da feature/1 está na master (ver pela mensagem) 7) Dar o push da master para a nuvem (realizar o merge localmente) 10
arquivo, na mesma linha. COMO LIDAR? - Melhorar a qualidade dos conflitos. - Diminuir a frequência em que ocorrem. - Não realizar commits diretamente em branches “longevas”. - Manter o histórico linear. (sem commits de merge) - Realizar Rebase
no seu repositório remoto. • São branches locais que você não pode mover, eles se movem automaticamente sempre que você faz alguma comunicação via rede. O QUE SÃO? UTILIDADE • Branches remotos agem como marcadores para lembrá-lo onde estavam seus branches no seu repositório remoto na última vez que você se conectou a eles. • Também servem para comparação com as branches de base para merge • Permite visualização para code review
branch nova a partir da mesma (feature/3) 3) Adicionar um arquivo novo com algum conteúdo 4) Realizar o commit deste arquivo 5) Dar checkout para a master 6) Realizar o merge da nova branch (feature/3) na master 7) Dar checkout para a feature/2 8) Realizar o rebase com a master 9) Dar push da feature/2 para a nuvem (realizar o rebase) 10
da tag>>: realiza a marcação da hash de commit com um nome git tag <<nome_da_tag>> PUSH <<nome_da_tag>>: disponibiliza a tag na nuvem git push origin <<nome_da_tag>>
checkout da master para uma nova branch (feature/4) 3) Modificar o conteúdo dos arquivos existentes na branch 4) Adicionar alguns arquivos e conteúdo dentro dos mesmos 5) Realizar o commit 6) Dar push da branch nova para a nuvem 7) Ir até o serviço de repositório remoto e criar o pull request 8) Validar as alterações e fazer o merge na modalidade fast-foward 9) Verificar os commits da master da nuvem e se certificar de que os commits estão na mesma (realizar merge através de pull request) 15
com a anterior MINOR: versão que adiciona uma funcionalidade que tem compatibilidade com a versão major PATCH: versão que marca uma correção compatível com a versão minor MAJOR.MINOR.PATCH (v0.0.0)
BRANCH WORKFLOW - Master é sagrada! - Funcionalidades são desenvolvidas em branches separadas, sem incomodar o código principal - Permite discussões acerca da branch GIT FLOW - Foi apresentado por Vincent Driessen - Desenhado para as releases de projeto - Para gerenciar projetos grandes - Trabalha com duas branches de longa vida: master e develop - Branches de vida curta: feature, release e hotfix
um fluxo de trabalho para sua equipe, é mais importante considerar a cultura da mesma. Afinal, você quer implementar um fluxo para aumentar a efetividade da equipe e não para ser um fardo que limita a produtividade. “ - Este fluxo escala para o tamanho da equipe? - É simples desfazer os erros com este fluxo? - Este fluxo impõe qualquer carga desnecessário para a equipe?
yurireeis
kawaguti
oracle4engineer
harishpillay
toshi_atsumi
inesmontani
yug1224
ynunokawa
danielbryantuk
kazuya_araki_tokyo
databricksjapan
recruitengineers
rainerhahnekamp
soudai
jlugia
rocio
marcelosomers
tammyeverts
kneath
panda_program
kastner
jonrohan
skipperchong
philhawksworth
holman
