vcarl

I bundled these up into groups and wrote some thoughts about why I ask them!

If these helped you, I'd love to hear about it!! I'm on twitter @vcarl_ or send me an email carl.vitullo@gmail.com

Onboarding and the workplace

https://blog.vcarl.com/interview-questions-onboarding-workplace/

• How long will it take to deploy my first change? To become productive? To understand the codebase?
• What kind of equipment will I be provided? Will the company pay/reimburse me if I want something specific?

jpierson

If you are like me you find yourself cloning a repo, making some proposed changes and then deciding to later contributing back using the GitHub Flow convention. Below is a set of instructions I've developed for myself on how to deal with this scenario and an explanation of why it matters based on jagregory's gist.

To follow GitHub flow you should really have created a fork initially as a public representation of the forked repository and the clone that instead. My understanding is that the typical setup would have your local repository pointing to your fork as origin and the original forked repository as upstream so that you can use these keywords in other git commands.

1. Clone some repo (you've probably already done this step)

   git clone git@github...some-repo.git

MohamedAlaa

tmux shortcuts & cheatsheet

start new:

tmux

start new with session name:

tmux new -s myname

CristinaSolana

1. Clone your fork:

git clone git@github.com:YOUR-USERNAME/YOUR-FORKED-REPO.git

2. Add remote from original repository in your forked repository:

cd into/cloned/fork-repo
git remote add upstream git://github.com/ORIGINAL-DEV-USERNAME/REPO-YOU-FORKED-FROM.git
git fetch upstream