> 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
