See how a minor change to your commit message style can make you a better programmer.
Format: <type>(<scope>): <subject>
<scope> is optional
| echo '.env' >> .gitignore | |
| git rm -r --cached .env | |
| git add .gitignore | |
| git commit -m 'untracking .env' | |
| git push origin master |
| //dijkstra solve graph starting at s | |
| function solve(graph, s) { | |
| var solutions = {}; | |
| solutions[s] = []; | |
| solutions[s].dist = 0; | |
| while(true) { | |
| var parent = null; | |
| var nearest = null; | |
| var dist = Infinity; |
If you use git on the command-line, you'll eventually find yourself wanting aliases for your most commonly-used commands. It's incredibly useful to be able to explore your repos with only a few keystrokes that eventually get hardcoded into muscle memory.
Some people don't add aliases because they don't want to have to adjust to not having them on a remote server. Personally, I find that having aliases doesn't mean I that forget the underlying commands, and aliases provide such a massive improvement to my workflow that it would be crazy not to have them.
The simplest way to add an alias for a specific git command is to use a standard bash alias.
# .bashrcThe Linux kernel is written in C, so you should have at least a basic understanding of C before diving into kernel work. You don't need expert level C knowledge, since you can always pick some things up underway, but it certainly helps to know the language and to have written some userspace C programs already.
It will also help to be a Linux user. If you have never used Linux before, it's probably a good idea to download a distro and get comfortable with it before you start doing kernel work.
Lastly, knowing git is not actually required, but can really help you (since you can dig through changelogs and search for information you'll need). At a minimum you should probably be able to clone the git repository to a local directory.