How to push the same edit to different branches in git?

Question

I have a Git repository which has a master branch. Now I want to create different branches which have the same changes in every branch (for example the database). So I can have these files in master:

• a.java
• b.java
• database-1.xml

and two branches, called branch-1 and branch-2, with these files:

• a.java
• b.java
• database-branch-1.xml

and

• a.java
• b.java
• database-branch-2.xml

Now, let that I find a bug in a.java, obviously I would like to fix it and commit the same change in every branch. How can I achieve my goal?

Note: The database files must remain different and the other files will be always the same.

Answer 1

merge. But it's best to change the file a.java at the common starting point where there is only database-1.xml otherwise it will get clobbered.

Cherry pick is the other way. But managing branches that way becomes unmanagable quickly.

This brings up the point about deploy config. You should not branch just because your config is changing based on where you're deploying. Make database.xml not work at all. Rely on deployment scripts or smudge/clean scripts to adjust the config based on where you're deploying - even locally.

This means the config should have the structure you need but be adjusted only in the areas it needs to be - usually just a connection string.

Think of what happens when you need to adjust something in the database file that has to go across all branches.

Answer 2

The possible solution depends on your workflow.

Option 1: Rewriting the history
If you do not push the branches to a remote repository you could commit the bugfix on the master branch since this is the common starting point of file a.java. Right after, you can rebase each branch to include this change.

Option 1a: Rewriting the history of topic branches only
Another workflow is based on conventions. You can have topic branches that are pushed to the server as you push the master branch. The convention is, that those topic branches are never merged into the master and rewriting the history is allowed. A topic branch can be private to one developer or shared among others. For the latter scenario the group has to coordinate before and after a rebase happens. When the topic branch work is done the branch gets rebased against the master and a fast-forward branch can be applied easily.

Option 2: Cherry pick
If you push the branches to a remote repository it is not recommened to rewrite the history. In short, the only option you have is to commit a bugfix on top of each branch. To avoid do the same job twice, git cherry-pick is the recommended command (as already told by Adam and Albert).

Option 3: Merge master back into each topic branch
This is the git part of Adam's answer. You can commit the bugfix on the master branch, which is the common starting point of the affected file. Then, you can merge the master back into the topic branches. That is in effect the same as updating the topic branch with all changes that have happened on the master branch in the meantime. This disadvantage is that you cannot choose the bugfix alone. This is what git cherry-pick allows (see Option 2).

Note:
If you do not plan to merge the two branches, you could actually use the same database-1.xml file for the specific configuration on each branch.

Project setup
Besides the different ways to work with git I totally agree with Adam's answer in the fact that you should definitely rethink your project setup and create a configuration file that allows you to specify different environments. A good example is the database configuration file of a RubyOnRails project as you might know.

// Rails project: config/database.yml

development:
  adapter: sqlite3
  database: db/development.sqlite3
  pool: 5
  timeout: 5000

test:
  adapter: sqlite3
  database: db/test.sqlite3
  pool: 5
  timeout: 5000

production:
  adapter: mysql2
  encoding: utf8
  reconnect: false
  database: myapp_production
  pool: 5
  username: username
  password: password
  socket: /var/run/mysqld/mysqld.sock

Answer 3

Try git-cherry-pick to apply specific commits: git-cherry-pick