Невозможно понять ветку Git, объединить и перебазировать
Я знаю ветку, в которой говорится, что rebase предназначен для небольших изменений teamMates, в то время как merge для больших изменений.
Я держу три Gits из трех товарищей по команде в следующей структуре каталогов, где у всех нас одинаковый исходный код:
project
| - I
| - myTeamMate1
| - myTeamMate2
Ветви не в том же Git. Это означает, что я не могу использовать rebase и merge. Я использовал vimdiff для синхронизации изменений между teamMates. Однако это отнимает много времени.
Я безуспешно пытался создать следующую структуру каталогов, где все ветви находятся под одним Git:
project
| - I - myTeamMate1 - myTeamMate2
Тем не менее, я запускаю команду клонирования для себя и для моего партнера по команде:
git clone <url>
и я получаю сообщение об ошибке после запуска второго клона для моего партнера по команде
fatal: destination path 'dotFiles' already exists and is not an empty directory.
Какую структуру каталогов я должен использовать с командой из 3 человек, чтобы я мог использовать rebase а также merge команды?
4 ответа
Просто некоторые другие мысли, чтобы завершить ответ Самуила.
В отличие от SVN, ветви и каталоги в Git совершенно не связаны: наличие 3 филиалов (по одному на каждого члена команды) не означает 3 каталога. Это не то, что вы имели в виду в своем вопросе (поскольку ваши каталоги на самом деле имеют 3 корня для 3 Git-репозиториев), но я предпочитаю упомянуть об этом на всякий случай;)
Будучи DVCS, эти 3 репозитория могут быть где угодно (не в 3 каталогах на одном компьютере). Если они доступны через путь UNC (
\\desktop\path\to\repo) их можно обозначить как удаленные.Git clone позволяет вам получать ссылки на удаленные ветви, но не создает отслеживание локальных веток, позволяющее вам получать работу ваших коллег. Рубиновый модуль " удаленные ветки" может помочь.
Будьте осторожны с ребазом, поскольку он переписывает SHA-1 вашей ветки (поскольку вы переигрываете свои коммиты поверх другой ветки): если ваши товарищи по команде основывают свои слияния на ваших ветках, им придется каждый раз объединять все ваши коммиты, даже те уже слил!
В этом случае лучше всего иметь 2 ветки:- рабочая ветвь, которую вы используете для своей разработки и перебазирования (для интеграции работ ваших коллег, хотя даже эта операция может выполняться в отдельной ветке)
- общедоступная ветвь публикации, в которой вы объединяете только свою стабильную работу и которая затем может использоваться другими удаленными репозиториями в качестве источника для слияний.
Тот факт, что они не находятся в том же мерзавце, что и вы, никак не ограничивает вас. Git распространяется, что означает, что вы можете выбирать между этими репозиториями, объединять, перебазировать и так далее.
смотреть на git remote --help чтобы увидеть, как вы можете назвать свои репозитории товарищей по команде в своих, чтобы вы могли легко импортировать их изменения, делать ребазинг или выполнять слияния. Вам не нужно менять структуру каталогов, ваша - удобна в использовании.
Примеры кода
Для отслеживания удаленной ветки
git remote add -t master Hnr git://github.com/userName/files.git
Это не скачать вам ветку. Он просто редактирует файл.git/config и добавляет несколько строк, которые сообщают Git, как, где и как получить данные удаленно.
Чтобы получить ветку вашего teamMate, запустите
git fetch Hnr
Чтобы увидеть, что у вас действительно есть ветка teamMates, запустите
git branch -a
или видеть только ветви ваших друзей
git branch -r
Изначально две вышеупомянутые команды вызвали у меня замешательство, поскольку я их не знал. Это заставило меня попробовать другие ненужные команды, чтобы иметь ветви для меня.
2-й способ получить ветку вашего друга
Тем не менее, обратите внимание, что вы можете использовать git-clone, чтобы поместить код вашего друга в отдельный каталог следующим образом
git clone UrlAtGithub
Тогда вы, очевидно, можете использовать Git-remote, как указано выше, чтобы иметь ветку в вашем репозитории Git:
git remote add master Hnr PATH/ToYourFriendRepo.git
Вывод: вы можете использовать два способа получить ветку вашего teamMate, либо с помощью git-clone, либо без него. Оба способа требуют использования git remote add, Преимущество последнего заключается в том, что вам нужно выполнить на одну команду меньше. Первый из них снова дает вам полное репо вашего teamMates на ваш жесткий диск.
Пожалуйста, ознакомьтесь с руководствами Git о том, как вы можете обновить свои удаленные ветки. (Примечание: удаленный филиал может находиться на вашем компьютере. Он не обязательно должен быть на удаленном компьютере. Ваш филиал также может быть удаленным филиалом, но это ограничивает ваш рабочий процесс.)
Затем вы можете захотеть объединить конкретный файл вашего друга с вашей веткой. В этом случае достаточно знать 5 первых букв коммита вашего друга, чтобы объединить файл.
[Я не уверен, как вы можете сделать следующее:] Вам нужно запустить, например,
git merge 76a32
Вы можете получить следующий вывод
CONFLICT (add/add): Merge conflict in shells/externalPrograms
Auto-merging shells/smallApps/extract
CONFLICT (add/add): Merge conflict in shells/smallApps/extract
Auto-merging shells/smallApps/extract~
CONFLICT (add/add): Merge conflict in shells/smallApps/extract~
Automatic merge failed; fix conflicts and then commit the result.
В этом случае ваши файлы значительно отличаются от файлов вашего друга, и Git не может решить, какой файл взять. Вам нужно запустить видимо следующее
git rebase
и вы получите
shells/smallApps/extract: needs merge
shells/smallApps/extract~: needs merge
cannot rebase: you have unstaged changes
Упражнение 1: Тем не менее, я сейчас застрял, поскольку мой тиг не показывает коммит моего друга на моем дереве Git.Как вы можете получить коммит 76a32 вашего друга на ваше дерево Git, какая ветка в вашем Git?
Возможно, теперь вы решили проблему. Проблема была в том, что я игнорировал разрешение конфликтов, о которых Git давал мне уведомления. Google снова сохраняет день на официальном сайте Git:
Если есть конфликты - например, если один и тот же файл был изменен двумя разными способами в удаленной ветви и локальной ветви - тогда вы будете предупреждены -
Следующая проблема - очистить проблемные части и снова объединить их. В ваших проблемных файлах вы видите нечто похожее на следующее - получайте удовольствие! (Наконец-то я добрался до реальных проблем;)
http://dl.getdropbox.com/u/175564/exampleGitProblemSolving.png
Проблема в различий и слияния dotFiles в Mac FileMerge
Мне нужно было обновить мой Git, так как только у самого нового Git есть команда difftool. Вы можете найти решение в теме.
Difftool позволяет запускать dotFiles в FileMerge с терминала. Вы не можете получить к ним доступ в графическом интерфейсе. Работает как
git difftool master:README dev:README
Проблема с вашей учетной записью в Github после добавления новой удаленной учетной записи
Ваша учетная запись Github, возможно, исчезла в.git/config. В этом случае вам нужно запустить следующий код
git remote add -f YourUserName UrlIn@form.git
Затем вы можете заметить, что вы не можете нормально толкать
git push origin master
Вы можете получить следующее сообщение об ошибке
fatal: 'origin' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
Вы также можете попробовать следующие команды для решения проблемы
git push Masi master
и все 3 под 2 перестановки Маси, мастер и происхождение. Однако ни одна из команд не сработала.
Упражнение 2: Как вы можете зафиксировать свою учетную запись на github, если в вашем удаленном списке есть teamMate?
Origin - это короткое имя для вашего реального внешнего git-репо, например, на Github. Содержимое вашей переменной происхождения может быть заменено другим удаленным репо. В этом случае я рекомендую вам создать новую переменную
git remote add github git@github.com:myLogin/myProject.git
Обратите внимание, что вы можете иметь origin2 вместо github. Origin - это просто соглашение по именованию репо.
Вы можете просто запустить
git push github master
У вас может быть пароль в вашем ssh-ключе. Если у вас есть, вы можете получить разрешение отказано - предупреждение. Если вы сделали, пожалуйста, смотрите ветку.
По правде говоря, я начал работать над тем, чтобы набрать хороший, длинный, подробный ответ... но мне это уже объяснили гораздо лучше, чем я мог бы по адресу http://excess.org/article/2008/07/ogre-git-tutorial/. Он охватывает использование различных веток, удаленных и слияния. Это также делается в видеопередаче, так что потратьте час, выпейте кофе и наслаждайтесь лекцией.
Специфично для вашего вопроса: вы не должны использовать настройки каталога. Git не обрабатывает ветвления с каталогами так же, как SVN с папками веток. Ветки в git - это совсем другое. Хотя вы не можете настроить центральный репозиторий (я рекомендую его), вы должны настроить одну главную ветку, к которой каждый выполняет свою окончательную, чистую работу.
В одном из моих репозиториев есть скриншот с Wikimedia Commons. В моем примере "бармен" представляет свой код только в виде фрагментов tar, поэтому я должен импортировать его сам, чтобы управлять им. "master" (показанный здесь только как remotes/elf/master) - это общедоступный репозиторий SVN, который я импортирую, и база изменений изменяется. "autocracy" - моя собственная базовая линия для кода, а "private" - это то, где я храню файл конфигурации с паролями, которыми я хочу управлять, но никогда не публикую. Проверьте временные метки на частном, и вы заметите, что они не совпадают с ветками ниже. Это потому, что я перекладываю эту ветку на "автократию" вместо слияния.
Вы заметите две отдаленные ссылки: эльф и бард. Это две мои удаленные машины с программным обеспечением. Я могу толкать и тянуть туда свои ветви, как захочу. В вашем случае у вас будут удаленные репозитории других ваших разработчиков, и они будут изменять свои собственные ветки. Просмотр учебника даст вам лучшее представление о том, как он работает. Удачи:)