Thank you for the idea, however I am having troubles with basically maintaining the uncommitted groups of files: I would prefer the clear distinction that "those files belong to feature A" and "these files belong to feature B", before I commit anything. Committing separately every change for feature A and for feature B would probably a good option unless I have many changes and then cherry-picking the proper commits to create a single changeset for the integration would become a nightmare. On Tue, Jul 11, 2017 at 1:39 PM, Lars Schneider <larsxschneider@xxxxxxxxx> wrote: > >> On 11 Jul 2017, at 17:45, Nikolay Shustov <nikolay.shustov@xxxxxxxxx> wrote: >> >> Hi, >> I have been recently struggling with migrating my development workflow >> from Perforce to Git, all because of the following thing: >> >> I have to work on several features in the same code tree parallel, in >> the same Perforce workspace. The major reason why I cannot work on one >> feature then on another is just because I have to make sure that the >> changes in the related areas of the product play together well. >> >> With Perforce, I can have multiple changelists opened, that group the >> changed files as needed. >> >> With Git I cannot seem to finding the possibility to figure out how to >> achieve the same result. And the problem is that putting change sets >> on different Git branches (or workdirs, or whatever Git offers that >> makes the changes to be NOT in the same source tree) is not a viable >> option from me as I would have to re-build code as I re-integrate the >> changes between the branches (or whatever changes separation Git >> feature is used). >> Build takes time and resources and considering that I have to do it on >> multiple platforms (I do cross-platform development) it really >> denominates the option of not having multiple changes in the same code >> tree. >> >> Am I ignorant about some Git feature/way of using Git that would help? >> Is it worth considering adding to Git a feature like "group of files" >> that would offer some virtutal grouping of the locally changed files >> in the checked-out branch? > > Interesting question that came up at my workplace, too. > > Here is what I suggested: > 1. Keep working on a single branch and make commits for all features > 2. If you make a commit, prefix the commit message with the feature name > 3. After you are done with a feature create a new feature branch based on > your combined feature branch. Use `git rebase -i` [1] to remove all > commits that are not relevant for the feature. Alternatively you could > cherry pick the relevant commits [2] if this is faster. > > I wonder what others think about this solution. Maybe there is a better > solution that I overlooked? > > - Lars > > [1] https://robots.thoughtbot.com/git-interactive-rebase-squash-amend-rewriting-history > [2] http://think-like-a-git.net/sections/rebase-from-the-ground-up/cherry-picking-explained.html >
