Follow these explicit steps for using git in a command line. This walks you through a complete cycle of completing a simple story), of a feature branching workflow using just a working dev and a topic branch. Uses fetch/merge not pull, and merge commits not rebasing. Assumes a local initiated git repo and a hosted remote repo of name "origin". A…

git-feature-branch-merge-steps.txt

Rachelle Gray
Git Feature Merging and Branching Workflow
	- indented numbered items are command line arguments
	- flush comments to give context

Follow these explicit steps for using git in a command line. This walks 
you through a complete cycle of completing a simple story), of a feature 
branching workflow using just a working dev and a topic branch. Uses 
fetch/merge not pull, and merge commits not rebasing. Assumes a local 
initiated git repo and a hosted remote repo of name "origin". Assumes 
some form of ticketing system. Does not include running automated 
tests. (Baby steps).

From your command line prompt, in the local repo directory,
on branch 'dev':
	1. git status
	2. git fetch
	3. git status

let's say there are changes on origin/dev
	4. git merge orgin/dev
	5. git status
all is good

Go to browser & update the ticket to 'in progress'
Back to command line:
checkout your new branch with a meaningful name:
that includes the ticket name-number and a couple-word description
	6. git checkout -b projectname-11-nav-fix

			(or, if the branch exists already, just
				6. git checkout projectname-11-nav-fix
				7. git merge dev
				8. git status
			it's all good
			)
	9. code your fix save file

Back at the command line. Now, what did I change again?
	10. git status
	11. git add .
Make your commit, using this handy subject/description syntax 
that allows multilines.
Commits with lines less than 80 characters long are easiest to read.
	12. git commit -m "Projectname-11 nav state fix:" -m "
	 - on all breakpoints, correct the link style rules to show a change in color
	 - update local state logic"

Feel satisfied.
		(
		depending on your situation, push to remote branch for review there
			12b. git push -u origin projectname-11-nav-fix
		)

Collect any updates that might have occured while you were in code cave.
	13 git checkout dev
	14. git fetch

let's say there are changes on origin/dev. Let's get them.
	15. git merge origin/dev
		(
			15b. git status
		all is good, continue
		)
Checkout your local branch so you can update it with dev's latest.
	16. git checkout projectname-11-nav-fix
	17. git merge dev
no problems, yay
do quick check in browser to verify everyone's changes show
		(
		depending on your situation, push to remote branch for review there
			17b. git push -u origin projectname-11-nav-fix
		do quick check in browser on remote site to verify everyone's changes show
		)
So close....
	18. git checkout dev
	19. git fetch
	20. git status
all good no changes

now bring your magic into your local dev branch!
	21. git merge projectname-11-nav-fix

Because, honestly, changes might have happened on origin in those 5 seconds--
	22. git fetch
	23. git status
But, thank goodness, not this time. 

Final scan in browser looks good.
Back in your terminal, release your code!
	24. git push origin dev

Finally,
if the looks good on dev.com,
update the ticket with `ready to test`,
(Prune those branches!)
and delete your fully merged topic branch both locally and from remote.

Now take a break away from the computer. Really.