Use Git to work on several features simultaneously

Sometimes you need to switch between different tasks with things left unfinished and then return back to them. DataSpell provides you with a few ways to conveniently work on several different features without losing your work:

You can stash or shelve pending changes.
Stashing changes is very similar to shelving. The only difference is in the way patches are generated and applied. Stashes are generated by Git, and can be applied from within DataSpell, or outside it. Patches with shelved changes are generated by DataSpell and are also applied through the IDE. Also, stashing involves all uncommitted changes, while when you put changes to a shelf, you can select some of the local changes instead of shelving them all.
You can keep changes related to different tasks or features in different changelists.
You can create branches to work on different unrelated features.

Shelve changes

Shelving is temporarily storing pending changes you have not committed yet. This is useful, for example, if you need to switch to another task, and you want to set your changes aside to work on them later.

With DataSpell, you can shelve both separate files and entire changelists.

Once shelved, a change can be applied as many times as you need.

Shelve changes

In the Commit tool window Alt+0, right-click the files or the changelist you want to put to a shelf and select Shelve changes from the context menu.
In the Shelve Changes dialog, review the list of modified files.
In the Commit Message field, enter the name of the shelf to be created and click the Shelve Changes button.

You can also shelve changes silently, without displaying the Shelve Changes dialog. To do this, select a file or a changelist you want to shelve, and click the Shelve Silently icon on the toolbar, or press Control+Shift+H. The name of the changelist containing the changes you want to shelve will be used as the shelf name.

To avoid ending up with numerous shelves with the same name (such as Default, for example), you can drag a file or a changelist from the Commit to <branch> tab to the Shelf tab of the Commit tool window, wait a second until it's activated, and edit the new shelf name on-the-fly when you release the mouse button.

Unshelve changes

Unshelving is moving postponed changes from a shelf to a pending changelist. Unshelved changes can be filtered out from view or removed from the shelf.

In the Shelf tab, select the changelist or the files you want to unshelve.
Press Control+Shift+U or choose Unshelve from the context menu of the selection.
In the Unshelve Changes dialog, specify the changelist you want to restore the unshelved changes to in the Name field. You can select an existing changelist from the list or enter the name for a new changelist to be created containing the unshelved changes. You can enter the description of the new changelist in the Comment field (optional).
If you want to make the new changelist active, select Set active. Otherwise, the current active changelist remains active.
If you want DataSpell to preserve the context of a task associated with the new changelist on its deactivation and restore the context when the changelist becomes active, select the Track context option (see tasks and contexts for details).
If you want to remove the changes you are about to unshelve, select the Remove successfully applied files from the shelf option. The unshelved files will be removed from this shelf and added to another changelist and marked as applied. They will not be removed completely until deleted explicitly by clicking on the toolbar, or selecting Clean Already Unshelved from the context menu.
If you've deleted unshelved files by accident, you can view and restore them from the Recently Deleted node.
Click OK. If conflicts occur between the patched version and the current version, resolve them as described in Resolve conflicts.

You can also unshelve changes silently, without displaying the Unshelve Changes dialog. To do this, select a file or a changelist you want to unshelve, and click the Unshelve Silently icon on the toolbar, or press Control+Alt+U. The unshelved files will be moved to the active pending changelist.

You can also drag a file or a changelist from the Shelf tab to the Commit to <branch> tab to unshelve it silently. If you drag it holding the Control key, it will be copied to the Commit to branch tab instead of being removed from the shelf.

Discard shelved changes

In the Shelf view, select the changelist that contains the changes you do not want to keep any more.
Right-click it and choose Delete from the context menu, or press Delete.

Restore unshelved changes

DataSpell lets you reapply unshelved changes if necessary. All unshelved changes can be reused until they are removed explicitly by clicking the icon on the toolbar, or selecting Clean Already Unshelved from the context menu.

Make sure that the Show Already Unshelved toolbar option is enabled.
Select the files or the shelf you want to restore.
From the context menu of the selection, choose Restore.

Apply external patches

You can import patches created inside or outside DataSpell and apply them as shelved changes.

In the Shelf view, choose Import Patches from the context menu.
In the dialog that opens, select the patch file to apply. The selected patch appears in the Shelf tab as a shelf.
Select the newly added shelf with the patch and choose Unshelve Changes from the context menu of the selection.

