Kate Hudson’s Flight Rules for Git borrows from NASA’s Flight Rules style. The result is a recipe-style collection of Git tips & tricks to get you out of a jam.
Still early days, but pretty cool tech coming from the team at Gitchain:
Gitchain is an application of the exciting ideas behind Bitcoin, Namecoin and DHT applied to Git hosting. Once you install it, it acts as a local proxy to the entire Gitchain P2P network.
I love seeing the Bitcoin protocol (perhaps the crypto-currency’s greatest virtue) applied to different domains.
Gogs looks like a nice, new (still in Alpha) option if you want to self-host some Git repositories with a web interface similar to GitHub’s.
It’s written purely in Go, so installation should be dead simple. From the README:
Gogs only needs one binary to setup your own project hosting on the fly!
There’s a lot of innovation (and iteration) going on in the online publishing space. GitBook continues that trend by offering a command line tool built specifically for creating programming book and exercises.
You write your book in Markdown and from that GitBook can generate a static website, PDF, eBook, and even JSON. Here’s what the results look like:
Touché. It’s on GitHub.
The only problem I see with gitsh is reversing years of Git muscle memory with
git appended to each command.
Git commands tend to come in groups. Avoid typing
gitover and over and over by running them in a dedicated git shell.
Our engineers were comfortable with Git and we preferred to stay with a familiar tool, so we took a long, hard look at improving it to work at scale. After much deliberation, we concluded that Git’s internals would be difficult to work with for an ambitious scaling project.
Instead, we chose to improve Mercurial.
Together, the hgwatchman and remotefilelog extensions have improved source control performance for our developers, allowing them to spend more time getting stuff done instead of waiting for their tools.
How many other organizations with large codebases will follow Facebook to drink the Mercurial water too? Facebook’s move to Mercurial should come as good news for Bitbucket as well.
Mercurial or Git? Tell us on Twitter.
Andrew and Adam talk with Sytse Sijbrandij, one of the Co-founders of GitLab, about building GitLab, sustaining open source, community management, and ways to handle a “road map” for your product or project.
The project home page includes a
screenshot, but you can also visit a project hosted on a
public facing installation
and can click around.
There are nice diff pages and you can also get a
The project is still very young, but looks promising.
GitPrep is written in Perl and it is very easy to install, even on a shared host. It can run
its own web server, use any web server supporting PSGI/Plack, and it can
even run in CGI mode for those shared hosts.
dotCloud’s Docker — a project which makes managing Linux containers easy, previously covered here and discussed on episode #89 — is inspiring & enabling a bunch of open source Platforms as a Service (PaaS).
Dokku weighs in at under 1,000 lines of Bash and offers the same git-push-based app deployment made famous by Heroku and emulated by many PaaS providers. After installation and some configuration, you can deploy to your own mini-Heroku using one of the many supported buildpacks.
Here’s what deploying Heroku’s example Node.js app looks like with Dokku:
$ cd node-js-sample $ git remote add progrium firstname.lastname@example.org:node-js-app $ git push progrium master Counting objects: 296, done. Delta compression using up to 4 threads. Compressing objects: 100% (254/254), done. Writing objects: 100% (296/296), 193.59 KiB, done. Total 296 (delta 25), reused 276 (delta 13) remote: -----> Building node-js-app ... remote: Node.js app detected remote: -----> Resolving engine versions ... blah blah blah ... remote: -----> Application deployed: remote: http://node-js-app.progriumapp.com
It’s exciting to see how much can be done with so little code. Dokku is MIT licensed and hosted on GitHub.
Are you paranoid and want to protect your codes at all times?
There is some controversy over using this technique, so do your research and understand the implications of using this tool before you go crazy with it.
Check out the project on GitHub.
From the Kickstarter story:
The main use case this enables is developing offline in environments like ChromeBooks. I worked on Cloud9IDE for a year and it was a great experience as long as you were online with a fast connection. With this library, HTML5 apps will finally be able to do the full developer lifecycle. They can clone from github to the browser’s local file storage when online, work offline using an editor like ACE or CodeMirror, and then when they are online again, they can push their changes back to github. I’ll implement branching, merging, diffing, and as many other awesome common tasks from git as possible.
Tim’s plan is to develop the library in the open and license it under the MIT license. “It will be open sourced on GitHub as soon as the Kickstarter succeeds,” says Tim. Our guess is you’ll be able to fork it here github.com/creationix/js-git on Saturday Mar 30, 11:50am CDT when the Kickstarter funds.
I’m pretty sure that most of you who read The Changelog care about
git. Well, yesterday, 1.8.2 was released!
Of course, linking to the commit that actually did the release isn’t mega-helpful, so here’s a link to the CHANGELOG instead.
My favorite change is this one:
The patterns in .gitignore and .gitattributes files can have
as a pattern that matches 0 or more levels of subdirectory.
fooitself or in a
I find myself wanting this a bunch, so it’s nice to have in. I’m also pumped about ‘git check-ignore’, which helps you figure out if what you added to your
.gitignore actually did what it’s supposed to do.
One of the best things about git is that it allows you to do whatever you want.
One of the worst things about git is that it allows you to do whatever you want.
This has lead to a bunch of different ‘workflows’ for managing an open source project. I remember when “Git Flow” hit the scene, and everyone was mega-excited by it. Then, GitHub themselves fired back with “GitHub flow,” which was a bit simpler and talked about how they handle things.
Here’s Yet Another Entry into this ongoing saga: “On GitHub and Workflows” Basically, it’s somewhere in between the two: you have three branches, representing production, staging, and development. On top of development, you work like GitHub Flow, and when things go from development -> staging and staging -> production, there’s an opportunity for a last code review.
As a bonus, there’s a little script at the bottom for making pull requests from the command-line with
hub. Neat! We originally saw this from this tweet by @moo9000.
Here’s a snap of the plugin in action:
Switch branches as fast as you switch pages. Waiting for a deploy sucks. Allocating a staging server for each remote branch is costly. But nothing beats testing on a staging server with real production data. Divergence allows you to quickly test your remote branches simply by changing the subdomain.
With Divergence you can easily view any branch from your repository on your staging server by using the branch name as the subdomain. Just use your branch name as the sub-domain and Divergence will magically find your branch and serve it up. You can even hook into a number of callbacks to automatically restart Passenger, run
bundle install, or any other task if needed.
It’s a Rack application that acts as a HTTP proxy between you and your web application for rapid testing. Divergence was built with an Apache-Passenger stack in mind, so if you’re wanting to help develop the project further, checkout the contributing section of the readme.
Divergence is a work in progress, and labeled as a beta release. The folks at LayerVault could use a hand with:
Divergence::Application.configure do |config| config.git_path = "/path/to/git_root" config.app_path = "/path/to/app_root" config.cache_path = "/path/to/cache_root" config.forward_host = 'localhost' config.forward_port = 80 config.callbacks :after_swap do restart_passenger end config.callbacks :after_cache, :after_webhook do bundle_install :path => "vendor/bundle" end config.callbacks :on_branch_discover do |subdomain| case subdomain when "release-1" "test_branch" when "release-2" "other_branch" end end end
Some of the engineers from Ooyala have released a new project that “makes code reviews fun.” It is a standalone piece of software that you host on your own (they recommend using Vagrant/VirtualBox).
With barkeep you get syntax-highlighted colored diffs, the ability to easily add your own features, a simple CLI, a REST API and plaintext (threadable) emails. Out of the box, barkeep offers many more features that will keep code reviews quick and entertaining. You can use barkeep with any git repo that has a reachable URL.
The team at Ooyala plans on growing barkeep as the community sees fit. Open issues as you play around with it – better yet, fork it and add new features yourself! Their style guidelines are simple: “mimic the style around you.”
gibo Python vim >> .gitignore
The script also lets you list all the templates in the GitHub project:
Check out the source on GitHub to check out implementation, usage, or how to contribute.