Worst Practices for version control Smit Thakkar 

README.md ● Chief Architect at Corridor Funds ● Contributor at: FossAsia, Gluster and NgUI ● Github: https://github.com/smitthakkar96 ● Email: [email protected] 

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. 

No content

ME 

No content

Version control everything….. 

● Version control only the source code ● Use .gitignore 

No content

Commit messages are for losers 

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). 

Committing broken code to main branch 

Committing code with console logs and old commented code 

Committing unrelated changes 

Committing directly to master 

Big monolithic Repository 

The “fix previous commit” commit 664e6ac (HEAD, master) Fix one line in verification method (4 minutes ago) 3945ef1 Add verification method (5 minutes ago) 

Solution: git commit --amend 

No content

What is rebase? ● It is a powerful tool capable of modifying git history ● Enables developers to squash, delete and change order of commits 

Unorganized workflows 

Git Workflows ● Centralized Workflow ● Forking Workflow ● Feature branching ● Gitflow workflow 

Centralized Workflow 

Centralized Workflow Process ● Initialize the central repository ● Clone the central repository ● Make changes and commit ● Push new commits to central repository ● Manage Conflicts 

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 

Forking workflow 

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 

Feature Branching 

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 

Example 

Git Flow Workflow 

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 

Things to keep in mind when choosing workflow ● Short-lived branches ● Minimize and simplify reverts ● Match a release schedule 

References ● https://www.atlassian.com/git/tutorials ● https://images.google.com 

Questions?