Rebase is one of the main ways to integrate changes from one git branch to another. It consists of placing all commits of a source branch on top of the target branch. Its basic usage is simple:

$ git checkout new-branch
$ git rebase main

As complexity grows, branches will be created from other branches and, when rebasing onto an already rebased branch, you may be asked to solve the same conflicts you solved in the first rebase. To understand why this happens, it’s important to know that using rebase changes the hash of the affected commits. Because of this, git assumes it’s a different thing and doesn’t know that the conflict has already been solved in the past.

Before rebase
*--a--b—--d -> A
    \---c---e-----g -> B
             \-f-----h---i -> C

After rebasing B onto A
*--a--b—--d -> A
    \      \---c'---e'-----g' -> B
     \---c--e--f---h---i -> C

After merging B onto A
*--a--b—--d---c'---e'-----g' -> A
    \---c--e--f---h---i -> C 

Note that all commits on Branch B changed to a commit' version. It represents the same change, but with a different hash.

If when rebasing B to A you solve a conflict on c, when rebasing C to A, git will not recognize that c is already rebased and will try to put it on top of g', prompting you to solve the conflict again. In complex cases, with a lot of commits and conflicts, this could lead to a lot of extra work.

To solve this problem, we have two options.

Using git rerere functionality

“rerere” stands for “reuse recorded resolution”. It’s a flag that, when active, tells git to record how you solve each conflict to reuse it in case you need to solve it again. Turning it on is super simple:

$ git config --global rerere.enabled true

And it’s done. From now on, every time you would be asked to solve a conflict you’ve already handled, you won’t. Git will identify the recorded conflict and solve it for you.

It’s important to note that git rerere will record only future conflicts, but if you landed here while searching for “solving the same conflict multiple times” you probably already have this situation going on. Which leads us into our second option:

Using git cherry-pick

This is not as simple as using rerere but it’s still simple. With cherry-pick we can select a range of commits to apply to a given branch. This way, we can make a “manual rebase”, selecting only the commits that were not rebased onto the first one.

In our example situation, we’ll need to select commits f, h and i from branch C and put them on top of branch A:

$ git checkout A
$ git cherry-pick f^..i

And it’s done.

Want to learn more about Git and other stuff related to development? Follow our blog Goiabada and enjoy a delicious mix of software development, design, and business.

Git Tricks: Avoid solving the same rebase conflict multiple times was originally published in Goiabada on Medium, where people are continuing the conversation by highlighting and responding to this story.

Removendo o termo Master de seu projeto no GitHub

Devido à onda de protestos nos EUA e em todo mundo contra o racismo, muitas pessoas passaram a se perguntar onde e como ele se manifesta em suas vidas.

A resposta pra isso é simples: em todo lugar. E em nossos projetos digitais não seria diferente.

O Git, um dos sistemas de controle de versão mais populares do mundo, utiliza como padrão o termo master para identificar a versão principal do projeto. Este termo vem de uma metáfora extremamente opressiva: Master-Slave, que significa Mestre-Escravo.

Existem diversas razões para abolir o uso dessa metáfora de nossos projetos digitais e, em 2018, a Internet Engineering Task Force (IETF) lançou um documento que fala sobre os males de terminologias opressoras em projetos digitais, por que elas não devem ser utilizadas e sugere termos para substituir essas terminologias.

Além disso, muitas comunidades e empresas vêm abolindo o uso de termos racistas como Master, Slave, Blacklist e Whitelist de seus projetos e os substituindo por termos não opressores e de igual entendimento: Primary, Secondary, DenyList e AllowList. 👏 🎉

Um pequeno gesto que está em nossas mãos é remover o termo master de nossos projetos no GitHub, dessa forma, além de demonstrar apoio, você influencia outras pessoas a seguirem o mesmo caminho.

Como fazer isso?

