Vladimir Ovsyannikov vlad-ovsyannikov

Squashing Git Commits

The easy and flexible way

This method avoids merge conflicts if you have periodically pulled master into your branch. It also gives you the opportunity to squash into more than 1 commit, or to re-arrange your code into completely different commits (e.g. if you ended up working on three different features but the commits were not consecutive).

Note: You cannot use this method if you intend to open a pull request to merge your feature branch. This method requires committing directly to master.

Switch to the master branch and make sure you are up to date:

Jenkins, Protractor and Headless Chrome Browser Setup on Ubuntu 14.04

Update Ubuntu

sudo apt-get update
sudo apt-get upgrade

Install Java

Comprehensive Introduction to @ngrx/store

By: @BTroncone

Also check out my lesson @ngrx/store in 10 minutes on egghead.io!

Update: Non-middleware examples have been updated to ngrx/store v2. More coming soon!

GitHub for Bug Bounty Hunters

GitHub repositories can disclose all sorts of potentially valuable information for bug bounty hunters. The targets do not always have to be open source for there to be issues. Organization members and their open source projects can sometimes accidentally expose information that could be used against the target company. in this article I will give you a brief overview that should help you get started targeting GitHub repositories for vulnerabilities and for general recon.

Mass Cloning

You can just do your research on github.com, but I would suggest cloning all the target's repositories so that you can run your tests locally. I would highly recommend @mazen160's GitHubCloner. Just run the script and you should be good to go.

$ python githubcloner.py --org organization -o /tmp/output

	sudo: required #is required to use docker service in travis

	language: php #can be any language, just php for example

	services:
	- docker # required, but travis uses older version of docker :(

	install:
	- echo "install nothing!" # put your normal pre-testing installs here

	# Reference: https://www.exclamationlabs.com/blog/continuous-deployment-to-npm-using-gitlab-ci/

	# GitLab uses docker in the background, so we need to specify the
	# image versions. This is useful because we're freely to use
	# multiple node versions to work with it. They come from the docker
	# repo.
	# Uses NodeJS V 9.4.0
	image: node:9.4.0

	# And to cache them as well.

	// inspiration: https://dribbble.com/shots/4370657-Share-Your-Feedback

	import React, { Component, Fragment } from "react";
	import { Animated, StyleSheet, Text, View, TouchableOpacity, Dimensions, Platform, Easing, TextInput, KeyboardAvoidingView, Image } from "react-native";
	import FontAwesome5 from 'react-native-vector-icons/FontAwesome5';

	const { width: windowWidth } = Dimensions.get('window');

	const Icon = (props) => <FontAwesome5 {...props} />

	(function (root, factory) {
	if ( typeof define === 'function' && define.amd ) {
	define([], factory(root));
	} else if ( typeof exports === 'object' ) {
	module.exports = factory(root);
	} else {
	root.myPlugin = factory(root);
	}
	})(typeof global !== "undefined" ? global : this.window \|\| this.global, function (root) {

-# delete local tag '12345'
-git tag -d 12345
-# delete remote tag '12345' (eg, GitHub version too)
-git push origin :refs/tags/12345
-# alternative approach
-git push --delete origin tagName
-git tag -d tagName

	# Solution found here: http://stackoverflow.com/questions/134882/undoing-a-git-rebase

	# The easiest way would be to find the head commit of the branch as it was immediately before the rebase started in the reflog...
	git reflog
	# and to reset the current branch to it (with the usual caveats about being absolutely sure before reseting with the --hard option).

	# Suppose the old commit was HEAD@{5} in the ref log
	git reset --hard HEAD@{5}