managment team workflow with git work flow ci,cd & release strategy, smantic versioning , code review, lint & test

1. Agile team workflow
Mahmoud Masih Tehrani
Coderconf3

2. Mahmoud Masih Tehrani
Php & Golang developer
about 10 years use GNU/Linux
I love Nature ,Sport ,Theatre ,Free
Software & Programing
Username : mahm0ud or
mahm0ud22
Email:
mahmud.tehrani@gmail.com

3. Git
What is it? Git is a free and open
source distributed version control
system created by Linus Torvalds in
2005 ( Who is also the creator of Linux
kernel ). It is designed to manage
everything for small or very large
projects with speed and efficiency.
Majors organisations like Google,
Facebook, Microsoft uses GIT daily.

4. But, It’s too complicated!
Most of the developer who doesn’t use
git or using git very little, they came up
saying, “Git is too complicated. It’s too
hard to learn. I don’t really understand
it.” Actually, Git is very easy to use and
learn and especially considering how
powerful it is! If you can have the basic
understanding of git flow, it’ll be a life
saviour for YOU.

5. A successful Git branching
model
First post about git workflow
in 2010 By Vincent Driessen

6. What’s the best
workflow
different team
+ different cultural
+ different product
= git workflow

7. Design your own workflows
issue issue
issue issue
Our codeIssues

8. Linear workflow

9. Another code freeze
Idle developer

11. Branching workflow

12. Why branch?
Isolation
Stability
Traceability

13. Git Workflow model
Feature branching
Release branching
Hot fix branching

14. Feature branching
Feature A Feature B
Feature C Feature D
Issues

15. gitlab merge request OR
github pull request

16. release branching

17. Release Branch
Sid
Testing
Stable

18. hot fix branching

19. Tagging Versions(Semantic)
MAJOR.MINOR.PATCH
1. MAJOR version when you make incompatible API
changes,
2. MINOR version when you add functionality in a
backwards-compatible manner, and
3. PATCH version when you make backwards-compatible
bug fixes.

20. Review code

21. code review rules

22. Test & lint

23. Deployment

24. Cycle team

25. tıps for git branching
model efficient usage of git

26. Learn git Command Line by
heart, stop using GUI

27. Only few people should be
authorize for merging
development branch to
master branch

28. ensure that all tests are
passing
before pushing to upstream

29. do not push half-baked,
untested, incomplete,
not-compiling, to-be-fixed,
not-ready-to-deploy code to git
push code. If commit it use
write flag WIP !

30. Never use --m <message> flag to git
commit and Follow Commit message
best practices characters or less.
That is summary.
• First line is 50line
• Then a blank text should be
wrapped at 72 characters.
• Remaining description That is
detailed

31. Branch naming
Issue title
Issue id number
Issue type/issue number/description

32. Squash commits of bug fix
into one and exactly one
commit that completely
represents that bug fix

33. Squash commits of your completed
story into one commit before pushing
to upstream
One Task
One commit
One pull request
Please use Commit - - amend

34. Use .gitıgnore in order not to
send irrelevant files never
push IDE files or package or
binary or temp files

35. Forking a repository allows you to freely experiment
with changes without affecting the original project.

36. Git pull upstream master
- -rebase

37. do not reset without stashing
or committing & tagging

38. references
• A successful Git branching model http://nvie.com/posts/a-successful-
git-branching-model/
• Understanding the GitHub Flow https://guides.github.com/introduction/
flow/
• Gitlab workflow https://about.gitlab.com/2014/09/29/gitlab-flow/
• Comparing workflow https://www.atlassian.com/git/tutorials/
comparing-workflows
• Semantic Versioning http://semver.org/

39. Thanks a lot
The end