Worst Practices for version control

I have been programming since I was a kid and have been using git since 2013. I was a noob when I started using it and due to not knowing about it perfectly some of my experiments actually got me to lose my 2 days work which was terrible. Some practices I didn’t follow made my life stick. When I actually wanted to use the power of version control, I couldn’t efficiently switch between commits or sometimes my git history was just a big mess to figure out. We use tools to make our life easier not to jeopardize the productivity if it is making you efficient or doing no good to you then you probably might wanna change it or find an alternative or learn the good practices of using it so that you can call it your weapon. If you think you know git and you wanna learn about good way to use it or git gave you hard time back in past then probably you are in right place.

Transcript

1. Worst Practices for version control Smit Thakkar
2. README.md • Chief Architect at Corridor Funds • Contributor at: FossAsia, Gluster and NgUI • Github: https://github.com/smitthakkar96 • Email: smittthakkar96@gmail.com
3. What is version control? Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. For the examples in this book, you will use software source code as the files being version controlled, though in reality you can do this with nearly any type of file on a computer.
5. ME
7. Version control everything…..
8. • Version control only the source code • Use .gitignore
10. Commit messages are for losers
11. Things to consider when writing commit messages • Write the summary line and description of what you have done in the imperative mode, that is as if you were commanding someone. Start the line with "Fix", "Add", "Change" instead of "Fixed", "Added", "Changed". • Always leave the second line blank. • Line break the commit message (to make the commit message readable without having to scroll horizontally in gitk).
12. Committing broken code to main branch
13. Committing code with console logs and old commented code
14. Committing unrelated changes
15. Committing directly to master
16. Big monolithic Repository
17. The “fix previous commit” commit 664e6ac (HEAD, master) Fix one line in verification method (4 minutes ago) 3945ef1 Add verification method (5 minutes ago)
18. Solution: git commit --amend
20. What is rebase? • It is a powerful tool capable of modifying git history • Enables developers to squash, delete and change order of commits
21. Unorganized workflows
22. Git Workflows • Centralized Workflow • Forking Workflow • Feature branching • Gitflow workflow
23. Centralized Workflow
24. Centralized Workflow Process • Initialize the central repository • Clone the central repository • Make changes and commit • Push new commits to central repository • Manage Conflicts
25. John works on his feature Mary works on her feature John Publishes his feature Mary tries to publish her feature Mary Rebases and Resolves conflicts Mary publishes the feature
26. Forking workflow
27. Steps 1. A developer 'forks' an 'official' server-side repository. This creates their own server-side copy. 2. The new server-side copy is cloned to their local system. 3. A Git remote path for the 'official' repository is added to the local clone. 4. A new local feature branch is created. 5. The developer makes changes on the new branch. 6. New commits are created for the changes. 7. The branch gets pushed to the developer's own server-side copy. 8. The developer opens a pull request from the new branch to the 'official' repository. 9. The pull request gets approved for merge and is merged into the original server-side repository
28. Feature Branching
29. Steps • Start with the master branch • Create a new-branch • Push feature branch to remote • Update, add, commit, and push changes • Push feature branch to remote • Resolve feedback • Merge your pull request
30. Example
31. Git Flow Workflow
32. The overall flow of Gitflow is: • A develop branch is created from master • A release branch is created from develop • Feature branches are created from develop • When a feature is complete it is merged into the release branch • When the release branch is done it is merged into develop and master • If an issue in master is detected a hotfix branch is created from master • Once the hotfix is complete it is merged to both develop and master
33. Things to keep in mind when choosing workflow • Short-lived branches • Minimize and simplify reverts • Match a release schedule
34. References • https://www.atlassian.com/git/tutorials • https://images.google.com
35. Questions?