GIT branch
A branch is a pointer for a particular commit.
So when you do a git branch, the new branch and master points to the same branch at inception.
You will branch from the commit you are on.
Fixing Errors or Deleting branches after merge:
(You should do it so that you don’t have to spring clean much later)
Cannot delete branch you are on
git branch -d <new branch name> (delete only if merged)
git branch -D <new branch name> (force delete branch)
How to merge feature branch to master:
git pull -r (from feature branch)
git checkout -b <branch name>
DEVELOP
git pull -r origin master
git checkout master
git merge <branch>
git push origin master
git branch -d <branch>
Avoid 3-way merge
(Rebase is a fast-forward merge, that means the pointer would include all the previous commits of the pointer you are rebasing from and add your own commits after)
Rebase keeps your tree clean and straight.
If you do git merge <branch name>, you would create a 3-way merge
Fixing errors on rebase/ merge: (Before pushing)
git reset –hard ORIG_HEAD
force reset
Notes:
GUI for GIT is a convenience, and devs should learn the CL commands first
GIT UI – GitKraken
To avoid merge conflicts:
If you are trying to merge the local branch to master, do a git pull -r first then merge
Resources:
git flight rules
learn git branching
User Stories vs Requirements
User-centric, as opposed to feature-centric
As a… I want to… so that…
Goes into who, how and why
User stories create vertical slices (but your team needs to be full-stack).
For eg, withdrawing cash (from a bank app) might be one feature, but would involve FE, BE and DB.
| Letter | Meaning | Description |
|---|---|---|
| I | Independent | The PBI should be self-contained, in a way that there is no inherent dependency on another PBI. |
| N | Negotiable | PBIs are not explicit contracts and should leave space for discussion. |
| V | Valuable | A PBI must deliver value to the stakeholders. |
| E | Estimate-able | You must always be able to estimate the size of a PBI. |
| S | Small | PBIs should not be so big as to become impossible to plan/task/prioritize within a level of accuracy. |
| T | Testable | The PBI or its related description must provide the necessary information to make test development possible. |
Acceptance criteria
It defines boundaries for a user story.
AC formats: checklist, given > when > then
Cover all bases: Positive + negative scenarios, UX concerns, functional and performance concerns
Avoid scope creep: Don’t add ACs in that doesn’t fit with the user story card.
Short and simple (checklist is better for it)
Note
Don’t follow philosophies and methodologies blindly. Best practices are the ones adapted to your situation.
Stuff I Have Learnt 