Same project on slightly different machines

Hopefully this is not a dumb question.

I have a situation where my project needs to run on two different machines. One is a machine in my lab and the other is on an embedded system in the field. The project is completely python so architecture differences don’t really matter.

The issue is that there are slight changes that need to me made to make the code work on the machine in the field. So we created a separate branch for the machine in the field. Now when we develop new features on the machine in the lab and need to pass these features on to the machine in the field we use cherry pick commits to bring the new feature into the branch for the machine in the field.

Is this a good way of doing this ?

Cherry picking commits is generally best for when you have a lot of changes and you need only some of those changes to move over. Merging branches is the standard approach for when you want to develop some changes and then update a second environment with the “verified stable” changes. From your description, it sounds like merging branches is what you would want to use.

Just to be certain, let me be more specific. It sounds like you do the following:

  1. You make changes to the codebase to add new features on a branch (let’s call it lab)
  2. When the new features have been thoroughly tested, you need to add that code to the code that’s in the field (on a branch called field for example)

Now currently, you find all the commits that were added to the lab branch and git cherry-pick them into the field branch. I assume you do this because, at some point in the past, you did git merge and either clobbered the slight code changes for the field or dealt with some merge conflict when things changed in both places?

To be clear, both approaches work. But git merge is easier especially when there are no merge conflicts. You can significantly reduce the chance of merge conflicts if you extract the code differences into different files. For example, you could use a different configuration file in the field versus in the lab. Or you could load different code based on whether a certain environment variable existed (like __LAB_ENVIRONMENT=1).

This allows you to use the much simpler git merge process and still not have to deal with merge conflicts nearly as much.

Let us know if you have more questions.

1 Like

You have it exactly right. Thanks for the reply! Really appreciate it

Regarding your suggestion of merging. When I merge the ‘lab’ branch into the ‘field’ branch does the lab brand not cease to exist ? So when I want to work on the lab code is would have to rebranch and do the whole lab setup. Maybe I’m confused about branching, haven’t done it in a while.

Also, your suggestion about separating the difference in ‘lab’ and ‘field’ code into a config file or using flags as you suggested is probably the real solution to the problem.

Cherry commits work okay but they are easy to mess up and definitely not ideal for this situation

No, a branch that is merged does not cease to exist. You’re merging the commits from branch X into branch Y, essentially (in the common case) making branch X and branch Y equivalent. It is quite common though for this process to be used:

  1. Do some work on lab
  2. Merge the lab branch into the field branch
  3. Do more work on lab
  4. Merge the lab branch into the field branch
  5. etc

In this example, you could replace lab with development and field with production to perhaps get a better idea of how this process works. You do some work and every so often, when the changes are ready, you merge the changes to “production” to deploy them. This is a simplified version of how we do work at GitHub to make bunches of changes to the website each and every day.

Let me know if you have more questions.


Ahhh I see. Merging is the way to go for sure then :slight_smile: