All of the following information is based on go version go1.17.1 darwin/amd64.
| GOOS | Out of the Box |
|---|---|
aix |
✅ |
android |
✅ |
warning: ignoring broken ref refs/remotes/origin/HEAD
➜ ✗ g symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/develop
➜ ✗ g fetch --prune
➜ ✗ g gc
| import { NgModule } from '@angular/core'; | |
| import { BrowserModule } from '@angular/platform-browser'; | |
| import { SafeHtmlPipe } from "./pipes" | |
| @NgModule({ | |
| declarations: [ | |
| SafeHtmlPipe, |
I've been asked a few times over the last few months to put together a full write-up of the Git workflow we use at RichRelevance (and at Precog before), since I have referenced it in passing quite a few times in tweets and in person. The workflow is appreciably different from GitFlow and its derivatives, and thus it brings with it a different set of tradeoffs and optimizations. To that end, it would probably be helpful to go over exactly what workflow benefits I find to be beneficial or even necessary.
| # Hello, and welcome to makefile basics. | |
| # | |
| # You will learn why `make` is so great, and why, despite its "weird" syntax, | |
| # it is actually a highly expressive, efficient, and powerful way to build | |
| # programs. | |
| # | |
| # Once you're done here, go to | |
| # http://www.gnu.org/software/make/manual/make.html | |
| # to learn SOOOO much more. |
This specification is inspired by and supersedes the [AngularJS commit message format][commit-message-format].
We have very precise rules over how our Git commit messages must be formatted. This format leads to easier to read commit history.
Each commit message consists of a header, a body, and a footer.
These rules are adopted from the AngularJS commit conventions.