joaomas
commented
1 month ago @cfbastarz estamos trabalhando com o PR do Saulo .
Closed joaomas closed 3 weeks ago
joaomas
commented
1 month ago @cfbastarz estamos trabalhando com o PR do Saulo .
:people_holding_hands: User Story
COMO (...) QUEREMOS (...) PARA (...)
:clipboard: Critérios de aceite de conclusão da Issue
:pencil: Detalhamento adicional da atividade
:comet: Impactos
-.
:link: Dependências
504 - OK
:hammer_and_wrench: Solução
Analise da DTN-03 com o Pull Request
Ações após PR
Foi atribuído "reviewer" e "assignees" para a minha conta @joaomas e add label "pull request" no PR.
Orientação do GitHub para análise do PR.
Step 1: From your project repository, check out a new branch and test the changes.
git checkout -b saulorfreitas-develop develop git pull https://github.com/saulorfreitas/MONAN_Phys_SRF_v1.git develop
Step 2: Merge the changes and update on GitHub.
git checkout develop git merge --no-ff saulorfreitas-develop git push origin develop
O conflito se deu pois o PR foi feito antes da correção do bug pelo LF. Foi então alterado para a solução do LF.
Após solução o PR foi finalizado com sucesso, com o código do PR mergeado no Develop.
Antes de rodar o cron foi renomeado o arquivo /mnt/beegfs/monan/scripts_CD-CT_dev/scripts_CD-CT/datain/fixed/x1.1024002.static.nc para OLD para forçar a geração deste na etapa do pré. Após o arquivo foi removido.
O Cron DEV na Egeon atualizou com a nova versão do Dev.
Discussões sobre PR x GitFlow e PR
"Pull Request
Podemos trabalhar com Git Flow e Pull Request. Mas, isso não é gerenciado pelo plugin, quando o utilizamos. Tudo que vem das branches de melhoria (feature, bugfix etc) pode ser enviado para a develop via Pull Request, ao invés de um merge manual, até ai bem tranquilo. Assim conseguimos garantir que o time está revisando tudo que chega na branch develop.
Para a branch master, as coisas mudam um pouco. As branches que originam merges para a master (branches de “preparo de versão” — release e hotfix) também precisam fazer o merge para a develop. O processo para que PRs para a master funcione, basicamente consiste em, após o PR criado, aprovado e “mergeado” da release/hotfix para master, fazemos a finalização da release/hotfix normalmente pela linha de comando. Usando comandos do Git Flow, tudo funciona normal, e com comandos do Git podemos “pular” a etapa de merge com a master.
Em alguns times que utilizam processos semelhantes é possível observar a adoção apenas de pull request a partir de hotfix dado que todo código feito nessa branch não é validada e revisada em outra etapa. Branches de release são iniciadas a partir da develop, branch previamente validada. "
"So, why don't we use git-flow at GitHub? Well, the main issue is that we deploy all the time. The git-flow process is designed largely around the "release". We don't really have "releases" because we deploy to production every day - often several times a day. We can do so through our chat room robot, which is the same place our CI results are displayed. We try to make the process of testing and shipping as simple as possible so that every employee feels comfortable doing it."
So, what is GitHub Flow?
Anything in the master branch is deployable
To work on something new, create a descriptively named branch off of master (ie: new-oauth2-scopes)
Commit to that branch locally and regularly push your work to the same named branch on the server
When you need feedback or help, or you think the branch is ready for merging, open a pull request
After someone else has reviewed and signed off on the feature, you can merge it into master
Once it is merged and pushed to 'master', you can and should deploy immediately
Comparing Git workflows: What you should know - https://www.atlassian.com/git/tutorials/comparing-workflows
Understanding the GitHub Pull Request - https://blog.mergify.com/understanding-the-github-pull-request-workflow/
"Choosing a Git pull request workflow
There are multiple git pull request workflows to choose from in addition to the GitHub flow model described above, and each one offers unique advantages that might suit your team. However, at least one of these—the centralized workflow—can’t accommodate pull requests and should be avoided if you prefer to leverage such requests in your own project's history.
There are a few additional Git workflow models you might consider trying if you are planning on using pull requests, such as the afore-mentioned Gitflow model, the feature branch workflow model, and the forking workflow model. Each of these is great for certain applications and not so great for others. The forking model is particularly well-suited to open projects with many different collaborators, for instance, as repositories are neatly copied each time they’re forked."
GitFlow x GitHub Flow - https://www.split.io/blog/github-flow-vs-git-flow-whats-the-difference/
Pull request workflow - https://nulab.com/learn/software-development/git-tutorial/git-collaboration/reviewing-changes/pull-requests-workflow/
"Manoj Shetty March 26, 2014
Hi,
One workflow for this problem can be:
1) Master branch is the production ready branch. Only the Team leader has permissions to write or merge on Master branch.
2) Before starting the next Iteration for the Sprint release, you can create a new Release branch 2.0 on the Remote Repo
3) Every developer will checkout from Release 2.0 branch before coding. Then create a new Feature branch based on Release branch.
4) Developer will do coding and commit on Local Repo - Feature branch
5) Developer will push the Local Repo Feature branch to Remote repo Feature branch
6) by this time, Bamboo build will trigger for the Remote - Feature branch - if Build pass then Pull request can be created
7) If build pass, Developer creates the Pull request and assign to Team leader for code review
8) Team leader will do the code review and merge Feature branch to Release branch - later the Bamboo build will trigger on Release branch
9) later the Feature branch will be deleted
10) after all Features are developed and merged, finally when the Release branch is stable and build is also pass.
11) QA team will do all testing on Release branch
12) if all pass on Release branch, Team leader will merge from Release branch to Master branch.
regards"
:rotating_light: Problemas encontrados
-.
:white_check_mark: Conclusão
:spiral_calendar: Trabalhos Futuros
-.