gitbranchworkflowrebasesquash

Why does my git show 4 ahead, 4 behind after rebasing to staging?


I've been doing some dev work, and my workflow is to commit things in a feature branch then squash and merge into develop, and then after that, every time I want to deploy into the staging server, I open a new PR and rebase develop into staging.

What happens is that the branch gets more and more diverged, with me having to force-push occasionally into staging, which I believe is definitely not the way going forward. 4 ahead, 4 behind

I tried to rebase or merge from staging into develop at one point, and what proceeded to happen was that I keep getting a lot of file conflicts of what seems to be outdated code (that I don't even see in Github) against the updated code from develop.

My specific workflow is something along the lines of:

  1. Make new branch from develop, e.g. feature-1
  2. When I'm done, I squash and merge feature-1 into develop
  3. I keep working on different features and get them squash and merged into develop
  4. When it's time for deployment, I rebase develop into staging

staging, at least to my view, should always be synced up with develop in a linear timeline since no changes are made to it other than it being rebased from develop during deployment, but what really happens is that it seems that when we rebase, it only copies the commit messages from develop but not the hashes, and staging gets split out into a linear but different timeline from develop. Also at this point, when I try to rebase develop into staging manually, it will show the above "N ahead, N behind" thing, and then when I pull from origin/staging, the "N behind" part goes away sometimes. I really have no idea how this works.

How do I get staging and develop back into one same linear timeline? And how to I prevent the branches from diverging like that again?

Additional details edit:

I've tried to manually rebase develop into staging because Github was complaining that it cannot rebase without conflict again: rebase manually

And now you can see that it is 5 ahead, but 4 behind the remote branch, so I cannot push as is as it'll show below: cannot push as is

Finally, I tried pulling from remote, and this is what I get: pulled from remote

Now we may think that all is fine and we can push, but after I checked gitahead it shows that I do, in fact, have spawned another linear but separate timeline for staging's commit. parallel timeline

I really don't know how to move forward without force-pushing.


Solution

  • I tried to rebase or merge from staging into develop

    Ideally, any merge or rebase is done from the most specific branch to a more general branch (feature to dev, dev to staging, staging to master).
    Doing the opposite means a lot of merge conflicts.

    How do I get staging and develop back into one same linear timeline?

    I would rather use an alternative workflow like gitworkflow, where you merge the feature branch to dev, and then the same feature branch to staging, keeping both dev and staging independent.

    The idea is to be able to merge only the branches ready for staging, instead of merging all dev, since dev can include features not yet ready, not robust enough to work with the other merged features.