O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Git collaboration

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Próximos SlideShares
Git flow Introduction
Git flow Introduction
Carregando em…3
×

Confira estes a seguir

1 de 29 Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Semelhante a Git collaboration (20)

Anúncio

Mais recentes (20)

Git collaboration

  1. 1. Collaboration with Git & Bitbucket Pikicast R&D Jack Pham
  2. 2. Pull Request and Code Review
  3. 3. Anatomy of a Pull Request source repo target repo source branch target branch Reviewers Reviewers Merge pull request
  4. 4. Pull request process A developer creates the feature in a dedicated branch in their local repo. feature The developer pushes the branch to a public Bitbucket repository. local repo public repo push feature The developer files a pull request via Bitbucket. file a pull request feature master master Reviewers The rest of the team reviews the code, discusses it, and updates it. The project maintainer merges the feature into the official repository and closes the pull request. public repo
  5. 5. Workflows with Git
  6. 6. feature master feature Centralized Workflow Feature Branch Workflow Gitflow Workflow Forking Workflow
  7. 7. Centralized Workflow
  8. 8. Working Workflow - Everybody working on the same branch$ git pull # Update latest code # Edit files $ git add <file> # Stage file $ git commit # Commit change $ git push # Push to remote repo pull pull push origin/master origin/master push Cannot push because the base has changed origin/master master pull merge rebase + fast-forward merge origin/master master origin/master master push
  9. 9. When to use - Everybody working on the same branch - Simple flow - No review or feature request allowed - More conflict if many devs +Easy to manage +Good for less prone to change project +Good for maintaining project Infra Team ?
  10. 10. Feature Branch Workflow feature master feature
  11. 11. Feature Branch Workflow - There are: - One master branch - Many feature branches (each for a feature) - Each feature is developed on a dedicate branch - A pull request is filed when feature is completed - Feature branch is closed (delete) after finish feature master feature
  12. 12. Working on crazy_feature # Implement the feature $ git add <file> # Stage file $ git commit # Commit change $ git pull # Update latest code $ git checkout -b crazy_feature $ git push -u origin # optional master feature master feature master crazy_feature Local Remote crazy_feature master crazy_feature master crazy_feature master 1.0 crazy_feature master 1.0 $ git push # Push to remote repo
  13. 13. Finalise crazy_feature # Implement the feature $ git add <file> # Stage file $ git commit # Commit change $ git push # Push to remote repo feature master feature Remote crazy_feature master crazy_feature master Local hotfix or other feature crazy_feature master hotfix or other feature Reviewers master master Merge Rebase
  14. 14. When to use feature master feature - Dirty master branch - Develop vs. Production - Feature vs. Hotfix - NO Release tracking +Relatively easy to manage +Code review support +Good for internal project (no hand off release to end-users) Simple team structure, focus task, few concurrent task
  15. 15. Git-flow Workflow
  16. 16. - There are: - One master branch - One develop branch - One temporary branch for each release - One feature branch for each feature - One temporary hotfix branch for each hot fix Git-flow Workflow anatomy
  17. 17. Development semantic versioning Release Feature Branch Workflow
  18. 18. Gitflow conventions - Master branch tracks release - Develop branch tracks feature/issue development - Hot-fix branches are always branched off master branch - Feature/issue branches are always branched off develop branch - Release branches are always branched off develop branch Branching
  19. 19. Git-flow conventions - Feature branches are always be merged to only develop branch after finish - Hot-fix and Release branches need to be merged to both master and develop branch after finish - Only hot-fix and Release are allowed to merge to Master branch Merging
  20. 20. Gitflow conventions - Feature branches should be named: feature/<name> - ex: feature/walkthrough - Hot fix branches should be named: hotfix/<name> - ex: hotfix/reallyhotfix - Only hot-fix and Release are allowed to merge to Master branch - ex: release/v1.0 Naming
  21. 21. Gitflow Tools (Source Tree)
  22. 22. When to use - Many branch - Need follow convention to have smooth management +Separate release and development +Multi-thread +Prevent dirty branch history +Good for end user product with release base Big team, multiple group and concurrent feature, and regularly release
  23. 23. Forking Workflow
  24. 24. Forking Workflow Official CloneClone Official CloneClone Team1 Team2 Team3
  25. 25. Forking Workflow Centralize Feature Branch Git-flow - Each clone repo can be a central repo of a group - Each may organised as other work flow
  26. 26. When to use - More than one central repo - Huge and distributed - Large scale project Open source project
  27. 27. Reference • Reading • https://www.atlassian.com/git/tutorials • https://git-scm.com/book/en/v2 • https://www.youtube.com/watch?v=OMLh-5O6Ub8 • Git hosting with pull-request • Bitbucket, Github, gitLab…many more

Notas do Editor

  • A developer creates the feature in a dedicated branch in their local repo.
    The developer pushes the branch to a public Bitbucket repository.
    The developer files a pull request via Bitbucket.
    The rest of the team reviews the code, discusses it, and alters it.
    The project maintainer merges the feature into the official repository and closes the pull request.
  • suite for infra team, setting file, configuration file, less likely to change.
  • For feature, merge are recommend because of the history clearly show which commit belong to the feature development.
  • No need to freeze code for release

×