Tuesday, December 5, 2017

GIT Branching Model

Idea Extracted from this website as I had the liberty to learn from it and apply it to my personal projects as well as in some of the organizations I work for.

The details are summarized as follows:


Overall picture:




Main branches:

  • MASTER 
  • DEVELOP


We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state

We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”. This is where any automatic nightly builds are built from

When the source code in the develop branch reaches a stable point and is ready to be released, all of the changes should be merged back into master somehow and then tagged with a release number.

Other Branches

  • Feature branches
  • Release branches
  • Hotfix branches


Unlike the main branches, these branches always have a limited life time, since they will be removed eventually.

Feature:
May branch off from: develop Must merge back into: develop

Finished features may be merged into the develop branch to definitely add them to the upcoming release.

Release:
May branch off from: develop Must merge back into: develop and master
It is exactly at the start of a release branch that the upcoming release gets assigned a version number—not any earlier.
This new branch may exist there for a while, until the release may be rolled out definitely. During that time, bug fixes may be applied in this branch (rather than on the develop branch).

When the state of the release branch is ready to become a real release, some actions need to be carried out. First, the release branch is merged into master (since every commit on master is a new release by definition, remember). Next, that commit on master must be tagged for easy future reference to this historical version

Finally, the changes made on the release branch need to be merged back into develop, so that future releases also contain these bug fixes.

Hotfix:
May branch off from: master Must merge back into: develop and master

When finished, the bugfix needs to be merged back into master, but also needs to be merged back into develop, in order to safeguard that the bugfix is included in the next release as well. 

Saturday, December 2, 2017

React Redux Concepts

Redux is a tool for managing both data-state and UI-state in JavaScript applications.

Redux attempts to make state mutations predictable by imposing certain restrictions on how and when updates can happen.

Core principals:



  1. The state of your whole application is stored in an object tree within a single store.
  2. The only way to change the state is to emit an action, an object describing what happened.
  3. To specify how the state tree is transformed by actions, you write pure reducers. Reducers are just pure functions that take the previous state and an action, and return the next state. 


What React Solves:



Component to Component communication is hard in react, as data flows from top to bottom.




For communication between two components that don't have a parent-child relationship, you can set up your own global event system. ... Flux pattern is one of the possible ways to arrange this.


React solves the above problem by introducing a global store. Components then "dispatch" state changes to the store, not directly to other components. The components that need to be aware of state changes can "subscribe" to the store:


npm install --save redux react-redux