banching can change your life
TRANSCRIPT
Branching can change your lifeworking in contexts, a world without branches, branches to the rescue
Branching can change your life• using branches in your day-to-day work might very well prove
to make you a better programmer or designer.
• if you're coming from another version control system, please forget the things you already know about branching & merging.
• git's concepts in this area are absolutely unique when it comes to ease of use and performance.
Working in contexts• In every project, there are always multiple different contexts
where work happens.
• Each feature, bugfix, experiment, or alternative of your product is actually a context of its own: it can be seen as its own "topic", clearly separated from other topics.
identifying real life contexts• while you're preparing 2 new variations of your application design (context 1 & 2)...• you're also trying to fix an annoying bug (context 3).• on the side, you also update some content on your FAQ pages (context 4), while...• one of your teammates is working on a new feature for your database (context 5),…• and another colleague is experimenting with a whole new login functionality (context 6).
A world without branches• Not working in clearly separated contexts can (and
sooner or later will) cause several problems• Things will start to get very confusing when you try to
handle multiple topics in a single context.
workflow on one centralised repo
1. Vlad starts to work on an issue 2. Melisa starts to work on a feature 3. Vlad pushes work 4. Melisa can’t push and has to pull in order to resync
5. Melisa starts finishes pull and merges changes 6. Melisa is ready to push again 7. Melisa finally pushes work
Branches to the rescue• branches are what we need to solve these problems• a branch represents exactly such a context in a project and helps you
keep it separate from all other contexts• all the changes you make at any time will only apply to the currently
active branch; all other branches are left untouched.
workflow on one centralised repo with branches
1. Vlad starts to work on an issue 2. Melisa starts to work on a feature 3. Vlad pushes work to it’s branch 4. Melisa pushes work to it’s branch
5. Integrator merges changes to the main branch when things are stable
Workflows• there are multiple possibilities when it comes to working with
git. • the array of possible workflows can make it hard to know
where to begin when implementing Git in the workplace.
Centralised Workflow
Gitflow Workflow
Feature branch Workflow
Forking Workflow
Centralised Workflow
1. Vlad starts to work on an issue 2. Melisa starts to work on a feature 3. Vlad pushes work 4. Melisa can’t push and has to pull in order to resync
5. Melisa starts finishes pull and merges changes 6. Melisa is ready to push again 7. Melisa finally pushes work
Feature Branch Workflow• The Feature Branch Workflow still uses a central repository, and
master still represents the official project history. But, instead of committing directly on their local master branch, developers create a new branch every time they start work on a new feature. Feature branches should have descriptive names, like animated-menu-items or issue-#1061. The idea is to give a clear, highly-focused purpose to each branch.
Gitflow Workflow• is derived from Vincent Driessen at nvie.• still uses a central repository as the communication hub for all
developers. And, as in the other workflows, developers work locally and push branches to the central repo. The only difference is the branch structure of the project.
Forking Workflow• The Forking Workflow is fundamentally different than the other workflows
discussed in this tutorial. 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.
• The main advantage of the Forking Workflow is that contributions can be integrated without the need for everybody to push to a single central repository.
Golden rules of version control1. Commit related changes2. Commit often3. Write good commit messages4. Use branches 5. Test code before you commit6. Never commit half-done work7. Never amend published commits8. Version control is not a backup system 9. Agree on a workflow
“don’t hesitate to forward your questions”Thanks!
email: [email protected]
Vlad Vesawebsite: http://www.vladvesa.roSW Developer & Tech enthusiast