Embora a master seja a branch principal de seu projeto, renomeá-la não é complicado. Mas lembre-se: sincronize essa ação com colegas de trabalho. Esta branch é utilizada por todos as pessoas participantes do projeto e alterar seu nome sem um aviso prévio pode (e vai) causar problemas.

Avisou pra todo mundo? Todo mundo de acordo? Então vamos:

Escolha um novo nome

Existem várias opções possíveis: default, primary, trunk, etc. Eu gosto de main pois, como citado por Scott Hanselman, utilizando este nome você ainda tem a vantagem de que este termo também começa com ma, então a memória muscular de digitar ma e apertar Tab para auto-completar ainda funciona.

Crie uma nova branch

Faça isso a partir da master e, depois, faça o push para o repositório:

$ git branch --move master main
$ git push -u origin main

Modifique a branch padrão no GitHub

Fazendo isso, a tela inicial do repositório, todos os novos Pull Requests e qualquer outra ação que aponte para uma branch, serão apontados para a main, a não ser que você especifique o contrário. Para fazer isso, vá até seu repositório no GitHub, em Settings → Branches. Na opção Default branch escolha main e aperte Update.

Faça a modificação em serviços que dependem do nome da branch

Se você utiliza alguma regra ou action no GitHub, algum serviço de CI/CD, pipelines ou qualquer outro que dependa do nome da branch para funcionar, você deve modificar a branch para a qual o serviço aponta. Não é provável, mas fique de olho em qualquer problema que possa aparecer após a mudança.

Peça a todos para sincronizar

Todas as pessoas trabalhando no repositório terão que aplicar as modificações em sua cópia local. Para criar uma nova branch referenciando a nova main basta rodar $ git branch -u origin/main.

Apague a branch master

Se estiver trabalhando com várias pessoas, não tenha pressa para fazer isso. Sincronize com todo mundo e quando estiver pronto para apagar a master, utilize $ git branch -D master se quiser apagá-la apenas localmente. Para apagar a branch remota, você pode fazer pela interface do GitHub ou utilizar $ git push origin --delete master.

E é isso, a partir de agora seu repositório possui uma branch principal que não faz referência e nem normaliza a estrutura social de um período sombrio de nossa história.

Não pare por aí

Há muito mais a ser feito e isto não é algo que tenha fim. Estamos inseridos em uma sociedade opressora e, mesmo sem perceber, utilizamos termos e expressões que normalizam e reforçam essa condição.

É necessário prestar atenção constante nos termos utilizados em nossos projetos. No documento proposto pela IETF, há um sumário de recomendações que ajudam a não utilizar termos opressores, entre elas:

• Reflita antes de usar metáforas;
• Use gênero neutro;
• Leve isso em consideração em processos de revisão.

E é assim, através de pequenas ações, que podemos fazer nossa parte na construção de um mundo (real e digital) melhor e mais inclusivo para todas as pessoas.

Não são somente palavras

Ao refletir sobre os termos usados em nossos projetos, aprendemos sobre a origem dessas expressões e os impactos que elas causam nas pessoas e na sociedade. Apenas parar de usá-las não é suficiente: devemos agir de maneira a não propagar essas opressões.

Para nos ajudar a trilhar esse caminho, estamos usando o Pequeno Manual Antirracista, de Djamila Ribeiro, como tema de debate para o nosso próximo clube de leitura aqui na Guava. Leia você também!

Removendo o termo 'Master' de seu projeto no GitHub was originally published in Goiabada on Medium, where people are continuing the conversation by highlighting and responding to this story.

Spec-Driven Development is a software development process that uses the API specification as a guide to implementation. Inputs and outputs are turned into test cases to ensure that the API does everything it promises.

There is just one requirement to use this approach: Write the API documentation first. The most we can do beforehand the better, but we're not going Waterfall here. We can also use the benefits of agile methodologies to increment the documentation in cycles, as we do when coding.

Writing documentation first has some benefits:

