2013-08-17 2 views
3

Я начал небольшой проект, за которым последовал Git. Со временем проект вырос, и теперь основной папке нужна большая реорганизация.Переместить файл в Git с помощью ветвей

Это Android проект так в данный момент у меня есть эта структура:

/myProject/ 
    +-- AndroidManifest.xml 
    +-- res/ 
    +-- src/ 
    +-- ServerPart/ 
    +-- [other folders and files] 

Теперь я хотел бы перейти к структуре, как это:

/myProject/ 
    +-- android/ 
      +-- AndroidApplication/ 
        +-- AndroidManifest.xml 
        +-- res/ 
        +-- src/ 
      +-- AndroidApplicationTest/ 
    +-- server/ 
    +-- aFolderwithOtherFiles/ 

Прежде всего, если у вас есть некоторые рекомендации по лучшей структуре (лучшая практика) не стесняйтесь.

Проблема в том, что у меня есть несколько ветвей. Если я делаю эту операцию на главной ветви, например, когда я иду делать проверку на другой ветке, моя структура взорвется (и Eclipse может не оценить ее).

Есть ли решение для этого рефакторинга и адаптации моих ветвей, чтобы «дать» им эту новую структуру?

ответ

1

'Слить конфликты, если слишком много изменений, должны быть применены во время перебазирования. Как правило, вы можете помочь git, не переустанавливая напрямую, чтобы справиться, но выполнять перестановки на меньших шагах от фиксации до фиксации.

На самом низком уровне git не знает о «перемещениях файлов». Он знает только об удалении и создании нового файла. Однако, если оба происходят при одной и той же фиксации, и удаленный и вновь созданный файл достаточно схожи, однако git предполагает, что фактически произошло «перемещение файла» и ведет себя соответствующим образом (например, при применении коммитов во время переустановки).

Итак, идти, как это:

  • Разделите реорганизацию на несколько коммитов, каждый из которых не более 50-70 файлов. Это помогает правильно распознавать движения.

  • Не делать любых других изменений, но только файл перемещается в этих фиксациях! Разрешено только изменение имени нового пакета, если исходные коды меняют пакет Java.

  • Нанести два тега в свой проект: «premoves» до последней фиксации перед тем движение совершает, «postmoves» до последнего из движущаяся совершающего. Я сделал это в gitk.

Теперь у вас есть все ветви вашей функции перед фиксацией с тегом «premoves». Выполните переустановки в три этапа:

1) Восстановите ветвь до фиксации «премокает». Поскольку раньше не было файлов, это «нормальная» перестановка со всеми обычными колокольчиками и свистами.

2) Теперь выполните «gm rebate postmoves». Это переводит вашу ветвь на реструктуризацию. Поскольку основная ветвь содержит только перемещения файлов, а ваша ветка свойств содержит фактические изменения содержимого в файлах, git должен иметь возможность обрабатывать ситуацию автоматически в значительной степени. Тем не менее, вы получите конфликты слияния на файлы, которые вы удалили в ветви функции.

Решите эти конфликты слияния вручную, указав, что удаленный файл ветки функции также должен быть удален на ветке реструктурированной функции (помните, git не знает о семантике. Он просто видит: «С одной стороны, файл был перемещен, а с другой - удален. Я не знаю, что делать ».) Я сделал это в git gui, произнеся« Take remote version »(удаленный? local?) Тот, который показан в окне diff как «DELETED»)

После этой перезагрузки все файлы, которые вы изменили на ветке функций, должны находиться в реструктурированной позиции со всеми их изменениями. Удаленные файлы ветки функции все еще удаляются. Остается только проблема: новые файлы в ветви функции.

Эти новые файлы, вам нужно переместить их вручную в правильное положение. Помните, git только видит файлы, он не имеет понятия о «перемещении структур каталогов вокруг». Итак, переместите ваши новые файлы в ветви свойств в их новые правильные позиции и примените git-коммиты для них.

Я бы предложил совершить эти перемещения файлов для каждого файла отдельно, а затем использовать «git rebase -i» и «fixup» файл move commit с последним фиксатором ветки функции, которая коснулась файла. Это предотвращает слишком много загромождения.

3) После того, как все это сделано, выполните окончательный «мастер переустановки git» (или что-то еще). Это теперь также стандартная rebase, поскольку реструктуризация уже произошла на ветке функций.

+0

Ваше решение очень интересно и эффективно, большое вам спасибо! – WaZaA

1

Вы должны использовать git mv в главной ветке, чтобы перемещать вещи вокруг.

Когда вы будете готовы применить эти вещи к своим филиалам, вам нужно будет добавить и внести изменения. Затем на каждой ветке вам нужно будет проверить, а затем я, вероятно, сделаю git rebase master

Это применит ваши изменения поверх структуры папок.

Конечно, любой код, который у вас есть, зависит от текущей структуры, необходимо будет изменить.

Некоторые команды могут выглядеть следующим образом: возникают

git mv AndroidManifest.xml android 
mkdir android/AndroidApplicationTest 
touch android/AndroidApplicationTest/.gitkeep 
git add . 
git mv ServerPart server 
git status 
git add . 
git commit -m'Restructured application' 
git checkout dev 
git rebase master 
First, rewinding head to replay your work on top of it... 
Fast-forwarded dev to master. 
+0

С помощью этого метода, когда я делаю 'git rebase master', у многих конфликтов есть конфликты: некоторые файлы отображаются как« оба удаленные », и я не понимаю, почему ... Однако я думаю, что это« лучший «решение, даже если многие совершают конфликт. – WaZaA

Смежные вопросы