In the `Branches` view of my bitbucket repo, I have several branches (as expected). I want to make "master" have ALL the changes of `feature/public_20210922/byron`.
I'm lost in the user interface, and I've spent the day being "git-spanked".
When I look at the branch in question, I see what appears to be a split bar, with a light grey portion under the "Behind" tab and bright blue portion under the `Ahead` tab.
Each says "26". When I mouse over the bright blue bar, a tooltip says "26 commits ahead of master". When I mouse over the light grey bar, a tooltip says "26 commits behind master".
When I select the branch in question, I get a light blue bar that says "26 commits behind "master" and has a "Sync now" button.
When I click the "Sync now" button, I get an alert that says "Syncing this branch will result in merge conflicts".
I already knew that!
Here is a command-line session that seems to have the same unhappy result:
[tms@byron browser]$ git branch
[tms@byron browser]$ git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
[tms@byron browser]$ git merge feature/public_20210922/byron
CONFLICT (content): Merge conflict in yarn.lock
CONFLICT (content): Merge conflict in src/components/scene/map_scene/MapSceneView.js
CONFLICT (content): Merge conflict in src/components/scene/map_scene/MapScene.js
CONFLICT (content): Merge conflict in src/components/scene/SceneView.js
CONFLICT (content): Merge conflict in src/components/scene/Scene.js
CONFLICT (content): Merge conflict in src/components/scale/SingleEndedScale.js
CONFLICT (content): Merge conflict in src/components/omnibox/scene_controller/SceneController.js
CONFLICT (content): Merge conflict in src/components/omnibox/navigator/panes/ContactPane.js
CONFLICT (content): Merge conflict in src/components/omnibox/OmniboxView.js
CONFLICT (content): Merge conflict in src/components/omnibox/OmniboxContainer.js
CONFLICT (content): Merge conflict in src/components/legend/legend_view/BooleanLegendView.js
CONFLICT (content): Merge conflict in src/components/legend/Legend.js
CONFLICT (modify/delete): src/components/data_layer/legend_view/SingleEndedLegendView.js deleted in feature/public_20210922/byron and modified in HEAD. Version HEAD of src/components/data_layer/legend_view/SingleEndedLegendView.js left in tree.
CONFLICT (modify/delete): src/components/data_layer/legend_view/DoubleEndedLegendView.js deleted in feature/public_20210922/byron and modified in HEAD. Version HEAD of src/components/data_layer/legend_view/DoubleEndedLegendView.js left in tree.
CONFLICT (modify/delete): src/components/NavigatorSpike.js deleted in feature/public_20210922/byron and modified in HEAD. Version HEAD of src/components/NavigatorSpike.js left in tree.
CONFLICT (modify/delete): src/components/LegendSpike.js deleted in feature/public_20210922/byron and modified in HEAD. Version HEAD of src/components/LegendSpike.js left in tree.
CONFLICT (content): Merge conflict in src/components/ContentContainer.js
CONFLICT (content): Merge conflict in .vscode/launch.json
CONFLICT (content): Merge conflict in .eslintcache
CONFLICT (content): Merge conflict in .env
Automatic merge failed; fix conflicts and then commit the result.
Is there some straightforward way to tell git/bucket to make the `master` branch be the same as `feature/public_20210922/byron`?
I know that I can slog through dozens of files one by one with my IDE and fix them -- but that is exactly WHY I put all these changes into this feature branch!
What am I missing here?
Following are three screenshots showing the above:
I know that the community is not going like what I'm about to write, and I'm going to accept it anyway as an answer.
All of this complexity about merge conflicts and such was exactly WHY I started using the "feature branch" workflow two years ago. This is not a huge project with many developers. This is JUST ME -- trying to keep different layers of my technology in some meaningful way.
The specific use case is that I have a complex app that works (I invite you to drive it at `https://covid.zeetix.com`). It has a database backend, middleware in nodejs, and a frontend built from React using the Material UI library. The last is key -- the working front end, as of about a year ago, was written in v4 of the Material UI library.
I learned, about that time, the MaterialUI v4 was being replaced by v5 -- and the changes are pervasive (at least in my front-end). I needed a place to keep those changes, and so I created a feature branch for them -- `feature/muiv5`
I did ALL of my muiv5 development in that feature branch, and started working on the migration.
The motivation for changing the front end was the need to add user authentication. I chose `auth0` to minimize the amount of code I had to write on my own. Still, it meant writing several new React components to present the various screens to the user. Since I didn't want to add more technical debt, I decided to add the user authentication behavior in the `feature/muiv5` branch.
The new screens are independent enough that I just added them, knowing that I still had work to do to port the rest of the UI from muiv4 to muiv5. The new screens use muiv5 components, and so far all was fine. All this was in the `feature/muiv5` branch.
Then the world changed -- my (small) team decided that we really needed to make some immediate changes in the appearance of the front end (rendering a map with different colors, for example). That couldn't wait for the muiv5 project. I did those in a different feature branch called `features/public_20210922` -- it was branched from the public server on 22-Sep-2021 (almost a year ago). Note the misspelling of the branch name -- it should be `feature/public-20210922`, but that's a different story.
I chose these two branches in hopes of keeping these changes separate from each other.
As I wrapped up the rendering changes in early 2022 (funny how a "1-2 week" project always turns into "2-3 month"), we determined that it was important to add completely new and very challenging behavior to the system. I did frontend pieces of that work in the `features/public_20210922` branch, again in the hopes of keeping them separated from the delayed user authentication and MUI migration that were in the `feature/muiv5` branch.
A few weeks ago, the changes in `features/public_20210922` were finished, everything worked, and everything was deployed. All was fine.
It was the first attempted merge -- from features/public_20210922 to `master` -- that derailed me. Somehow (I have no idea how) the `feature/muiv5` changes were already in the `master`.
I thus got a long list of merge conflicts. That's when I dove into the `branches` screen to try and sort things out. What it did was confuse me even more.
I spent about 2 days laboriously plodding through dozens of merge conflicts, making what appeared to be the obvious choices. After each pass, when I tried to run the app, more problems were revealed. I gave up after about a half-dozen restarts.
Here is what ultimately worked for me:
I now have what I wanted in my new repo. I have all the branches that were in the original repo, and my `master` is in a known-good state.
This is very close to what I would have done had I not had any version control at all.
I am the only developer committing to this repo. In a particular working directory, I do a "git add .", "git commit -m ..." and "git push" at least once a day. At least I can still reconstruct the daily changes I've made over the past two+ years.
Nevertheless, this particular "Branches" screen and -- so far as I can tell -- the entire "feature branch" workflow is a disaster.
At least for the foreseeable future -- certainly until a second developer joins the team -- I intend to use `master` for ALL my changes. The happy talk about branches, workflows, and so on strikes me as marketing material intended to sell products rather than actual robust and working practices that reasonably competent developer can do on a daily basis.
Basically, the UI tries to tell you couple of things:
So now you have code changes in both your `master` & `feature/public_20210922/byron` branch, and you need to ask yourself which of the changes you need to keep.
This article gives a good explanation about git merge strategies and and I recommend you choose one which suites you best from there.
Going forward, to avoid such issues, I highly recommend to limit the feature branches lifetime, preferably, till nearest weekend. Small changes are easier to merge, easier to review, easier to test and statistically, include less bug :)
Great comment @Erez Maadani ! This kind of out-of-sync scenario happens quite often in larger teams as 'master' or 'main' evolve quickly. I found this strategy the easiest:
Going forward as @Erez Maadani suggested, perform steps 1 - 4 regularly, perhaps even first thing in the morning (after coffee of course, in case there are merge conflicts to go through)
// Izymes (We build apps that turbo-charge team velocity through contextual automation.)
Beginning on April 4th, we will be implementing push limits. This means that your push cannot be completed if it is over 3.5 GB. If you do attempt to complete a push that is over 3.5 GB, it will fail...