1. Parallelize the development process. With the documentation in hands, both server and client can develop simultaneously. Mocking the API can improve this benefit.
2. Improves understanding of the whole. When writing the docs, you'll face edge cases, find inconsistencies and notice design problems. This will make the development process a lot easier and decrease the amount of rework.
3. Guide Development. Using the documentation as base for spec-driven development ensures that the API does exactly what it promises and, by delivering a great test coverage, decreases the amount of escaped bugs.

How to use Spec-Driven Development

With our documentation in hand we can start the development process. It’s very similar to BDD, with the difference that we rely on our API docs instead of user stories:

1. Choose a resource to develop;
2. Based on the specification, create automated tests to ensure the behaviour of the resource;
3. Code until the test passes;
4. Refactor until you're happy :)
5. Repeat!

Showing by example

Now that you already know what to do, I'll show how I'd do to create automated tests based on the documentation of a given resource. To do this, I'll use the OpenApi format to define the specification and RSpec to implement the tests.

Suppose we have an application that stores information about artworks and a new feature is required: transfer the ownership of a given artwork. The first thing we need to do to use Spec-Driven Development is to write the documentation of this feature.

After some discussion and review process we ended up with this:

A simple PUT endpoint. Let's walk through each point of interest.

• parameters: just one, named id, that represents the ID of the artwork;
• requestBody: one integer representing the ID of the new owner;
• Three response cases: 200, 404 and 422.

These elements are important to build our expectations and create a good test coverage. I'll show you.

First of all, let's describe our endpoint:

Here we've described our endpoint and defined two arguments that will change according to our context: the action (or path) and the params that will be used. We've also declared what will be done before each expectation: a put method to our action, using the defined params.

To ensure our API implements every response case, let's define one context for each one:

As said, each context represents one of the response cases and defines the necessary conditions for them to happen. Doing this ensure that every single response case of our API is covered by our specs.

Finally, we define the expectations for each context:

Each context has one or more expectations. When the artwork is transferred we just need to ensure that the response is a 204 status. In the other two contexts, we also check if the error message is correct.

Now, our tests are ready and we can start our development process. I'll not cover it here, but remember: if during the development process you notice that something is wrong with some resource, go back to the documentation and change it first.

At the end of the development process you may not have a perfect API, but will have one with a great test coverage and that delivers exactly what it promises. That's what an API is about, right?

Want to learn more about development process and other related stuff? Follow our Goiabada Blog and enjoy a delicious mix of software development, design, and business.

Using Spec-Driven Development to build consistent APIs was originally published in Goiabada on Medium, where people are continuing the conversation by highlighting and responding to this story.

Git Tricks: Avoiding merge when dealing with remote conflicts

TL;DR: git pull --rebase

The scenario is common: You finish the changes on a codebase, all commits are ready to be pushed. You run git push and an unexpected message appears: "! [rejected]". The reason: "Updates were rejected because the tip of your current branch is behind its remote counterpart. Integrate the remote changes (e.g. hint: ‘git pull …’) before pushing again.".

You follow the message and run git pull. Instead of pulling all changes to your local machine you are asked to confirm a merge commit message…

First of all… Why this is happening?

This happens because, after you've pulled, someone pushed changes to the same branch you're working on:

By confirming the merge commit, all the work on the remote branch will be merged on your local work. After this, you will be able to push your changes, making your-local-work coincide with the tip of remote-branch:

Is there an alternative to merge commit?

Yes, there is. To avoid the merge commit you need to rewrite your local history.

To do this, instead of just pulling the remote changes, you need to rebase them: git pull --rebase. By doing this, all of the commits from your local branch will be placed after the ones in the remote branch:

After this, you just need to push your changes. Your local work will become the tip of the remote branch.

The advantages of this approach is that you don't need a merge commit and a fork on the branch history will not be created. Also, notice that nothing on remote was rewritten, so you'll not need to use--force to push your changes.

Want to learn more about Git and other stuff related to development? Follow our Goiabada Blog and enjoy a delicious mix of software development, design, and business.

