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 >>

/
Cleaning Up Your GitHub Tree

A photo of Pablo Villar wrote this on February 21, 2014 under clean, github, inaka, tree .

Cleaning Up Your GitHub Tree

This is my first blog post at Inaka (yay!). I hope it will help you.

As soon as I started to work at Inaka, one of the first things I was taught was to be organized when working with Git. Not only does it allow me to understand it better, but it also allows me to keep track of what I’m doing and revert changes or go back to a previous state in case I need it.

It’s important to mention that using Git with iOS projects (the kind of projects I work on) is not as easy as with other projects, such as Erlang or Ruby projects, mostly because of the structure of the files and the way the changes are managed. So, it’s useful for me if I keep my Git graph story as clear as possible.

A couple of days ago, I had a nice bunch of branches that got messed up. I needed to confront the problem in order to get the network graph clean once again.

This is what the tree looked like before:

A messy tree

Then, as you can see, I somehow ended up with such a huge mess of branches:

After making an effort to clean it, the tree ended up like this:

A clean tree

Nicer, isn’t it?

So, how exactly did I clean it? How did I turn that crazy branchy thing into that neat and unified tree?

Here comes the magic.

There is a process that you should repeat for each branch you work on. I will explain the process and I hope you can get used to applying it and you feel satisfied afterwards.

Considering that you have been working on several branches, and each one is finished and ready to be PR’ed and merged into master (or the main branch you are using on your project), this is what you have to do for each branch to maintain order:

  1. Pull the latest code from master.
    • git checkout master
    • git fetch origin
    • git merge origin/master
  2. Stand on the branch you want to merge.
    • git checkout <your_branch>
  3. Rebase* this branch so that its base is now the latest commit from master branch.
    • git rebase master
  4. If there are conflicts when rebasing, you have to solve them by using any merge tool you feel comfortable with.
    • example (the one I use): git mergetool -t opendiff
  5. Once the rebase is finished, push these changes to GitHub by using the --force (or -f for short) parameter. (You have to force-push because you have changed what the network graph looks like).
    • git push -f origin <your_branch>

After that, network graph should look like this:

Network graph

This means that your branch was properly rebased and is ready to be merged into master, but you are not going to merge it manually, are you?

6. The correct way to merge a branch into master (if you are following Inaka’s workflow) is to open up a Pull Request and assign it to someone else, so that person can review your code before merging it into master.

Pull request

7. Once your code has been reviewed and merged, the tree should look like this:

Merged

8. If you want to keep your story cleaner, you should delete <your_branch> once it has been merged. What I usually do is delete it on the remote but keep it locally just in case I need it for some reason.

Taa-daa! Your branch has been successfully rebased and merged.

You can notice that by following this flow, your master branch will only contain commits that come from PRs.

When I got that mess of branches I mentioned above, I just repeated these eight steps for each branch I had. Finally (after the hard work of solving merge conflicts) I got my tree clean and shiny.

Before and after

Something I have learned during this process is that if you need to work on several branches before your code can be reviewed and merged by someone else (this is what happened to me), you should always start branching from latest master commit. If there is any specific reason for not doing so (i.e. you need code from a branch that is in another branch you are working) then you will have to branch from that specific branch. But be careful, because the cleaning process may become harder in that case.

*Remember: Rebase is a process of merging, where you merge a branch (your branch) commit by commit into another branch (a base branch). After a rebase, you will see that your branch has not lost any of its commits, but it has changed its starting point, which is now the last commit of the base branch (i.e. your branch has changed its commit base, it has been rebased).

It’s not the aim of this post to explain how the command git rebase works, so I won’t get into details about it. If you would like more information about it, look here.

A photo of

Pablo Villar

iOS Developer