Key/Command | Description |
---|---|
Tab | Auto-complete files and folder names |
Ctrl + A | Go to the beginning of the line you are currently typing on |
Ctrl + E | Go to the end of the line you are currently typing on |
Ctrl + U | Clear the line before the cursor |
Ctrl + K | Clear the line after the cursor |
Ctrl + W | Delete the word before the cursor |
Ctrl + T | Swap the last two characters before the cursor |
// Reference: http://lea.verou.me/2011/10/easily-keep-gh-pages-in-sync-with-master/ | |
$ git add . | |
$ git status // to see what changes are going to be commited | |
$ git commit -m 'Some descriptive commit message' | |
$ git push origin master | |
$ git checkout gh-pages // go to the gh-pages branch | |
$ git rebase master // bring gh-pages up to date with master | |
$ git push origin gh-pages // commit the changes |
Here's a little walkthrough of how Yannick and I are using feature branches and pull requests to develop new features and adding them to the project. Below are the steps I take when working on a new feature. Hopefully this, along with watching the process on Github, will serve as a starting point to having everyone use a similar workflow.
Questions, comments, and suggestions for improvements welcome!
When starting a new feature, I make sure to start with the latest and greatest codebase:
git checkout master
## How to hide API keys from github ## | |
1. If you have already pushed commits with sensitive data, follow this guide to remove the sensitive info while | |
retaining your commits: https://help.github.com/articles/remove-sensitive-data/ | |
2. In the terminal, create a config.js file and open it up: | |
touch config.js | |
atom config.js |
Just migrated it from Codepen.io to markdown. Credit goes to David Conner.
Working with DOM | Working with JS | Working With Functions |
---|---|---|
Accessing Dom Elements | Add/Remove Array Item | Add Default Arguments to Function |
Grab Children/Parent Node(s) | Add/Remove Object Properties | Throttle/Debounce Functions |
Create DOM Elements | Conditionals |
I wrote about how to write a great pull request on my blog
This is always helpful as a way to connect the different methods of communication that your company uses within your Product Development teams.
A description of the ticket, explaining potential changes in the code or away from the original intent of the story
This may be a synthesis of offline discussions you had surrounding the code you wrote. It could include what decisions were made, or realizations come to surrounding necessary codebase changes.
import React, { Component } from 'react'; | |
import { ScrollView, TextInput, button, form,} from 'react-native'; | |
import { InputText, InputCountrySelector, InputSwitch } from 'react-native-input-list'; | |
//add Image below | |
import { StyleSheet, Text, View, TouchableOpacity, Alert, Image } from 'react-native'; | |
// changes |