You're about to create your best presentation ever

Branching Powerpoint Template

Create your presentation by reusing a template from our community or transition your PowerPoint deck into a visually compelling Prezi presentation.


Transcript: Branching ODM Proposal Version Control A way to write code without affecting the rest of your team Merge branches to integrate your changes Version Control - Branching Version Control with git - Recall Why use branching? So you can push unstable code Work independently Still use remote version control Only merge stable/functioning code What if everyone pushes to the same branch? Why use branching? Without Branching - Scenario All team member push to master Susan is updating the backend Will take weeks Stable when complete Intermediate changes have unpredictable consequences elsewhere John is making changes to the frontend Sees side effects caused by Susan’s pushes Thinks his code caused the changes Without Branching - Scenario Tempting solution Don’t push to the remote repo until all changes are complete Changes only exist locally during development One hard drive error away from losing weeks of work! If there are 10+ developers with different tasks on the same codebase? Complex interactions between modules can multiply issues Without Branching - Scenario Someone pushes code with errors Code breaks Who broke it? Everyone’s workflow halts and the search begins It happens All code functions locally Combined pushes doesn’t contains error ex: A function header is changed Without Branching – Worse Scenario Without Branching - Worse Scenario Branching New commits are only added to the current branch Can implement experimental code without affecting others When the life of the branch is over Merge it into the primary codebase Branching is crucial on large teams Branching Branching in git git checkout –b <newBranchName> Creates branch off of current branch Equivalent to: git branch <newBranchName> git checkout <newBranchName> Alternatively Create a branch in GitHub git checkout <branchName> Branching in git Merging Once the changes are complete and stable Merge the branch back to the codebase Typically: Initiate a pull request If your team performs code reviews It will likely happen here Choose how to merge the code Conflict resolution can be time consuming Helps to coordinate with your team and limit editing the same files Merging A Branching Model A suggested method for branching A Branching Model Master and Develop The two primary branches Master is the default branch in git Use for stable releases Create develop branch Use for untested code Primary working branch for the team Contains the latest features Close to a release Test develop branch for stability Merge commits in develop into master Test and release master Continue to code on develop through the release Master and Develop Feature Branch Branch off of develop Primary working branches for an individual(s) When new feature is finished Merge into develop Code reviews (If applicable) Hope it doesn’t break develop (it might) nightly builds to find out Temporary branches Can be many feature branches being developed in parallel If the feature is a failure Delete the branch without merging into develop Feature Branch Merging To retain branch information git merge --no-ff no fast-forward With fast-forward Existence of the branch is lost Without meaningfully tagging commit messages Looking through history is confusing Especially with many features developed in parallel Merging Hotfixes Production release contains a bug Create a hotfix branch from master Fix the bug Merge fix into: Next production release Develop Hotfixes Release Branch Branch off develop when approaching a release No features added Extensive testing and bug fixes Merge all changes back to develop When confidently stable Merge into master as a release Release Branch Versioning Tag the current state of the code Can easily work with a previous version if needed Use versioning on master Versioning

Now you can make any subject more engaging and memorable