Merging snapshots
In order to preserve the readability of the repository and the history of changes, it is good practice to combine multiple snapshots in the theme branches (feature / bugfix / hotfix). This can be done with the command git rebase, which moves the branch to any place in the repository (graph) with the possibility of performing certain operations on the snapshots, including joining them. Before merging snapshots, always execute the command git fetch or git pull on the branch to which you want to move the branch – usually this is the branch develop, so the one from which the theme / featurefix theme branches should originate.
An example of merging snapshots into one:
gt; git fetch
gt; git checkout feature/EXE-7-category-importer
gt; git rebase -i origin/develop
With the -i (–interactive) switch, it will be possible to select the operations to be performed on each snapshot:
reword c3c6078 EXE-7 Category importer fixup 7824ac8 EXE-7. Module skeleton fixup 44dc564 EXE-7. Added unit tests fixup a1173f1 EXE-7. Fixes in unit tests fixup eba0152 EXE-7. Added repositories fixup 5d5d6d5 EXE-7. Implemented category importer logic # Rebase 92d7e23..5d5d6d5 onto 92d7e23 (6 commands) # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x, exec = run command (the rest of the line) using shell # d, drop = remove commit # # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. # # However, if you remove everything, the rebase will be aborted. # # Note that empty commits are commented out
The first snapshot should always have a pick or reword command if you want to change the name of the snapshot. It will be merged with subsequent snapshots, which in turn must have the fixup or squash command.
When you execute the git rebase command, conflicts may occur as when merging branches to each other. In this case, we do the same as for the git merge command – we resolve the conflict, and then execute the git rebase –continue command to accept the state of the files and continue moving the branch.
Grouping snapshots of different authors.
If the branch contains many snapshots, whose authors are several people – for example, snapshots of the front-end changes and the back-end of the developer – they should be grouped by authors and merged with each other. Thanks to this we will keep the correct history of changes and it will be visible who actually modified the files.
pick c3c6078 EXE-35. (Developer A) pick 7824ac8 EXE-35. (Developer B) pick 44dc564 EXE-35. (Developer A) pick a1173f1 EXE-35. (Developer A) pick eba0152 EXE-35. (Developer A) pick 5d5d6d5 EXE-35. (Developer B)
The above change history including the changes of Developer A and Developer B should be grouped as follows:
pick c3c6078 EXE-35. (Developer A) fixup 44dc564 EXE-35. (Developer A) fixup a1173f1 EXE-35. (Developer A) fixup eba0152 EXE-35. (Developer A) pick 7824ac8 EXE-35. (Developer B) fixup 5d5d6d5 EXE-35. (Developer B)
The result of such a rebase command will be two snapshots – one with Developer A changes and the other with Developer B changes.
As you can see above, it is acceptable to change the sequence of processing individual snapshots, but you must be aware that this approach will not always work. There may be a situation where the file modification snapshot will be applied before the file that it adds to the repository.