Branch strategy
Branch Descrição
Master Branch inicial com o repositório do produto
Prod Branch em utilização no ambiente produção
PreProd Branch em utilização no ambiente pre-produção
Dev- Branch em utilização em sprint de desenvolvimento
Sprint”SprintName”
Dev-”Dev Initials” Branch para desenvolvimento das USs
“Env”-FixID Branch para efectuar fix direct no ambiente
Funcionamento
Here is an overview of the pull request workflow:
• 0. “Pull” the changes to your local machine (get the
most recent base)
• 1. Create a “branch” (version)
• 2. Commit the changes
• 3.a Push your changes
• 3.b Open a “pull request” (propose changes)
• 4. Discuss and review your code
• 5. Rebase and tests
• 6. “Merge” your branch to the master branch
Funcionamento
Create a “branch”
The master branch is the “default” branch when you create a repository. Use other branches for
development and merge them back to the master branch upon completion.
create a new branch named “feature_x” and switch to it using
git checkout -b feature_x
a branch is not available to others unless you push the branch to your remote repository
git push origin <branch>
Funcionamento
Commits
This process of adding commits keeps track of your progress as you work. Commits also create a
transparent history of your work that others can follow to understand what you’ve done and why. Each
commit has an associated commit message, which is a description explaining why a particular change
was made.
Furthermore, each commit is considered a separate unit of change. This lets you roll back changes if a
bug is found, or if you decide to head in a different direction.
Funcionamento
Push your changes
Pull Requests initiate discussion about your commits. Anyone can see exactly what changes would be
merged if they accept your request.
You can open a Pull Request at any point:
when you have little or no code but want to share some screenshots or general ideas,
when you’re stuck and need help or advice,
or when you’re ready for someone to review your work.
Funcionamento
Discuss and review your code
Once a Pull Request has been opened, the person or team reviewing your changes may have questions
or comments (the most often through your git host platform). Perhaps the coding style doesn’t match
project guidelines, the change is missing unit tests, or maybe everything looks great and props are in
order. Pull Requests are designed to encourage and capture this type of conversation.
You can also continue to push to your branch in light of discussion and feedback about your commits. If
someone comments that there is a bug in the code, you can fix it in your branch and push up the
change.
Funcionamento
Rebase and tests
Once your pull request has been reviewed and the branch passes your tests, you can rebase your branch
on master (it will use the most recent version of the code base) in order to test all the changes together
(production).
Rebase
To take all the changes that were committed on master and replay them on the current branch.
git rebase master
This operation works by resetting the current branch to the same commit as master, and applying each
commit of the current branch.
Funcionamento
Merge
Now that your changes have been verified in production, it is time to merge your code into the master
branch.
Tag & Version
It is recommended to create tags for software releases. You can create a new tag named Hurna v1.3.0
by executing
git tag -a v1.3.0 -m "Hurna v1.3.0"
This makes it easy to keep track of your versions and rollback if needed.
Funcionamento Branchs
Novo Sprint Fim Sprint
Master
Release
Production
Prod-defect-001 Prod-defect-002
Fim Sprint
Staging
PreProd-TestBug001
Development
Developer 1
Story001 Story003 Story004
Developer 2
Story002
