Commit Your Team to an Stable Version - Using GIT in your team, the right way

In this talk, I explained the basic concepts about the GIT version control system, the basic commands to work with and the GIT Flow pattern created by Vincent Driessen and how it could let your team more productive.

Transcript

1. Commit your team to an stable version Using GIT in your team, the right way
2. VCS
3. VCS - Version Control System Revision Control, also know as version control and source control, it's a software to manage different versions in the development of any document. This systems are generally used in the development of softwares to control the versions during the software lifetime and keep a history of the development of that software and it documents.
5. Why GIT? • Free and Open Source • Simple and directly • Quickly and efficient • Designed for little and big projects • Excellent branching and merging • Decentralized, but centralized • GUI tools
6. HISTORY
7. Created by Linus Torvalds
8. Managing Linux Kernel
9. Maintained by Junio Hamano
10. USING GIT
11. GIT for dummies $ git init $ git add $ git commit
12. $ git init $ git add $ git commit $ git pull $ git push GIT for a team of dummies
13. WHY NOT BE A JEDI?!
14. GIT branching A branch in a GIT repository it's a ramification starting from an origin branch, where you can do changes without impact in the main source code of your software.
15. GIT Merge and Rebase Merge and Rebase are actions executed in GIT repositories to join updated did in a branch into another branch.
16. Merge vs Rebase • Merge: Applies a update block in a specific destination branch, generating a new commit on the top of the development history of that branch. • Rebase: Applies a update block on the top of the development history of a specific branch without generate new commits.
17. Merge Pros: • Traceability • More secure Cons: • Dirty development history
18. Rebase Pros: • Clean development history • Handle just one commit is quite easy • Keep updated your development branch Cons: • Dangerous!!! • Don't recommended to use in pull requests • More work • More conflicts
19. GIT FLOW by Vincent Driessen's
20. Descentralized, but centralized
21. Remote repository modeling An organized remote repository generally includes two branches: develop and master. In the first (develop), we centralize the development history of a software. In the second (master), we have an stable history of our system.
22. A successful GIT Flow model
23. Feature development • Define a feature • Ramified from the development branch • Just one developer or team by feature • Continuous Integration • Must be deleted after finished.
24. Are you ready for release? • Ramified from the development branch • Release Hardening • Minor version increases • Updated the documentation and code comments with the new version number • Merge • Tag • Package • Release!
25. BUT... NOTHING IS PERFECT...
26. BUGS
27. Perform a hotfix! • Ramified from the master branch • Fix • Test • Increase patch version • Merge • Publish
28. Supporting an version • Ramified from a tag in the history • Commonly used in: ◦ API's ◦ Long updates ◦ Support a big client in a specific version
29. NOW YOU ARE A GIT JEDI!
30. Thank you! Lucas Mendes devsdmf@gmail.com devsdmf.net about.me/devsdmf github.com/devsdmf Slides at: bit.ly/devsdmf-git-talk