Git

https://github.com/git-tips

git fetch origin && git reset --hard origin/master && git clean -f -d

config

git config --list
git config --global user.name "mckenatim"

ignore and delete from the past

.gitignore the file you want to hide from now on

node_modules/
bower_components
jspm_package
env.json

do this command with path to file you want to get rid of in all history

git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch env.json' \
--prune-empty -- tag-name-filter cat -- --all

git push origin --force --all
git push origin --force --tags

submodules

for repositories that have things like server @ d9c02a2 with a double folder icon, from the root directory of the repo do

submodule update --init

to pull the submodule in

tagging a commit

git tag 0.0.1
git push--tags

to list tags

git tag

to go back to tagged code... If you are in the midst of changes you haven't committed then `git stash` them before you ...

git stash
git checkout tagname

then to get back to where you were

git checkout master
git stash apply

Node package manager

updating gulp gyp jsdom

So a quick solution for all node-gyp issues around some of the packages in which is thrown, is to update all those packages with:

$ npm install -g npm-check-updates
$ npm-check-updates -u
$ npm install

from egghead series https://egghead.io/series/how-to-write-an-open-source-javascript-library https://github.com/kentcdodds/starwars-names.git

versioning

1.0.0 is typical with the major release number getting changed any time the api changes. Adding features would change the second digit and bug fixes would change the last digit.

process

modify package.json to new version, say 1.1.0

git add . -A
git commit -m 'about new version'
git push
git tag 1.1.0
git push --tags
npm publish

beta process

from current version, say 1.3.0 to add a beta feature bump the version to 1.4.0-beta.0

modify package.json to new version, say 1.4.0-beta.0

git add . -A
git commit -m 'about new beta version'
git push
git tag 1.4.0-beta.0
git push --tags
npm publish --tag beta

testing

mocha

• https://glebbahmutov.com/blog/testing-reactive-code/

regression testing

Regression testing is a type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes such as enhancements, patches or configuration changes, have been made to them. The purpose of regression testing is to ensure that changes such as those mentioned above have not introduced new faults. One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software. Regression tests can be broadly categorized as functional tests or unit tests. Functional tests exercise the complete program with various inputs. Unit tests exercise individual functions, subroutines, or object methods

Contrast with non-regression testing (usually validation-test for a new issue), which aims to verify whether, after introducing or updating a given software application, the change has had the intended effect.

http://jsfiddle.net/fdietz/2Ny8x/

npm install mocha chai --save-dev

  same as
npm i -D mocha chai

create a test file src/index.test.js

 var expect = require('chai').expect;
 var starWars = require('./index');
 describe('starwars-names', function() {
   describe('all', function() {
     it('should be an array of strings', function() {
       expect(starWars.all).to.satisfy(isArrayOfStrings);
       function isArrayOfStrings(array) {
         return array.every(function(item) {
           return typeof item === 'string';
         });
       }
     });
     it('should contain `Luke Skywalker`', function() {
       expect(starWars.all).to.include('Luke Skywalker');
     });
   });
   describe('random', function() {
     it('should return a random item from the starWars.all', function() {
       var randomItem = starWars.random();
       expect(starWars.all).to.include(randomItem);
     });
   });
 });

change package.json to run tests (automatically on update -w)

 "scripts": {
   "test": "mocha src/index.test.js -w"
 },

 npm test

on cloning from a prior commit

first - branch from prior commit

You can create the branch via hash,

git branch branchname <sha1-of-commit>

or by using a symbolic ref.

git branch branchname HEAD~3

second - clone that branch

mkdir $BRANCH
cd $BRANCH
git init
git remote add -t $BRANCH -f origin $REMOTE_REPO
git checkout $BRANCH

git

git branch feature (create) git checkout feature (swithc to) git push origin feature

git checkout master git merge feature

if someone has changed a repository and pushed it up and then someone else tries to push they can't. They first need to pull and merge. If they tried to modify the same file then you may need to manually merge, resolve and push.

git pull = fetch + merge and is shortcut for pull origin master

always commit before merge and pull

head is latest commited version on your machine

head

head orig

http://mckennatim.github.com/mckennatim

the gh_page index.html is in pathboston.com/mckennatim/mckennatim. Go all the way there you should see

root@10.0.1.20: mckennatim$ (gh-pages *)  git add .
root@10.0.1.20: mckennatim$ (gh-pages +)  git commit -m "appmkt"
[gh-pages 1e8feac] appmkt
 1 files changed, 3 insertions(+), 1 deletions(-)
root@10.0.1.20: mckennatim$ (gh-pages)  git push
Counting objects: 5, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 437 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
To git@github.com:mckennatim/mckennatim.git
   bfd5b64..1e8feac  gh-pages -> gh-pages
root@10.0.1.20: mckennatim$ (gh-pages)

the work flow

The idea is to have production code on server and then a copy of that code locally. That copy has a branch that you can try fixes in. When the fixes are working well locally you can try them on the server from the same branch. When they are ready to go live you can merge the branch with the master locally, push it to github and fetch from github to the server where you merge the github master into the server master.

the setup

by cloning from github

Started by cloning code on your local machine(which creates a remote named 'origin')

$ git clone git@github.com:mckennatim/OBsoup.git

Then create a branch for putting new features:

$ git checkout -b loco
Switched to a new branch 'loco'

starting on a local drive

To make your current directory a Git repository we simply run init.

git init
git add .
git commit -m "initial commit"

Create a new repository on GitHub. It will tell you something like the following

 cd existing_git_repo
 git remote add origin git@github.com:mckennatim/food2buy.git
 git pull origin master //I think this just gets Read.me
 git push -u origin master

Enter passphrase for key '/c/Users/tim/.ssh/id_rsa': nj.

=remove sensitive data (doesn't work)

tekkub@iSenberg ~/tmp/github-gem master
$ echo "Rakefile" >> .gitignore

tekkub@iSenberg ~/tmp/github-gem master*
$ git add .gitignore

tekkub@iSenberg ~/tmp/github-gem master+
$ git commit -m "Add Rakefile to .gitignore"
[master 051452f] Add Rakefile to .gitignore
 1 files changed, 1 insertions(+), 0 deletions(-)

normal test process

locally

do some editing locally on a (loco)branch and test locally then add. and commit locally

(loco)$git add .
(loco)$git commit -m "my local edits"

push that branch to github

(loco)$git push origin loco

server

If you changed or added files without using version control by mistake. (you get an error like "error: Untracked working tree file '.htaccess' would be overwritten by merge. Aborting")

 git clean -f

before fetch and merge

If you had an old loco branch get rid of it before you add another

 ssh -i .ssh/hpkey.pem root@107.21.243.191
 (master)$ git branch -D loco

try the local changes by fetching the github origin then fast-forward the server branch by

(master)$git fetch origin 
(master)$git merge origin/loco
(master)$git checkout loco
(loco) 

Now the server is running from the loco branch. If you want it running from the older master code

(loco)$git checkout master
(master)$

once new code is tested on server from (loco)

Decided the protocal is to start merging branch into master locally then pushing it to GitHub then fetching from Github to server and merging there.

locally

OK so the branch can merge into master locally

(local)$ git checkout master
(master)$ git merge loco

Then push it to github

(master)$ git push

server

Get the merged master from github and mege it with the servers master

(master)$git fetch origin 
(master)$git merge origin/master

cloning and then makeing it a new repository

1. Make a new repo on Github called SecondProject.
2. Locally clone your MyfirstProject, either from disk or from Github. git clone htt....git SecondProjectDirName
3. git remote set-url origin git@github.com:yourname/SecondProject.git
4. Push it.