0

I've been asked to work with an analytics team whose main deliverables consist of Tableau dashboard files (which are XML). They are looking to develop some automation and best practices around versioning and deployment, and I am attempting to get them set up to use repositories and pipelines in Azure DevOps (their organization's standard).

I am attempting to set up a repository strategy with development similar to what is described here. The team will have an infinitely-lived main branch representing whatever is currently in production, an infinitely-lived development branch for changes not yet pushed to production, and short-lived feature branches created to make updates and additions. I am trying to create a proof of concept but am running into challenges when trying to complete merges from development into main.

I started to make a proof of concept by creating the empty repository with main and then creating development from the main branch. Then, I created the initial branch from development, and committed a test Tableau XML file to the initial branch. I merged initial into development, completed the PR, deleted initial, then merged development into main (but did not delete development). So far so good.

Then I created update from development, and updated the Tableau file. I merged into development, completed the PR, and deleted update with no issue. However, if I now attempt to merge development into main, I have a merge conflict. The process is attempting to merge all the commits on development into main, including the creation of the (monolithic) Tableau file, but there is already a commit on main that creates that file from the prior PR. So I am getting a merge conflict.

How can I create a merge strategy to ensure that I am only merging the incremental changes into main after the last merge of development into main ? I only need the commit that updates the file to merge into main at this point, not all the commits since the development branch diverged from main at the beginning of the repo's creation.

Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
mikstravaganza
  • 27
  • 8
  • 2
    I don't think there is any standard definition of a "monolithic" file. Do you mean a very large file? The usual thing to do when you have conflicts is to resolve them. – topsail May 06 '23 at 22:05
  • 1
    "then merged development into main" *how* did you merge development into main? " if I now attempt to merge development into main, I have a merge conflict" sounds like maybe you squashed those commits. In that case the old commits and the new commits no longer match. "and then creating development from the main branch" I see no strong motivation for development at all. Why not just have `main`? – erik258 May 06 '23 at 22:24
  • Merges are always painful, you can never work around that, that is why there is a note on top of the link you shared and my comment and some above. Check TBD, also check my post on how to handle that - https://worklifenotes.com/2022/11/02/on-feature-flags/ – taleodor May 07 '23 at 03:32
  • you mention a branch called "initial", was that ever merged into "development"? Merges only happens if you merge into a branch, and that branch has commits which doesn't exist in the branch you are merging into it, this is why you should never get a merge conflict if you create a master branch, from that creates a development branch, and only ever updates master by merging development into it. – Kim May 07 '23 at 07:34
  • 1
    @erik258 -- you were correct, the issue was that a squash merge was being performed. Changing the merge type resolved the issue. As far as the reason for `development`, I didn't go into detail in the post but there will be different deployments to different systems based on merges into those branches. – mikstravaganza May 09 '23 at 03:07
  • @topsail You're correct, I meant more along the lines of 'atomic.' It's not really feasible to handle merge conflicts within the XML files published by Tableau. Thankfully the problem was an incorrect merge strategy, where squashing was causing the intermediate commits to be lost and resulting in the conflict. – mikstravaganza May 09 '23 at 03:14

1 Answers1

0

The branching model from your Link is GitFlow. GitFlow uses quite a lot of merges throughout the lifecycle of branches. As already stated in the comments, try starting with a simpler model, like e.g. Release Flow.

As for the desired outcome, what exactly do you wish to achieve? I read from your question that you wish to keep the files from development as is and merge them directly to main? In this case you can use merge with strategy, which will overwrite all merge conflicts with the version from development.

To merge recursively and resolve by using development:

git checkout main
git merge -X theirs development

Read this similar topic: Is there a "theirs" version of "git merge -s ours"?

And also take a look at: https://git-scm.com/docs/merge-strategies

Mario Dietner
  • 566
  • 2
  • 9