Keeping of changes from one file inside two different changelists with Git and IntelliJ IDEA

Question

I'm using Git as VCS and IntelliJ IDEA as IDE.

I want to keep my local changes (those, which I won't to commit) in the changelist with the name 'local' and other changes (intended to be committed) in my default changelist. The problem occurs when I have local changes and changes that I intend to commit in the same file. In this case, before performing the commit, I need to review all changes in those files and discard all local changes.

Is there any way to keep one part of changes in a file in the first changelist and the other part in the second changelist?

Answer 1

Actually, this IS possible now with IntelliJ's new support for Git's partial commits in 2018.1. You've probably already ran in to it by now, but there are two ways (at least) to have different changes in the same file exist in different change sets.

The important thing to note in any case, is that changes that sit in an unrelated, or inactive change set, will appear with a very faint color, instead of the normal green/blue/etc highlighting when viewing a dif. The faint highlighting means that is IS a change to your working copy, but not staged with 'this' change set. (might be using the wrong nomenclature here)

The two ways to keep local changes, but continue to work on things as usual follow:

1. Simply keep existing changes to a file sitting in an inactive change set, and make further modifications to the file. The default behavior is to add any new changes to the active change set. When you go to commit this file from the active change set, the inactive changes will not be included.

2. If you need to split up existing changes to two different change sets, the way I have found to do this is mildly more tedious. Hopefully someone else knows of an even better way... The way I have done it is to shelve the changes without reverting them, move the changes to an inactive change set, and revert or manually remove the changes you want to be in the active changeset. At that point, just unshelve the changes and apply them either to the active changeset, or do not apply them to a specific change set. I'm sure this can be done in reverse order (as in, keep the file active, revert the 'inactive' changes you want to keep, then unshelve the changes to the inactive change set), or any other mix and mash.

Hopefully this helps, if you haven't already figured it out!

Answer 2

No, changelists (and version control for java in general) don't work like this. Further, I think what you're doing is probably wrong -- especially given that you have git.

Assuming you're part of a team, with a centralised shared repo somewhere that you push your changes to (though this works if you're alone pushing to github too)...

You should have a branch off master for the feature you're working on -- let's call it 'Feature-A'. On your local machine you should create a local branch off that, let's call it 'local'. So, you have this branching structure:

master
  ->   Feature-A
            ->    local

You can work and commit what you like in local -- you may push that to the shared repo for, say, backup. During this process, occasionally checkout each branch and pull the branch above it (so, in local, pull Feature-A) to ensure that you have the latest changes from master. When you're ready, you can checkout Feature-A and merge in the changes from local (this is like your double change-list). Before you start working on something new make sure that you merge your (commitable) changes from local into Feature-A. When Feature-A is ready, you can push it to the central repo and issue a pull request for master.

Basically, you should always keep what's pushable in Feature-A, and do development in 'local', merging it into Feature-A when appropriate.