Automatically shelve base revision

It may be useful to configure DataSpell to always shelve base revisions of files that are under Git version control.

Press Control+Alt+S to open the IDE settings and select Version Control | Shelf.
Select the Shelve base revisions of files under distributed version control systems option.
If this option is enabled, the base revision of files will be saved to a shelf that will be used during a 3-way merge if applying a shelf leads to conflicts. If it is disabled, DataSpell will look for the base revision in the project history, which may take a while; moreover, the revision that the conflicting shelf was based on may be missing (for example, if the history was changed as a result of the rebase operation).

Change the default shelf location

By default, the shelf directory is located under your project directory. However, you may want to change the default shelf location. This can be useful, for example, if you want to avoid deleting shelves accidentally when cleaning up your working copy, or if you want to store them in a separate repository allowing shelves to be shared among your team members.

Press Control+Alt+S to open the IDE settings and select Version Control | Shelf.
Click Change Shelves Location and specify the new location in the dialog that opens.
If necessary, select Move shelves to the new location to move existing shelves to the new directory.

Watch this video tutorial on how to benefit from shelves to be able to switch to a different task without losing unfinished work:

Stash changes

Sometimes it may be necessary to revert your working copy to match the HEAD commit but you do not want to lose the work you have already done. This may happen if you learn that there are upstream changes that are possibly relevant to what you are doing, or if you need to make some urgent fixes.

Stashing involves recording the difference between the HEAD commit and the current state of the working directory (stash). Changes to the index can be stashed as well.

Unstashing involves applying a stored stash to a branch.

You can apply a stash to an existing branch or create a new branch on its basis.

A stash can be applied as many times as you need to any branch you need, just switch to the required branch. Keep in mind that:

Applying a stash after a series of commits results in conflicts that need to be resolved.
You cannot apply a stash to a "dirty" working copy, that is a working copy with uncommitted changes.

Save changes to a stash

From the main menu, choose Git | Uncommitted Changes | Stash Changes.
In the Stash dialog that opens, select the appropriate Git root and make sure that the correct branch is checked out.
In the Message field describe the changes you are about to stash.
To stash local changes and bring the changes staged in the index to your working tree for examination and testing, select the Keep index option.
Click Create Stash.

Apply a stash

From the main menu, choose Git | Uncommitted Changes | Unstash Changes.
Select the Git root where you want to apply a stash, and make sure that the correct branch is checked out.
Select the stash you want to apply from the list.
If you want to check which files are affected in the selected stash, click View.
To remove the selected stash after it is applied, select the Pop stash option.
To apply stashed index modifications as well, select the Reinstate Index option.
If you want to create a new branch on the basis of the selected stash instead of applying it to the branch that is currently checked out, type the name of that branch in the As new branch field.

To remove a stash, select it in the list and click Drop. To remove all stashes, click Clear.

Group changes into different changelists

When you are working on several related features, you may find it convenient to group changes into different changelists. This approach has its pros and cons as opposed to using feature branches to work on multiple tasks.

Pros:

You can easily switch between different logical sets of changes and commit them separately from each other.
Unlike using branches for the same purpose, you have all your changes at hand without having to switch between branches which can take a while if your project is really large.
It's convenient to test how different features work together.
You can remote-run a changelist on a build server.

Cons:

While using changelists may seem a more lightweight option compared to branches, it's not safe as there's no backup for your changes until you have committed and pushed them. If something happens to your local working copy, all your changes will be lost as they are not part of Git project history.
No atomic testing of features is possible.
No collaboration on the same feature is possible. Also, you cannot make contributions from different machines unless you send patches with changes through email, which may not be very convenient.

All changelists are displayed in the Commit window of the Commit to <branch> tab. All modified files are automatically placed in the active changelist, which is the Changes changelist unless you have created a different one and made it active.

Changelists are displayed in the Commit window . Initially, there is a single default changelist. It is called Changes, all new changes are automatically placed in this changelist. There is also an Unversioned Files changelist that groups newly created files that haven't been added to Git yet.

You can create as many changelists as needed and make any of them active at any moment. You can move any uncommitted changes to any changelist.

Create a new changelist

In the Local Changes view, click on the toolbar and select New Changelist.
In the New Changelist dialog, specify the name of the new changelist, and add a description (optional).

Set the active changelist

