-5

Persistence is an essential requirement for preferences. Developer's preferences are saved in .idea/ folder. It is recommended to add .idea/ to .gitignore to avoid merge conflicts. But then settings are lost whenever

  • Project is cloned to a new environment
  • Project settings are messed up and you want to roll back
  • New developer joins a team

I end up emailing idea.zip folder to myself to not lose my settings. This feels wrong because the whole point of Git is to track changes to files. If I can email settings, then I can email the whole project as well.

I can use some dirty hack like a separate git project for developer settings. Import settings branch, merge dev source code branch, resolve conflicts,... But this is even more manual than .idea.zip email.

What is the right way to store developer's project settings on Git, but avoid edit warring? Is there a way to tell git to version settings per developer?

Improve this question
5
  • IDE settings could be stored in a different, personal Git repository. Commented Oct 26, 2018 at 18:14
  • 2
    This pretty much answers your question: stackoverflow.com/a/11968647/3608792 Commented Oct 26, 2018 at 19:02
  • @DanWilson the answer suggests to gitignore and lose your settings. Great plan! Can gitignore source code and use emails as a source control as well (sarcasm). Commented Oct 27, 2018 at 13:34
  • @Basilevs. Sure, but this is lame workaround. Clean solution would be to have .idea/Alice .idea/Bob etc where Alice and Bob are Github usernames. Making several repos to patch Github design flaw is just bad. Commented Oct 27, 2018 at 13:40
  • 1
    @Stepan you only lose settings when you blow away your repo or clone a new one. You're making a mountain out of a mole hill IMHO. I use the same repo directory for months or years. Commented Oct 27, 2018 at 13:52

1 Answer 1

Reset to default
0

"Oh, those Russians!"

  1. "Recommended" != "Must to"
  2. If you want to share .idea, you have to share it
  3. "Share it" doesn't mean "merge it into code of project"; hint - Git have "branches"
  4. Git can use custom mergetools

Sapienti sat

Improve this answer
1
  • "Git have branches" - welcome to branching hell. I am not OK to create ten times more branches, but OK to add ten extra branches (one per developer), Also, generic branches imply three way merges, which is a nightmare. "Custom merge tools" - this is exactly my question. Commented Oct 29, 2018 at 11:54

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.