GIT Tricks: Avoiding merge when dealing with remote conflicts was originally published in Goiabada on Medium, where people are continuing the conversation by highlighting and responding to this story.

One DateTime, two inputs… Doing it in Rails

Let's assume you have an Appointment model and want to store the date and time it is scheduled. Since you need both date and time values the obvious choice is to go with a single datetime attribute named starts_at.

Now, you need to display it in a way the user can enter this value. Rails has a built-in datetime_select helper. It splits the datetime attribute into five smaller parts: year, month, day, hour and minute and creates one picker for each of these parts.

This would be enough if we wanted our users to select five different inputs, but our application design is different, it requires only two inputs: one for date and another one for time.

This design prevented us of using Rails' built in solution, so we decided to create two virtual attributes to represent both date and time. Let's dive into this solution.

First of all, let's check our view with these two inputs. I'll skip the date picker part for clarity purposes.

In the snippet above there are two attributes which we’ll need to define: starts_at_time and starts_at_date. We'll do so in the Appointment model by creating a getter and a setter for each:

If we load our view now it should render correctly 🎉. But if you try to create the appointment using the view above you'll see that the values chosen for starts_at_date and starts_at_time are not being stored in starts_at. This happens because we still need to map the persistentstarts_at to the values stored into the two virtual attributes. The most common way of doing this is defining a before_save callback:

Now we've done it. Our inputs are working and we're saving the correct value to our starts_at attribute. We could stop right here, but I don't like this approach very much for a couple os reasons. Firstly, it can create problems with validations. In addition to that, we could see some unexpected behavior on other parts of the system due to the callback. Lastly, the starts_at attribute won't be set/overwritten until we actually save the appointment.

For this reason I've decided to go with a more straightforward solution that updates the value into starts_at whenever we set one of the values of starts_at_date or starts_at_time:

And that's it 🎉. A simple and easy solution when dealing with datetime fields with multiple inputs.

In our full solution we used these virtual attributes in a React component using the react-rails gem. In future posts I'll explain why and how we did it, so make sure to follow Guava's blog Goiabada and keep track of all our posts :)

One DateTime, two inputs… Doing it in Rails. was originally published in Goiabada on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is the second part of a two-part series. You should read the first part first.

Before we restart

The 30-day code quality challenge is language-agnostic, but the project I’m working on is based on the Ruby on Rails framework. All code snippets used in here were gotten from this project. That said, let’s start.

Day 12 — Investigate your slowest test(s)

I already knew which tests I should look for. They were visibly slower than the rest. I ran rspec spec/ --profile to check how much slower they were:

I got 4 examples taking more than 3 seconds to run. All of them were inside a single context. Let’s take a look at them:

I didn’t need to look much to find out the problem was that the setup was creating a lot of forms for each expectation. I took a look at them and noticed that I could create all these forms only once for the entire context.

I changed this before to abefore(:context) and added DatabaseCleaner to clean my database after the context. Here what my context looked like after the changes:

I ran it with --profile again and had a nice improvement on the speed, decreasing the time of the lowest spec from 4.23 seconds to 1.45 seconds, almost 3 times faster. 🚅 🚅

Day 15 — Improve one name

One of the reasons to change the name of something is: Is the name your customers would use the same as what’s in the code?

For this question I had one attribute that used a different name on my code and another one on the client. I avoided changing this name because it’s used in 7 different models. Changing the name would make me change controllers, representers, specs, validators, etc…

But the time to change this name had come. I relied on my tests to make sure everything kept working and used find and replace to change the name across all the files I needed to change: 46 files.

Besides this great number of files, this task took me less than 20 minutes. Totally worth it. :)

Day 16 — Audit your dependencies

To complete this task I took a look at my Gemfile and made sure that I was using everything in there.

After this, I installed bundler-audit and ran bundle audit check --update to check if any gems have any security vulnerability. I got this as a result:

