Did you really `got Git? In this presentation for E-commerce at Scale meetup, I talk about why choose Git over other version control systems, Git Flows and also some very useful but not so popular Git features.
2. About me
Bruno Ricardo Siqueira
Brazilian, working as Senior Software
Developer at Smartbox, ~10 years of
software development experience, PHP
evangelist, Git lover, Rock N' Roll fan,
Sci-fi addicted, MTG hobbyist player.
brunoric.info
linkedin.com/in/brunoric
twitter.com/brunoric
github.com/brunoric
3. ● Motivation
○ Why your E-commerce system need a VCS?
○ Why Git?
● Git flows
○ Why use or create a flow?
○ Centralized workflow
○ Feature branch workflow
○ Gitflow workflow
○ Forking workflow
○ Dictator and lieutenants workflow
● Git features and tools
Agenda
13. Motivation - Why your E-commerce system need a VCS?
Conflict resolution
14.
15. Motivation - Why your E-commerce system need a VCS?
● Improve automation for daily tasks
● Avoid code loss
● Backup and restore strategy
● Prototyping
● Find when a specific bug or feature was introduced
● …
● Continuous integration and Continuous delivery
23. Git Flows - Why use or create a flow?
● With Git, branching and merging is cheap
● Flows bring history consistency
● Provide a logical way of reading the history
● Facilitate automation
● Facilitate new joiners ramp up
● Avoid mistakes (unintended pushes, merges, unmerged branches, etc)
● ...
25. Git Flows - Centralized workflow
● Like Subversion with
benefits:
○ developers have their
own local repository
○ Git branches are
fail-safe
○ Merge process is
painless
31. Git Flows - Centralized workflow
error: failed to push some refs to '/path/to/repo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.git push origin master
86. Git Flows - Credits and reference
● Tutorials, documentation and other presentations:
○ A successful Git branching model - Vincent Driessen:
http://nvie.com/posts/a-successful-git-branching-model
○ Atlassian Advanced Git Tutorials:
https://www.atlassian.com/git/tutorials/advanced-overview
○ Git - Distributed Workflows:
https://git-scm.com/book/it/v2/Distributed-Git-Distributed-Workflows
○ Git - Get Ready To Use It
http://www.slideshare.net/origamiaddict/git-get-ready-to-use-it
○ Git Tower:
https://www.git-tower.com/learn/git/ebook/en/command-line/appendix
/from-subversion-to-git
Changes made by many individuals over development process. Creation and deletion of files. File changes. Different VCS tools differ on how well they handle the history. Usually includes the author, date and written notes. If the software is being actively worked on, almost everything can be considered an "older version" of the software.
You can find when and who introduced any change. This is important to know more about the context of the code change.
Branching and merging possibilities parallel work in an organized way. Different people can work in the same codebase supported by tools that will help you in reusing the code for another purpose (branching) and insert back you modifications (merging).
A very important part is conflict resolution. With different people working in the same codebase, conflicts will happen for sure. You need tooling for solve this problem in an efficient way.
Deploy. Code loss by moving files or wrongly merging changes. You can easily make changes in your system. Having the complete history enables going back to previous versions to help in root cause analysis for bugs and it is crucial when needing to fix problems in older versions of software. CI and CD.
Git development began in April 2005, after many developers of the Linux Kernel gave up access to BitKeeper. The legend says that Linus Torvalds started the development in a weekend and in the same weekend Git was already using itself as version control system. Junio C Hamano is the current lead of Git project.
Unlike SVN, git provides the full repository locally instead of just a working copy.
Git staging area is an important concept. You work on your local repository, do your changes, stage them (git add), commit them (git commit) and publish them (git push).
First, it gives every developer their own local copy of the entire project. Unlike SVN, Git branches are designed to be a fail-safe mechanism for integrating code and sharing changes between repositories.
With this flow the goal is to have a linear history as much as possible.
John pushes his code to master.
But again, unlike Subversion, Git gives you the flexibility to branch out locally, as many as you want.
Mary also tries to push her changes.
The push is rejected.
Mary needs to update her local branch.
Mary pulls the remote changes. In Git, pull is an alias to git fetch and git merge, but with the --rebase option it's a git fetch and git rebase.
With the rebase operation, the changes made by Mary will be applied on top of John's code.
If the code has any conflicts those need to be solved and staged before continuing the rebase process. Everything is done locally, so to publish your changes you will need to push them.
Let's use Git as it was designed to be used, with decentralized contribution.
Branch out for a new feature.
Do implementations.
Finish implementations.
Push feature.
Feature is added to the main branch.
Pull latest changes from main repository.
Gitflow is a workflow proposed by Vincent Driessen in 2010. He was working at the time for nvie (now GitPrime), and they were using Gitflow as a branching model for internal projects. Gitflow is a strict framework for branching and merging using the concepts of the Feature workflow as base.
Historical Branches: Instead of a single master branch, this workflow uses two branches to record the history of the project. The master branch stores the official release history, and the develop branch serves as an integration branch for features. It's also convenient to tag all commits in the master branch with a version number.
Features branches: Each new feature should reside in its own branch, which can be pushed to the central repository for backup/collaboration. But, instead of branching off of master, feature branches use develop as their parent branch. When a feature is complete, it gets merged back into develop. Features should never interact directly with master.
Release branches: Once develop has acquired enough features for a release, you branch out a release from develop. Creating this branch starts the next release cycle, so no new features can be added after this point - only bug fixes. Once it's ready to ship, the release gets merged into master and tagged with a version number. In addition, it should be merged back into develop, which may have progressed since the release was initiated.
Maintenance Branches: Maintenance or “hotfix” branches are used to quickly patch production releases. This is the only branch that should fork directly off of master. As soon as the fix is complete, it should be merged into both master and develop (or the current release branch), and master should be tagged with an updated version number.
Instead of using a single server-side repository to act as the “central” codebase, it gives every developer a server-side repository. This means that each contributor has not one, but two Git repositories: a private local one and a public server-side one. Very distributed!
As with any Git-based project, the first step is to create an official repository on a server accessible to all of the team members. Typically, this repository will also serve as the public repository of the project maintainer.
Next, all of the other developers need to fork this official repository. It’s possible to do this by SSH’ing into the server and running git clone to copy it to another location on the server—yes, forking is basically just a server-side clone.
Next each developer needs to clone their own public repository. They can do with the familiar git clone command. And also add the first created repo as the official upstream.
Developers do their local changes.
Developers publish their changes.
After publishing their changes, developers create pull requests and the project maintainer(s) analyse them.
With new pull requests accepted, developers needs to pull from the upstream.
Also called as Integration-Manager Workflow.
Used by Linux Kernel project. Various integration managers are in charge of certain parts of the repository; they’re called lieutenants. All the lieutenants have one integration manager known as the benevolent dictator. The benevolent dictator’s repository serves as the reference repository from which all the collaborators need to pull.