- Explain what SDLC is and why we use it
- Provide a general overview of what "Agile" means and compare it to Waterfall
- Explain what SCRUM is, and how it relates to agile.
- Describe the process of requirements gathering.
- Explain what a user story is, and what specific points it should include.
There are many Git workflows out there, I heavily suggest also reading the atlassian.com [Git Workflow][article] article as there is more detail then presented here.
The two prevailing workflows are [Gitflow][gitflow] and [feature branches][feature]. IMHO, being more of a subscriber to continuous integration, I feel that the feature branch workflow is better suited.
When using Bash in the command line, it leaves a bit to be desired when it comes to awareness of state. I would suggest following these instructions on [setting up GIT Bash autocompletion][git-auto].
When working with a centralized workflow the concepts are simple, master
represented the official history and is always deployable. With each now scope of work, aka feature, the developer is to create a new branch. For clarity, make sure to use descriptive names like transaction-fail-message
or github-oauth
for your branches.
# [<tag>] (If applied, this commit will...) <subject> (Max 72 char) | |
# |<---- Preferably using up to 50 chars --->|<------------------->| | |
# Example: | |
# [feat] Implement automated commit messages | |
# (Optional) Explain why this change is being made | |
# |<---- Try To Limit Each Line to a Maximum Of 72 Characters ---->| | |
# (Optional) Provide links or keys to any relevant tickets, articles or other resources | |
# Example: Github issue #23 |