To fix this I just ran bundle update nokogiri and no more vulnerabilities were found.

Since I didn’t use nokogiri on this project I checked the Gemfile.lock to find out what gem used it as a dependency and created an issue there to check if they want the dependencies to be updated.

Day 17 — Tidy your open PRs/issues

As I do with branches, I always try to keep my PRs updated. Unfortunately, I admit this is not true for Trello cards. 😅 I have the bad habit of forgetting about them. But, this time, I had all of them updated. 🎉

So, I used the opportunity to poke my coworkers on their trello cards to check if they’re all updated. :)

Day 18 — Investigate long parameters list

I checked my code for methods that receive more than three parameters and found nothing. I just found one method that has three and most of them received one or no arguments.

I confess that I didn’t make this on purpose but I’m glad I did. Points to me. 👏 👏

Oh, Ben also sent an article explaining the types of coupling. It’s a good one and totally worth the time to read it. For this task, the Control coupling part deserves special attention.

Day 19 — Automate repetitive actions

On the last project I worked all the development took place inside containers. I used some aliases to start the environment since it always used two or more commands.

The current one is pretty simple so I don’t have any script or alias for it. I could create some for Git but I’m not a huge fan of creating aliases just to replace one command, although I know the benefits of it.

I’m sure when this project gets more complex I’ll have something to automate. For now, I liked one special thing that Ben told us this day and I’d like to share with you:

I think you’ll find this one quite satisfying. When I automate an annoying task, I get a little burst of dopamine each time I use my new, improved method to accomplish it. One-time effort; continuous payoff.

Day 23 — RTFM

Or, if you prefer, “Read The frickin’ Manual”.

During a long time of my experience in development, I skipped the step of reading the manual and jumped right to Stack Overflow questions. Doing this seems ok, but it’s not.

Using the manual instead of Stack Overflow is better because you have an overview of all features of the library and can learn different ways of doing the same thing.

For this project I’m using two new libraries and I have their manuals constantly open: dry_validation and Representable.

But, this task proposes something more uncommon: to read the documentation to check for unused features or anything that can improve what you already know. I confess that this is something that I almost never do.

Since I’m already trying to learn these two new libraries I’ll use Ben’s advice to get used to new commands:

Jot it down on a sheet of paper next to your keyboard so you remember to try it later. I do this often to teach myself new Vim commands. Once the new stuff is in my muscle memory, I throw the sheet away.

Day 24 — Done

And this is it. Day 23 was the last day of the Code Quality Challenge. I’d like to thank Ben for taking time to make this happen and all other participants who posted on the forum during the challenge. I’ve learned a lot with you during all these days.

Next steps?

Yes, of course. :)

I’ll get some of these daily tasks and schedule them to make it time after time. I think that doing them frequently will keep my code better, cleaner and more efficient.

What about you?

Do you have any task you do from time to time to increase the quality of your code? Share it with us, it will be nice to add it to my schedule.

Code Quality Challenge — A diary — Part 2 was originally published in Goiabada on Medium, where people are continuing the conversation by highlighting and responding to this story.

I've always tried, without success, to finish these X days challenges in doing something: 30 days writing challenge, 365 days photo challenge, 100 days JS programming challenges… And the list goes on. I don't have an exact reason for not ending, or even not starting, these challenges. I simply didn't.

But, a month ago, I started the 30-day code quality challenge, proposed by Ben Orenstein. This time, I finished it and want to share my experience with you.

Before we start

The 30-day code quality challenge is language-agnostic, but the project I'm working on is based on the Ruby on Rails framework. All code snippets used in here were gotten from this project.

That said, let's start.

Day 1 — Clean up your README

This was simple, but I had never written a README before. I've been working on the same project for four months and the README was blank… Until the day I accepted this challenge. In 20 minutes I had a simple but useful README that explains what the project is about and how to start the development for it.

Day 2 — Nuke TODO comments

