skip to Main Content

I wrote a telegram bot and currently running it on Heroku. I have two branches: master and heroku. They are almost same; just heroku branch includes a Procfile and uses webhook instead of polling.

I use master branch to test bot locally (polling) and heroku to deploy it on heroku (webhook).

To apply new features and fixes I:

  1. commit them on master and push to GitHub
  2. checkout to heroku branch
  3. rebase heroku on master and use git push --force

Doing this every time is frustrating and may cause error. For example, once I accidentally rebased master on heroku!

Is there any better solution for this situation?

2

Answers


  1. Not a good practice, but in this case you could choose to create an alias that does it for you. It is a possible solution because the rebase operation will probably not generate any conflicts, given that the only difference between these 2 branches is that heroku branch contains very specific files.

    The alias could be something like:

    git config alias.rebase-heroku '!git checkout heroku && git rebase master && git push --force-with-lease'
    

    The only thing that you have missed is the --force-with-lease option that is always a good practice, even if you are the only one working on the project.

    Login or Signup to reply.
  2. This is an answer to the actual question "Is there any better solution for this situation?" from OPs question, but not in terms of "how to solve this using git?", which is what I initially interpreted the question title as.

    It is more a suggestion on how to avoid this recurring rebase situation moving forward, so it is looking at the situation from another abstraction level.

    I would take a slightly different approach with this, and instead of having different code in the different branches, I would write code that could use either of the two methods (polling or webhook), and that it would decide on which one to use depending on some setting like an environment variable.

    The reason why I’m suggesting this, is because I have come across similar things myself, and there is often very little code that differs between the two (or more) versions, and I have found that using different adapters this way can lead to less hassle with git rebases, etc. I have found that it is often preferrable to not have multiple parallel branches that need to be updated.

    I have no idea what programming language you are using, so there is some sample code in Python:

    def polling(*args, **kwargs):
        ...
    
    def webhook(*args, **kwargs):
        ...
    
    mech = os.environ("API_COMMUNICATION_MECHANISM")
    
    entry_point = webhook if mech == "webhook" else polling
    

    You can now pass entry_point to whatever is starting your app.

    Using this approach, with having separate "adapters" for the two different versions of communicating with the API, means that you should be able to not necessarily have a separate heroku branch at all, since you can make sure to set the config value on heroku by running heroku config:set API_COMM_METHOD=webhook. Then you should be able to just push your master branch directly to heroku, since you don’t need any different code in them anymore.

    Again, I realize this might not at all reflect how your application is structured (including, as I previously mentioned, that I’m probably writing example code in the wrong language), so if you would give some example on how the code in your master and heroku branches differ, I might be able to provide a better example (in the right language).

    If you really want to stick to having different code paths in the different branches, you are probably better off using the suggestion of a git alias, like Marco Luzzara suggested in his answer.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search