In the Local Changes view, select a non-active changelist and press Control+Space or right-click it and choose Set Active Changelist from the context menu. All new changes will be automatically placed in this changelist.

Move changes between changelists

In the Local Changes view, select the changes that you want to move to another changelist.
Right-click the selection or click on the toolbar and choose Move to Another Changelist Alt+Shift+M.
In the dialog that opens, select an existing changelist or enter the name for a new changelist.
You can choose to make the target changelist active and to track context for it (DataSpell will save the context associated with this changelist, and will restore it when this changelist becomes active).

Delete a changelist

Right-click a changelist and choose Delete Changelist from the context menu.

Use feature branches

A branch in Git represents an independent line of development, so if you are working on a separate feature that you want to complete and test before you are ready to share the results of your work and integrate them into master, doing it in a feature branch is the best solution. This way you can make sure unstable code is not committed to the main code base of your project, and you can easily switch to other tasks if necessary.

Pros:

As opposed to using changelists to group changes, using feature branches is safe. After you've committed changes to Git, they become part of Git project history, so you can always restore your commit through Git reflog even if you corrupt your working tree. After you've pushed your changes, they are backed up.
You can develop parallel non-related features and test them atomically.
When you've finished development in your branch, you can reorder or squash commits, so that your history is linear and clean.
It is easy to collaborate on your feature, or develop it from different machines.

Cons:

It can take time to switch branches on really large projects.
It's not very convenient to test related features together.
You have to learn a workflow for using feature branches and integrating your changes into the main code base.

There are two major approaches for using feature branches and integrating your changes into the main code base:

the merge option
the rebase option

Use merge to integrate changes from a feature branch

The major benefit of the merge option is full traceability, as commits merged into the main code base preserve their original hash and author, and all commits that are part of one feature can be grouped together.

This workflow is good for projects where committing changes to the main code base involves pull requests or an hierarchical approval procedure, as existing branches are not changed in any way.

The main drawback of this approach is that extraneous merge commits are created each time you need to incorporate changes, which intensely pollutes project history and makes it difficult to read.

Create a branch for your separate line of development.
Commit your changes while you develop.
Push your branch to a remote repository. This should be done for backup, and so that you can collaborate or work from different machines.
Switch to a different branch when you need to perform work that is not related to your feature.
Have your feature reviewed and tested, and make the necessary fixes.
When you are ready to integrate the results of your work into the main branch (for example master), do the following:
1. Merge your feature branch into the main code base.
2. Delete the feature branch.
3. Push.

Use rebase to integrate changes from a feature branch

The major benefit of this option is that you get a clean project history that is easy for others to read and understand. Your log does not contain unnecessary merge commits produced by the merge operation, and you get linear history that is easy to navigate and search through.

When deciding to adopt this workflow, you should keep in mind, however, that rebase rewrites project history as it creates new commits for each commit in the original feature branch, so they will have different hashes, which obstructs traceability.

Create a branch for your separate line of development.
Commit your changes often while you develop.
Push your branch to a remote repository. This should be done for backup, and so that you can collaborate or work from different machines.
Rebase your feature branch onto master from time to time. It only makes sense to do this if your feature branch is a long one. This is useful to:
- make sure your feature branch and master do not fall too far apart.
- avoid resolving numerous conflicts when you finally integrate your changes into the main code base. When you rebase regularly, you can resolve conflicts iteratively and do not end up struggling with a long diff.
- speed up checking out branches, as switching between branches gets slower as soon as they diverge sufficiently.
Rebasing involves the following steps:
1. Fetch changes from the remote, or pull changes into the master branch.
2. Rebase your branch onto master.
3. Force push the results of the rebase operation to your feature branch.
Switch to master when you need to perform work that is not related to your feature. When you turn back to your feature branch, perform Checkout and Rebase onto Current.
Have your feature reviewed and tested, and make the necessary fixes.
Perform Interactive Rebase when your feature has been completed. This allows you to reorder and squash commits to make your feature branch history look nice and clean.
When you are ready to integrate the results of your work into the main branch (for example master), do the following:
1. Checkout the master branch.
2. Merge your branch with master. Since master has not diverged, Git will just move the pointer forward to the latest commit of the feature branch instead of creating a new merge commit (this is referred to as a fast-forward merge).
3. Delete the feature branch.
4. Push.

Last modified: 30 March 2023