I had luck with this one. I ran a search for TODO in my codebase and found only this one:

def handle_requisition_error(response)
  # TODO: Do something here
  context.fail!
end

Two days before this exercise, we had merged a commit that added Rollbar to our project so, instead of adding the TODO to an issue tracker, I decided to finish it.

It was fast and straightforward. It took half an hour and when I searched for TODO again, nothing appeared. Nice.

Day 3 — Get rid of a warning

I thought I would have nothing to do this day. I ran rails console,rails server, and rspec spec/ and no warnings. So I talked to one of my coworkers about it and he reminded me that bundle can output some warnings. I ran the command and got a nice warning telling me that I was using an old version of Bundler:

I don't know why I didn't update it before. Actually, I never read it, at all. I think I got used to ignoring warnings after working on a project that was full of them.

I just ran the command suggested by the warning itself and it was solved. It took me less than a minute of work.

Day 4 — Excise some unused code

The project I'm working on is a small one, created and maintained by myself. I always tried to check and remove all unused methods when refactoring things.

But, in the e-mail, Ben recommended the unused tool to check if you have code that is not being used. I decided to install it and give it a try. As a result, I got a green message saying: "Unused found no results" 🎉.

To check if the tool was really working, I ran it in an old project that I was sure there was unused code and I got a very big list. So, even if I didn't code anything in this day, I learned about a very useful tool to run in my next projects from time to time.

Day 5 — Trim those branches

The last project I worked on was a big one with a huge codebase. There I learned that keeping your codebase clean is very important to keep your sanity.

Therefore, since the beginning of this new project, I kept cleaning the merged branches so, when I ran git branch -r I just got branches that we're currently working on.

Day 8— Extract a compound conditional

Compound conditionals are statements composed of two or more conditionals. To find them I scanned my project for && and || and got one occurrence that was used in three distinct controllers:

It was a compound conditional made of two conditionals. The idea was to check if we should render the form_from_another_user_error. I created a protected method inside ApplicationControllercalled should_render_form_from_another_user_error? and placed the logic inside it:

Still not enough. The reason why I should render the error is not clear. To make this right I needed one more change: extract each conditional to its own method.

The first one is checking if the form doesn't belong to the current user so a method called form_from_another_user?(form) should solve it. The second one checks if the action is not a transfer so I decided to call it not_a_transfer_action?:

Now, instead of having a compound conditional inside my controller I have one method with an explicit name composed by two methods with good names. No one will ever need to guess what this piece of code does. 💥

Day 9— Slim down an overgrown class

First of all, I needed to check what classes of my project were the longest ones. So I ran the command given on the task to check it: find ~/code/my_project -name "*.rb" | xargs wc -l | sort -rn | head and got this list in response:

The command returned only specs and I don't know if having big specs files is a problem. Is it?

As a fallback task I needed to improve something about a class of my project. I went through my project searching for some class that I could refactor and found one folder named services containing only one class named third_party.rb.

The purpose of this class was not clear by its name or folder. This class is responsible to handle API connections with this third party software by including HTTParty.

I improved this code by creating a new folder called apis, moving the ThirdParty class to this new folder and renaming it to ThirdPartyApi. By doing it I made the purpose of this class clearer than before.

Day 10— Create a bin/setup script

This day's task was to create a script to setup my app for development use. I picked Ben's example, opened the bin folder and… found out that Rails generates a setup script.

So, all I needed to do is to update my README.md to include how to use the script.

Day 11— Run your tests with your wifi off

No problems here. My tests ran fine without connection. The system uses a third-party API but it's already mocked in specs. I'll show you how I did it. First of all, let's take a look at the controller:

To perform this create action I need to connect to a third-party API. I put all the interaction with this API inside an interactor called PerformLogin. It gets the response from the API and I handle it on the controller based on the interactor response.

So, on my specs, all I needed to do is to mock the response from PerformLogin and all the interactions with the third-party API will not happen anymore:

Is this the end?

No! For now, we're half of the way through these daily challenges.

Now continue on to Code Quality Challenge — A diary — Part 2!

Have any doubts?

Have any questions about the code quality challenge? Want to know more about any of these daily tasks? Have anything to share about code quality? Talk to us :)

Code Quality Challenge — A diary was originally published in Goiabada on Medium, where people are continuing the conversation by highlighting and responding to this story.

In one of our projects, we use git with 3 main branches: master, staging and production.

master has all the code that has already been reviewed and approved, staging has the code on our staging machine and production has what is currently running for the client. They all follow the same timeline: from master to staging, then to production, so we have something like this:

---------o---o---o->
         P   S   M

Then when we need to merge master into staging or staging into production we simply need to go to the target branch and merge it with the branch that is ahead of it:

$ git checkout production
$ git merge staging

Using this approach, no merge commit will be created, because this merge is Fast Forward (FF). The commits from the ahead branch are just put after the last commit of the target branch. After that, we should have:

-------------o---o->
            P,S  M

But yesterday, one thing happened: staging diverged from master.
One of my coworkers merged a PR on master, that was not synced with remote, merged it to staging and pushed it. So we ended up with something like this:

--a-----b---d--> master
   \------c----> staging

We just noticed it afterwards, when we tried to merge master into staging again and received a prompt to edit the message of the merge commit. An easy fix for it would be to just merge it, but if we did that, all our merges would stop being FF and would generate merge commits, something we don’t want.

Two options were available to solve this problem. I'll walk through both of them now.

Using reset and force push

This approach keeps history clean by rewriting it but you'll need to push to remote using the force option. This can cause some problems when working with other people. Be careful when using this approach.

First of all, cherry-pick the diverged commit from staging to master:

$ git checkout master 
$ git cherry-pick <commit-C-from-staging-branch>
$ git push origin master

Which leads us to:

--a-----b---d--c*-> master
   \------c-------> staging

Notice that a new commit was created on master. This happened because cherry-pick creates a new commit with the same changes as the selected one.

Now we need to return staging to the point where it diverged. We can use reset here to remove the last commit from staging's history.

$ git checkout staging
$ git reset --hard HEAD~1

If you try to push staging now you won't be able to do it. At this point, your local staging has diverged from remote staging. Keep in mind that we're using --force. This will rewrite history for any person that is dealing with this branch, so sync with them before doing so.

$ git push --force origin staging

Which leads us to the same timeline:

--a-----b---d--c*-> master
  |staging

At this time, staging doesn't have any different commits from master and is 3 commits behind. In this situation we can just run git merge master on staging. It will run smoothly, with FF and no merge commits, to the result of:

--a-----b---d--c*-> master, staging

Using merge commits to avoid force push

This approach avoids the use of the --force option, so it's safer. But it will add one merge commit to your history line. This is not a big deal but can pollute your history if used frequently.

Start this approach by going to master and merge staging into it.

$ git checkout master
$ git merge staging

This will create a merge commit, so you'll be prompted to confirm the commit message. Do it and push staging to origin, which will lead us to this, with a new merge commit:

--a-----b---d---m-> master
   \------c----/--> staging

Notice that staging is still split from master. To fix this we need to merge master into staging. Since both branches are synced, the merge will be FF, so you can just push it after the merge.

$ git checkout staging
$ git merge master
$ git push origin staging

Now, our two branches will be synced and all our merges from now on will be FF, but notice that our history will stay polluted by the time staging diverged from master:

--a-----b---d---m-> master, staging
   \------c----/

Git is extremely versatile and flexible so it usually offers different ways to accomplish the same goal. It's up to you to decide which one is best for your git flow. If you use another approach to keep your branches even, feel free to use the comments to share it with us.

Git Tricks: Keeping branches even was originally published in Goiabada on Medium, where people are continuing the conversation by highlighting and responding to this story.