These videos should get you up to speed with the shell if you feel you are struggling.
- How To Use Shell Environment Variables - DistroTube
- Bash and the Terminal for Absolute Noobs - Luke Smith <- This Will be super helpful if you feel like you are starting from 0
- Bash commands to not look dumb at the Interview... - Luke Smith <- Useful tips and tricks for the command line. Some of these may be linux specific but most are applicable to MacOS
A good place to look for hints about bash scripting is devhints
A key part of your shell is its configuration file. The name of the file differs from shell to shell but for zsh you generally are looking for .zshrc and .bashrc for bash. You may see or hear about other files being used, below is a quick breakdown of the meaning of them for bash
FILES
/bin/bash
The bash executable
/etc/profile
The systemwide initialization file, executed for login
shells
~/.bash_profile
The personal initialization file, executed for login
shells
~/.bashrc
The individual per-interactive-shell startup file
~/.bash_logout
The individual login shell cleanup file, executed when a
login shell exits
~/.inputrc
Individual readline initialization file
Taken from the bottom of the bash man page
The same for zsh can be found in its man page. Access man pages with the command man and scroll with your arrow keys (or hjkl if you use vim ;) )
Here is my .zshrc with annotations so its a little more understandable.
# Lines configured by zsh-newuser-install
HISTFILE=~/.histfile # <- defines where the file containing your shell history is stored
HISTSIZE=1000 # <- how big in KB(?) the history file can be
SAVEHIST=1000 # <- related to above
setopt autocd extendedglob nomatch # <- autocd: cd into a directory by just typing it, extendedglob: use extended glob matching (sort of an advanced topic feel free to ignore it), nomatch: remove the no matches found error when globing
unsetopt beep notify # <- turn of the really anoying terminal bell
# End of lines configured by zsh-newuser-install
# The following lines were added by compinstall
zstyle :compinstall filename '/home/m0on/.zshrc' # <- makes sure my zshrc complies with zsh style
autoload -Uz compinit # v
compinit # <- Load and start the command completion engine (tab complete)
# End of lines added by compinstall
export PATH=$PATH:$HOME/.local/bin # <- Append ~/.local/bin to my path
autoload -U colors && colors # <- Load colors
PS1="%B%{$fg[red]%}[%{$fg[yellow]%}%n%{$fg[green]%}@%{$fg[blue]%}%M %{$fg[magenta]%}%~%{$fg[red]%}]%{$reset_color%}$%b " # <- Make the command prompt look a bit cooler
stty stop undef # Disable ctrl-s to freeze terminal.
setopt interactive_comments # Allow comments in the command lineHomebrew is a package manager, a foreign concept to windows users. Basically it is a repository of software that you can install, remove, or update in a single command.
The first step in using homebrew is installing it. There are plenty of internal documents on doing this so I wont share here.
Once it is installed you can check brew is functioning just by typing brew.
Now that you have brew installed you can install something.
First find some software to install. Golang is a good idea to get started.
To find if go is in the homebrew repos you can search with brew search go. You should see some casks and some formulae, casks in this case are homebrew package definition that installs macOS native applications, formulae are scripts to install a program. So we look for go in the list.
Now that we have verified that go is avaliable we can run brew install go to have brew install the latest and greatest version of go. For specific versions you can use brew install <package>@<version> where version is the semantic version (Dont worry to much as to what semantic versioning is at the moment).
Uninstalling is just as simple as installing brew uninstall go.
To update go you can use brew upgrade go, replace go with any package you might want to update. To tell homebrew what can be updated run brew update
Git is a decentralized source code management program developed my Linus Torvalds, the same guy that came up with the Linux kernel. The linux kernel project has hundereds if not thousands of commits so as you can imagine it was built to handle many users working colaboratively yet independantly. For this to work there are a few concepts you need to understand.
The first concept to familiarise yourself with is a repository or repo. A repo stores your code as well as all changes and commits made to it. The key advantage of source code management systems is that they allow you to roll back changes and see where they came from. A repo stores all of that data.
The next complimentary concept is a commit. To put changes into your git repo you need to make commits. Commits describe where what and when something changed and are usually accompanied by a message describing the changes. Commit messages are deemed optional by git itself but that is to be disregarded, always write descriptive commit messages. Commits are labled by a SHA1 hash that is unique to the change, allowing them to be located and indexed easily. In an ideal world as you work you should commit what you change, for example as you make changes between files you should commit the changes that you have made in one file before moving to the next.
Branches are essential, they facilitate the collaborative nature of git. A branch is described as a "diverge[ence] from the main line of development and continue to do work without messing with that main line". Typically when you start working on a change you create a branch to implament your changes. Once you are done working the changes are merged back into the branch you diverged from.
A good acompanyment to branches are Pull Requests, sometime called merge requests or PRs. Whilst one can merge branches themselves the polite and propper thing to do is to notify the repo owner of your changes with a merge reqest. Here an owner/maintainer can check what your changes do, their quality, and weather they break existing code. If all is good the changed will be pulled/merged into the branch you broke off from. Usually the central branch of a git repo is called the master branch but with the move to more inclusive language you may also see it as the main branch.
If you want to see what a list of commits looks like and one of the ways git shows them look at the revisions tab in the top left
The best git reference there is
git clone <repo url>After which you can cd into the new directory created by the clone. Now you need to create a branch with the command
git checkout -b <name of feature>Its time to do some programming. Implament your changes and commit as you go. Commits happen in a few steps. First add the code to your commit. -A will add all changes found or you can add specific files by filename
git add <filenames|-A>Then you can use this command to actually commit the changes to git
git commit -m "Commit message describing your changes goes here"Once all your changes are made and you are ready to submit a pull request you can push your branch with
git push origin <branch name>After your branch is pushed you can create a merge request in the web-ui for the git server to create a pull request. Some servers will propt you to do this making the process super easy.
If you are working on open source project the workflow is slightly different, you should fork the repo before you clone it and submit your merge requests from there. The forking practice is best kept to open source, not internal repos
Git is specifically for source code, make sure you don't commit builds or any other files that arent needed/included under soure.
To mittigate commiting non-source files a lot of repos have a .gitignore file which outlines what files and folders can be commited.
If you need version tracking on large files or want a git like way to store large files look into git large file storage or gitlfs.
Occationally youll make a mistake with git (as well all do ;) ) so heres a quick reference on some fixes
If you have accidentally comitted something you shouldn't have you have two options:
git reset --hard HEAD~1This moves back to the commit before current and deletes any changes you have in the current repo.
Learning how to use git stash can be useful to keep your changes but delete a commit.
Your other option is to search for the commit hash you want to roll back to with
git logthen
git reset --hard <sha1-commit-id>If youve really messed up and pushed the bad commit use
git push origin HEAD --forceClean Code - Uncle Bob - Clean code lectures from the one of the guys that popularized agile and clean code (genuinely a very worthwhile watch)