Работать над веткой Git Feature и использовать (?) Одновременно - PullRequest
0 голосов
/ 30 ноября 2010

Я новичок в Git, и иногда я работаю над веткой функций (скажем, добавляя библиотеку A), а также работаю над программой B, которая ее использует (которую я называю веткой use, возможно, есть более подходящее слово) , Итак, в прошлом я имел две отдельные ветви: работайте над веткой функций, пока не получится, что она может работать, затем начните использовать API в ветке использования, объедините ветку функций и посмотрите, работает ли она. Если это не работает, я возвращаюсь к ветви функций, исправляю проблему, объединяю и повторяю. Это лучший способ сделать это?

Моя цель состоит в том, чтобы отделить ветвь функций от любой реализации, которая ее использует (хотя я полагаю, что даже это подлежит обсуждению). То, о чем я также подумал позже, - это предположить, что я редактирую ограниченное количество файлов, и я могу просто сделать «исправление» изменений в ветви использования и использовать «git checkout» в ветви функций, чтобы вернуть только изменения библиотеки.

То, что я действительно хочу, это работать в одном рабочем пространстве, но указать, что эти файлы принадлежат ветви A, и эти файлы принадлежат ветви B и могут фиксировать их отдельно. (Я могу представить себе реализацию, в которой вы указываете 2 (или n) ветви для объединения в псевдо ветку, предполагая, что вы не изменяете одни и те же файлы. Затем, когда вы изменяете файлы, находящиеся в одной ветви, вы можете зафиксировать только эти файлы в эта ветвь (и если вы изменяете новые файлы, вы должны указать, к какой ветке этот файл «принадлежит»). Насколько я знаю, это может противоречить тому, как работает Git, но я не знаю этого достаточно, чтобы рассказать. :)

Мысли

Разъяснение / Дополнение:

Это одна программа в одном репозитории (хотя решением могут быть два репозитория) Есть две ветви, с которыми я сейчас работаю

Пример (на самом деле не то, что я делаю :)): Я пишу программу для генерации случайного числа, а затем записать его в файл. Итак, моя основная программа находится в своей собственной ветке (то, что я называю своей веткой 'use'). Моя основная программа просто:

MyFileApi :: Write ("myfile", random ());

где random () - это какой-то системный API, который уже существует, но MyFileApi :: Write - это новая функция, которую я разрабатываю (поэтому моя программа использует эту новую функцию). В моей «ветке функций» я сказал заголовочный файл и реализацию для MyFileApi :: Write. Итак, я написал некоторую реализацию MyFileApi :: Write, но я хочу протестировать ее, используя мою новую программу записи файлов случайных чисел (вероятно, было бы лучше написать тесты специально для этого API, но я ленивый и тестирование в моей программе, которая использует код). Так что я делал слияние в моей MyFileApi :: Записать изменения в мою ветку 'use', тестировать его, видеть, что оно не работает, возвращаться к моей функциональной ветке, исправлять проблему, снова объединяться, повторять и т.д. ...

Ответы [ 2 ]

2 голосов
/ 30 ноября 2010

Ничто не мешает вам дважды клонировать репозиторий, поэтому у вас есть два локальных рабочих пространства, по одному для каждой ветви.Если выходные данные сборки из ветви возможностей должны находиться в ветви использования, вы всегда можете использовать символические ссылки (при условии, что вы работаете в ОС Unixy) и .gitignore их из ветви использования.

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

1 голос
/ 30 ноября 2010

Я не гит-гуру, но теоретически вы можете иметь столько веток, сколько захотите. Что бы я предложил, если у вас есть библиотека A в своем собственном git-репо и программа B (которая использует A) в своем собственном git-репо:

  • создать ветку (например, "new_features") в A
  • измените свой код, попробуйте скомпилировать / связать, исправить ошибки
  • создать ветку (используйте то же имя, чтобы показать, что будет тестироваться - "new_features") в B
  • изменить код в B, чтобы использовать новые / измененные функции, которые вы добавили / изменили в A
  • компиляция / ссылка / тестирование B

Вам действительно нужно иметь ветвь в вашей программе B, если изменения, которые вы делаете в библиотеке A, изменяют ее открытый набор функций / переменных. Если все, что вы делаете, это вносите изменения в «фоновый» код (то есть оставляете открытые функции / переменные такими, какие они есть, улучшая алгоритмы, использование памяти и т. Д. В этих функциях), вам не обязательно нужна ветвь для вашего B программа.

В любом случае, если вы разветвляете оба проекта, сначала перейдите в свою библиотеку A и объедините ветку обратно в ствол. Компиляция / ссылка / исправить ошибки. Затем перейдите к B и объедините его соответствующую ветку в ствол этого проекта. Опять же, скомпилируйте / связать / исправить ошибки.

На самом деле мне нужно сделать что-то подобное с одним из проектов, которые я сейчас разрабатываю; имеет основное приложение, которое использует различные общие библиотеки. Мы используем SVN, но концепции по сути одинаковы.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...