Re: "groups of files" in Git?
- Date: Tue, 11 Jul 2017 22:20:37 +0200
- From: Lars Schneider <larsxschneider@xxxxxxxxx>
- Subject: Re: "groups of files" in Git?
> 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:
>>> 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
>>> 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`  to remove all
>> commits that are not relevant for the feature. Alternatively you could
>> cherry pick the relevant commits  if this is faster.
>> I wonder what others think about this solution. Maybe there is a better
>> solution that I overlooked?
>> - Lars
>>  https://robots.thoughtbot.com/git-interactive-rebase-squash-amend-rewriting-history
>>  http://think-like-a-git.net/sections/rebase-from-the-ground-up/cherry-picking-explained.html
> On 11 Jul 2017, at 19:54, Nikolay Shustov <nikolay.shustov@xxxxxxxxx> wrote:
> 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.
I see. Why so complicated with gitattributes then?
How about this:
Let's say you start working on featureX that affects file1 and file2
and featureY that affects file8 and file9
1. Create aliases to add the files:
$ git config --local alias.featx 'add file1 file2'
$ git config --local alias.featy 'add file8 file9'
2. Work on the features. Whenever you have something ready for featureX
$ git featx
$ git commit
Whenever you have something ready for featureY run this:
$ git featy
$ git commit
Wouldn't that work?