Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

GIT Workflow

No description
by

Diego Pasqualin

on 5 April 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of GIT Workflow

Fluxos de Trabalho no Sistema de Versionamento GIT
- Centralized Workflow
- Feature Branch Workflow
- Gitflow Workflow
- Forking Workflow
Índice
Feature branch worflow
+
branches
especiais +
tags;
Branches
especiais:
develop
,
release, hotfix;
Gitflow Workflow
Cada nova funcionalidade é desenvolvida em seu próprio
branch;
O
merge
para o master é feito através de
merge requests;
Feature Branch Workflow
Possui somente o
branch "master"
, todos os desenvolvedores publicam diretamente nele;

A revisão de código é feita a posteriori;
Centralized Workflow
Repositório central é inicializado
$ git checkout -b issue/1234

$ git status
$ git add <some-file>
$ git commit

$ git push -u origin issue/1234
Maria começa uma nova funcionalidade
Considerando somente os branches
develop
e
branches

feature
o fluxo é o mesmo do
Feature Branch Workflow
, com o
develop
do
Gitflow Workflow
sendo análogo ao
master
do
Feature Branch Workflow
;


Branch develop
Todos clonam repositório central
Maria faz um pull (merge) request
Os
branches
do tipo
release
representam
releases
futuras e são nomeados na forma:
release/X.Y.Z;
Não recebem novas funcionalidades, apenas correções de bugs;

Quando pronto, um
merge
do
branch

release
é feito com o
master
e com o
develop
(
o
release
pode ter recebido correções que devem ser visíveis as novas
features
no
develop)
;
Após merge, o release/X.Y.Z deve ser deletado;
Branch Release
Fonte: https://www.atlassian.com/git/workflows
git clone ssh://user@host/path/to/repo.git
João aplica uma nova funcionalidade
$ git status # Ver mudanças locais
$ git add <file> # Adicionar arquivo
$ git commit <file> # Submeter arquivo

# Enviar para repositório remoto
$ git push origin master
Maria tenta aplicar uma nova funcionalidade
$ git push origin master

error: failed to push some refs to '/path/to/repo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.


Maria reconstrói sua base local
$ git pull

# Git pausa a operação quando encontra conflito.
# Resolva conflitos de cada commit de forma independente

$ git add <file> # Para resolver o conflito
$ git rebase --continue # Seguir para próximo commit
$ git rebase --abort # Cancela toda a operação desde git pull
Maria aplica nova funcionalidade
$ git push origin master


Desenvolvedores revisam código
Maria aplica correções e funcionalidade é adicionada ao
master
Se o
branch master
for protegido somente os
masters
do repositório podem fazer o
merge
, caso contrário a própria Maria pode fazê-lo.
Contém correções de
bugs
que não podem aguardar o lançamento de uma próxima
release
.
O
merge
de um
hotfix
é o único feito diretamente com o
master
, além do
branch

develop
(e
release
, se existir);

Branch hotfix
Todo merge para o
master
recebe uma
tag
com o nome do
branch

release
de origem, ou um acréscimo mínimo de versão quando originado de um
branch

hotfix
Branch master
Existe um repositório "oficial", mas cada desenvolvedor tem seu próprio repositório remoto, um
fork
do original;

Forking Workflow
Cada desenvolvedor pode utilizar o
workflow
que preferir;
Os desenvolvedores não precisam ter acesso de escrita no repositório oficial;
Muito comum no desenvolvimento de grandes aplicações open source;

Vantagens
Os interessados em colaborar com um projeto fazem um
fork
(cópia) dele, modificam criando funcionalidades e/ou corrigindo
bugs
, posteriormente submetem um
merge request
do seu repositório para o repositório oficial.
Fork -> Alteração -> Merge Request
Os projetos do C3SL são a união de um dos fluxos de trabalho anteriores
(fortemente recomendado Feature ou Gitflow workflow).
O Forking Worflow só é utilizado para contribuir ou permitir contribuições da comunidade externa.
No C3SL
Contato: dpasqualin@gmail.com
Diego Giovane Pasqualin
Full transcript