inaka

Latest blog entries

/
Erlang and Elixir Factory Lite B.A.

A brief introduction about what was the Erlang Factory Conference in Buenos Aires for some Inaka team members

Jul 07 2017 : Euen Lopez

/
The Art of Writing a Blogpost

The Art of Writing a Blogpost

Apr 11 2017 : Matias Vera

/
SpellingCI: No more spelling mistakes in your markdown flies!

Feb 14 2017 : Felipe Ripoll

/
Fast reverse geocoding with offline-geocoder

Do you need a blazing fast reverse geocoder? Enter offline-geocoder!

Jan 18 2017 : Roberto Romero

/
Using Jayme to connect to the new MongooseIM REST services

MongooseIM has RESTful services!! Here I show how you can use them in an iOS application.

Dec 13 2016 : Sergio Abraham

/
20 Questions, or Maybe a Few More

20 Questions, or Maybe a Few More

Nov 16 2016 : Stephanie Goldner

/
The Power of Meeting People

Because conferences and meetups are not just about the technical stuff.

Nov 01 2016 : Pablo Villar

/
Finding the right partner for your app build

Sharing some light on how it is to partner with us.

Oct 27 2016 : Inaka

/
Just Play my Sound

How to easily play a sound in Android

Oct 25 2016 : Giaquinta Emiliano

/
Opening our Guidelines to the World

We're publishing our work guidelines for the world to see.

Oct 13 2016 : Brujo Benavides

/
Using NIFs: the easy way

Using niffy to simplify working with NIFs on Erlang

Oct 05 2016 : Hernan Rivas Acosta

/
Function Naming In Swift 3

How to write clear function signatures, yet expressive, while following Swift 3 API design guidelines.

Sep 16 2016 : Pablo Villar

/
Jenkins automated tests for Rails

How to automatically trigger rails tests with a Jenkins job

Sep 14 2016 : Demian Sciessere

/
Erlang REST Server Stack

A description of our usual stack for building REST servers in Erlang

Sep 06 2016 : Brujo Benavides

/
Replacing JSON when talking to Erlang

Using Erlang's External Term Format

Aug 17 2016 : Hernan Rivas Acosta

/
Gadget + Lewis = Android Lint CI

Integrating our Android linter with Github's pull requests

Aug 04 2016 : Fernando Ramirez and Euen Lopez

/
Passwordless login with phoenix

Introducing how to implement passwordless login with phoenix framework

Jul 27 2016 : Thiago Borges

/
Beam Olympics

Our newest game to test your Beam Skills

Jul 14 2016 : Brujo Benavides

/
Otec

Three Open Source Projects, one App

Jun 28 2016 : Andrés Gerace

/
CredoCI

Running credo checks for elixir code on your github pull requests

Jun 16 2016 : Alejandro Mataloni

/
See all Inaka's blog posts >>

/
Git: Not Just for Devs

Inaka Blog wrote this on October 07, 2013 under for, git, github, inaka, writers .

Introduction

If you ask, most developers will wax poetic about the many benefits of using Git. But, for all its usefulness, the concept behind it is not so well known outside of the programming world.

For the uninitiated – just to cover our bases – Git works like this: the project lives on a stable master branch. Any and all edits to the master exist on separate, cloned branches. To officially add an edit, the separate, cloned branch is "pushed" to the master branch, along with an explanation (or "commit") explaining why. The edit and its commit are reviewed by a team member, and if they are accepted, the "pull request" is accepted, and the branch is merged to the master branch.

So what are the benefits Git? Well, for one, multiple versions of a project can exist at the same time on separate, cloned branches. What’s more, the separate branches are pushed and pulled to the master branch – the official version of the project – in a controlled, systematic manner. In this way, we avoid snafus like those real-time editing run-ins on Google Docs. In the end, Git makes sure all the information ends up in a single master project.

Another major benefit is that all edits are tagged with an explanation, so when reviewing the document, you’ll know why something was added or deleted. Likewise, you can easily undo each of these tagged edits.

