Latest blog entries
The Art of Writing a Blogpost
Mar 09 2017 : Matias Vera
Feb 14 2017 : Felipe Ripoll
Do you need a blazing fast reverse geocoder? Enter offline-geocoder!
Jan 18 2017 : Roberto Romero
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
Nov 16 2016 : Stephanie Goldner
Because conferences and meetups are not just about the technical stuff.
Nov 01 2016 : Pablo Villar
Sharing some light on how it is to partner with us.
Oct 27 2016 : Inaka
How to easily play a sound in Android
Oct 25 2016 : Giaquinta Emiliano
We're publishing our work guidelines for the world to see.
Oct 13 2016 : Brujo Benavides
Using niffy to simplify working with NIFs on Erlang
Oct 05 2016 : Hernan Rivas Acosta
How to write clear function signatures, yet expressive, while following Swift 3 API design guidelines.
Sep 16 2016 : Pablo Villar
How to automatically trigger rails tests with a Jenkins job
Sep 14 2016 : Demian Sciessere
A description of our usual stack for building REST servers in Erlang
Sep 06 2016 : Brujo Benavides
Using Erlang's External Term Format
Aug 17 2016 : Hernan Rivas Acosta
Integrating our Android linter with Github's pull requests
Aug 04 2016 : Fernando Ramirez and Euen Lopez
Introducing how to implement passwordless login with phoenix framework
Jul 27 2016 : Thiago Borges
Our newest game to test your Beam Skills
Jul 14 2016 : Brujo Benavides
Three Open Source Projects, one App
Jun 28 2016 : Andrés Gerace
Running credo checks for elixir code on your github pull requests
Jun 16 2016 : Alejandro Mataloni
Thoughts on rebar3
Jun 08 2016 : Hernán Rivas Acosta
Cleaning Up Your GitHub 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:
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:
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:
- Pull the latest code from master.
git checkout master
git fetch origin
git merge origin/master
- Stand on the branch you want to merge.
git checkout <your_branch>
- Rebase* this branch so that its base is now the latest commit from master branch.
git rebase master
- 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
- example (the one I use):
- 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:
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.
7. Once your code has been reviewed and merged, the tree should look like this:
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.
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.