Essentially, Git takes the very complicated collaborative process and simplifies it to its purest form. It does this so well, in fact, that many developers wouldn’t want to imagine a world in which they had to code without Git or, for that matter, GitHub. So why should such an amazing platform be limited to just code, and why should it cater just to developers? Isn’t it time to spread the love around a bit?

But to whom? Who might benefit from Git beside developers?

Anyone, and almost everyone. Think about it. Researchers, novelists, scientists, mathematicians, teachers, screenwriters, students, any collaborative group. There are endless possibilities.

In fact, a 600-page textbook on Homotopy Type Theory was written in less than six months by a few dozen mathematicians. And they used GitHub.

Loren Burton followed their project through its many iterations. Granted, it took them a while to get the gist of Git, but once they did, there was no stopping them, and what they did is nothing short of amazing. Maybe the best part? They can iterate new editions without breaking a sweat.

Because it is so useful, Git is slowly and surely finding ways to appeal to non-developers. But Git wasn’t designed with non-devs in mind. So here we are, to discuss the possible obstacles of using Git as a non-dev and highlight a few projects that are working towards making Git more accessible.

Obstacles of Git for Non-Devs

Git is great, and GitHub makes it even better. But it’s easy to forget how hard Git is to learn in the first place, especially if it isn’t a cornerstone of your work or office culture.

For one, tech jargon is especially alienating for those who have no tech background. This problem can be easily solved through implementing a more friendly user interface and finding different metaphors for command-line references in particular.

Another seemingly minor obstacle is that edits in Git are typically changed and marked line-by-line. That is to say, if I change one letter on a line of code, the entire line will be marked as deleted and then re-added, the latter version containing my edit. But this won’t work well for writers. A non-dev-friendly Git program would need revise the variable of change to phrases, words, and possibly even letters, not whole lines of code.

Something else to consider is the disciplinary aspect of Git. Those used to Git will find it easier to remember to upload each and every change, but this may prove difficult for others. If they aren’t used to the interruptions, it may even block whatever "creative flow" they have in the moment. This can be solved in any number of ways, either by sending reminders or automating the commits so that the user can forget about them altogether.

In exploring how to bring Git to non-devs, these obstacles need to be addressed and re-imagined, all while maintaining the benefits of using Git in the first place.

What’s Available

As far as Git for non-devs goes, nothing is as big or all-encompassing yet as GitHub, but people are chipping away at the idea. If Git interests you beyond coding, here are a few programs that are worth checking out:

Draft, for one, offers easy version control and other collaborative tools for users. When others propose edits to your personal project, you can decide to merge or ignore. It also bookmarks different versions of your work, and you can even examine how your document has changed over time by comparing these versions side-by-side. On top of that, there’s an Uber-like service for copy-editing. Simply click the "Ask a Professional" button for free advice, no matter if you’re writing a Christmas card, a wedding toast, or a piece of historical fiction.

There’s also Editorially. It, too, is presented in plain text so you can worry about the words more than the format. It also enables you to compare any two versions side-by-side, just as Draft does. You can hold discussions with your peers in the margins, and you can easily see who has said and changed what in the document. Editorially is always on auto-save. Plus, its responsive design will work on any of your devices.

Authorea is yet another program, developed by "a spin-off initiative of Harvard University." It has many of the same features, and its engine understands Latex, Markdown, and most web formats. It works online, too, rendering your articles into HTML5 right in your browser. The first article is free, but to use Authorea for more than one project, you’ll need to get a subscription.

A fourth program called Penflip is underway, too. It is one of Loren Burton’s projects. For now, it’s just a landing page, but based on the great ideas in his blog post, I’m sure it is worth receiving the updates.

Conclusion

Git is as popular as it is with devs for a reason. It is a simple and systematic way to create large, detail-oriented, collaborative projects. If this seems in any way useful to you, don’t shy away. I encourage you to look into one of the non-dev-friendly Git-based programs, because Git will change the way you think and write with others for the better.