Я пользователь SVN и сейчас изучаю Git.
В SVN я обычно оформляю репо на своей локальной машине, который включает все ветви в моем проекте, и я обычно выбирал папку для своей ветки, которая мне интересна, и работал там.
Я вижу разницу с помощью Git.
В настоящее время я клонирую репо и клонирую конкретную ветку, используя gitk.
Папка проекта содержит только содержимое этой ветви, и я не вижу все ветви, как в SVN, что немного смущает меня.
Я не могу найти простой способ увидеть все ветви в моем локальном репозитории с помощью Git.
Я хотел бы знать, является ли описанный мной процесс Git «стандартным», а некоторые - насколько правильным, или я что-то упускаю.
Также я хотел бы знать, как обрабатывать процесс, в котором мне нужно работать над двумя ветвями одновременно, например, в случае, если мне нужно сделать исправление на главном сервере, но также сохранить содержимое другой ветки.
Каковы рекомендуемые соглашения об именах, чтобы клонировать папки, включающие ветку, из репозитория в Git, например
myproject-branchname
?
git clone
больше похоже наsvnadmin hotcopy
илиsvnrdump
+,svnadmin load
чем на это похожеsvn checkout
. Сgit
, вы не спрашиваете биты и куски из в хранилище; Вы копируете весь репозиторий и работаете с ним локально, передавая изменения обратно в «исходный» репозиторий, когда и когда вам это нравится. Git и Subversion используют две совершенно разные модели для управления исходным кодом.git-flow
Ответы:
Добро пожаловать в банду!
SVN перевоспитание
Подожди немного. Хотя CVS и SVN и другие традиционные (то есть централизованные) системы контроля версий выполняют (в основном) ту же цель, что и современные (то есть распределенные) системы контроля версий, такие как Mercurial и Git, вам будет гораздо лучше изучать Git с нуля, а не пытаясь перенести рабочий процесс SVN в Git.
http://hginit.com ( вид на archive.org ) Джоэл Спольски (один из самых основателей Stack Exchange) представляет собой учебник для ртутного, не Git, но это ноль-й главы, «Subversion перевоспитания» является полезно для людей , переключающих от SVN к любой распределенной системе управления версий, так как она говорит вам , что SVN понятия вы должны (временно) ООН -Узнайте (или
stash
далеко , так как пользователи Git могли бы сказать) , чтобы быть в состоянии обернуть вокруг головы распределенного концепции системы контроля версий и идиоматические рабочие процессы, созданные для работы с ними.Таким образом, вы можете прочитать эту нулевую главу и в основном просто заменить слово «ртутный» на «Git» и тем самым должным образом подготовить себя и свой разум к Git.
Мелкий шрифт
(Вы можете пропустить это сейчас.) В то время как ртутный и Git гораздо больше похожи друг на друга , чем SVN, есть есть некоторые концептуальные различия между ними, так что некоторые из заявлений и рекомендаций в «Subversion перевоспитания» станет технически неправильно при замене "mercurial" на "Git":
В SVN все является каталогом (но вы не обязательно должны обращаться с ним как с таковым)
Но я тебя перебиваю. Ты говорил?
Если под этим вы имеете в виду, что вы извлекли корневую папку репозитория SVN (или любую другую папку, соответствующую более чем
trunk
одной ветке или более, например, в обычном макете репозитория SVNbranches
папку, содержащую все не магистральные ветви), тогда Я осмелюсь сказать, что вы, вероятно, неправильно использовали SVN (ish) или, по крайней мере, немного злоупотребили тем фактом, что ствол, ветви и теги все складываются в единое (хотя и иерархическое) пространство имен вместе с каталогами в пределах revisions / codebase.Хотя может быть заманчиво менять несколько веток SVN параллельно, но это AFAIK, а не то, как SVN предназначен для использования. (Хотя я не уверен в том, какие конкретные недостатки могут работать, как это.)
В Git только каталоги являются каталогами
Каждый клон репозитория Git сам по себе является репозиторием Git: по умолчанию он получает полную копию истории исходного репозитория, включая все ревизии, ветви и теги. Но он сохранит все, что вам нужно: Git хранит его в своей базе данных на основе файлов, расположенной в скрытой
.git/
подпапке корневой папки хранилища .Но какие скрытые файлы вы видите в папке хранилища?
Когда вы
git clone
хранилище, Git делает несколько вещей. Грубо говоря:.git/
подпапку с «базой данных».master
).Этот последний шаг означает, что Git ищет ревизию, на которую указывает эта ветвь, и распаковывает сохраненное там файловое дерево (база данных использует некоторые средства сжатия и дедупликации) в корневую папку хранилища. Эта корневая папка и все ее подпапки (кроме специальной
.git
подпапки) называются «рабочей копией» вашего репозитория. Вот где вы взаимодействуете с содержимым текущей проверенной ревизии / ветки. Это просто обычные папки и файлы. Однако для взаимодействия с самим хранилищем («база данных» ревизий и ссылок) вы используетеgit
команды.Просмотр веток Git и взаимодействие с ветками Git
Версия, которую
gitk
я получил, не может клонировать репозитории. Он может только просматривать историю репо и создавать филиалы и проверять филиалы. Также нет «клонирования» ветки. Вы можете только клонировать репозитории.Вы имели в виду, что вы клонируете репо, используя,
git clone ...
а затем, используяgitk
, проверяете ветку?Да, это довольно стандартно:
git clone ...
git checkout ...
или используйте графический инструмент, такой какgikt
Может быть:
git branch
git branch -r
или все ветви сgit branch -a
вы можете использовать
gitk
для просмотра полной истории (все метки веток и т. д., о которой знает ваше локальное хранилище), вызвав ее сКак работать с несколькими ветками параллельно
Здесь есть разные сценарии:
Новое (еще не созданное) изменение необходимо применить к нескольким веткам
Используйте этот рабочий процесс:
c
из ревизии, которая уже находится в предке всех этих ветвей (например, ревизия, которая внесла ошибку, когда изменение будет исправлено), или из ревизии, которая (включая всех ее предков) приемлема для введения в все эти ветви.c
.Для каждой ветви,
b
которая нуждается в изменении:Проверьте
b
:Объединить
c
вb
:Удалить ветку
c
:Существующее изменение необходимо в другой ветке
(... но без других изменений, внесенных в то место, где находится это изменение)
В одной ветви
a
вы хотите изменить один или несколько файлов на точное состояние, которое они имеют в другой ветвиb
a
Получить содержимое файла из ветки
b
:(За исключением
git checkout
случаев без передачи путей, это не переключит на ветвьb
, а только получит оттуда запрошенное содержимое файла. Эти файлы могут существовать или не существоватьa
. Если они есть, они перезаписываются с включенным содержимымb
.)Работая над одной веткой, вы хотите посмотреть, как обстоят дела в другой ветке
Проверьте ветку, над которой вы хотите работать.
Затем, чтобы посмотреть на другую ветку,
gitk
попытке переключить переключатели с «патча» на «дерево»)git worktree
для создания отдельного рабочего каталога того же хранилища (то есть, также используя базу данных в.git/
каталоге вашего текущего локального хранилища), где вы можете проверить эту другую веткуисточник
stash
идеально.git stash
Это хорошо, чтобы убрать незаконченную работу с дороги, например, чтобы поменять ветки и вернуться позже.Если вы не проверите каталог выше транка, в Subversion у вас обычно не все локальные ветки доступны. В Git весь контент (коммиты, сообщения, ветки и т. Д.) Всегда клонируется в каждую копию.
Не возможно, см. Выше. Вы можете
git checkout branch-name
, но не можетеgit clone something branch-name
. В Subversion ветки - это папки. В Git ветки являются указателями на коммит.Беги
git branch
. По умолчанию он показывает только локальные филиалы. Используйте,git branch --remote
чтобы увидеть удаленные ветви.источник
--single-branch
только (даже только подсказку--depth 1
). Разница между локальной и удаленной ветками, известными git, является всего лишь разновидностью метки. Удаленные ветви имеют префикс с именем удаленного источника (частоorigin
). Местные филиалы не имеют этого префикса. Но, в конце концов, данные доступны локально (если вы не сделали--single-branch
или что-то подобное). Когда вы работаетеgit checkout $branchname
с веткой, для которой нет локальной, но удаленной ветки, git автоматически устанавливает локальную ветку, «отслеживающую» удаленную.Поскольку это помечено git, я надеюсь, что мое отсутствие знаний SVN пренебрежимо мало.
Вы клонируете весь удаленный репозиторий, а не только конкретную ветку.
Репозиторий лучше всего представлять как базу данных, поэтому вы создаете копию текущего состояния удаленной базы данных. Но после этого вы работаете над своей собственной копией этой базы данных; если вы делаете коммит, вы изменяете свою локальную базу данных.
Команда
fetch
используется для синхронизации локальной базы данных с удаленной.Обычно из этой локальной базы данных вы извлекаете ветку для работы. Это не что иное, как внутренний маркер для git, с которого началась ваша текущая работа.
Скажем, вы работаете над простым репозиторием, в котором кроме ветки нет
master
, вы можете заглянуть в.git
папку, чтобы раскрыть «магию»:Предположим, что ваш последний коммит (on
master
) был182e8220b404437b9e43eb78149d31af79040c66
, вы найдете именно это подcat .git/refs/heads/master
.git checkout -b mybranch
После того, как вы откроете новую ветку , вы найдете точно такой же указатель в файлеcat .git/refs/heads/mybranch
.Ветви - это не что иное, как указатели. «Рабочий» маркер называется
HEAD
.Если вы хотите знать, где вы находитесь
HEAD
:cat .git/HEAD
который говорит, напримерref: refs/heads/mybranch
, который в свою очередь указывает (cat .git/refs/heads/mybranch
) на хеш коммита78a8a6eb6f82eae21b156b68d553dd143c6d3e6f
Фактические коммиты хранятся в
objects
папке (как это отдельная тема).Не путайте
working directory
с «git-database» в целом. Как я уже говорил выше, ваш рабочий каталог - это только снимок (может быть) подмножества.Скажем, у вас есть разные ветки, ваш рабочий каталог предназначен для работы только с этой веткой (хотя вы можете поместить работу оттуда в другое место).
Обычно, если вы хотите увидеть, какие ветви определены для проекта, у вас есть возможность
git branch
для местных филиаловgit branch --remote
для удаленных филиаловgit branch -a
для обоих(или
git branch -v
)Поскольку git является распределенной системой контроля версий, не только возможно, но и рекомендуется создавать различные ветви локально / удаленно.
Мой типичный рабочий процесс:
Когда функция завершена:
WIP
ветку (с интерактивным перебазированием) = сделать один коммит из этогоWIP
ветку с веткой возможностей и предложите (если вы работаете с github это предложение будет называться «запросом по запросу») интегрироваться в стабильную (основную) ветку.Это зависит от того, как ваш проект структурирован:
Скажем, у вас есть стабильный мастер. А функции разрабатываются только из этой стабильной ветки, поэтому обычно они находятся за веткой функций. Тогда у вас будет последний коммит на master, который будет корнем ветви возможностей.
Затем вы сделаете коммит в основной ветке и сможете решить, объединить ли обе ветви вместе или перебазировать (что является своего рода объединением для пользователей с, так сказать, сложными потребностями).
Или вы всегда можете вносить изменения в ветви (например
master
) и вставлять их в другие ветви.Это тебе решать.
Как правило, вы в конечном итоге с именем хранилища.
Но бывают случаи, когда этого не хотят:
например, вы клонируете oh-my-zsh с помощью
git clone git://github.com/robbyrussell/oh-my-zsh.git ~/.oh-my-zsh
Здесь.oh-my-zsh
прямо названа цель.источник
Git clone
фактически клонирует весь репозиторий, но устанавливает ваш рабочий каталог по умолчанию (обычно master).Вы можете видеть другие ветви, используя,
git branch
чтобы видеть локальные ветви илиgit branch -r
видеть удаленные, а затемgit checkout
переключаться на существующую ветку или создавать новую, основываясь на текущей ветке.Вы должны прочитать git документацию для получения более подробной информации, и у Atlassian есть несколько хороших статей об этом.
источник
Ветки в git и svn - это принципиально разные вещи.
В SVN филиал (или тег) является каталогом в репо.
В git ветвь (или тег) - это указатель на коммит.
С svn вы можете, если хотите, проверить корень репо. Это означает, что вы отметили каждую ветку и тег сразу. На самом деле это не обычный способ использовать SVN.
Ветвь git не является каталогом, поэтому нет эквивалента «проверке корня репо». Существует некоторая поддержка нескольких рабочих деревьев, поэтому я думаю, что вы могли бы собрать скрипт, чтобы оформить каждую ветку в одно и то же время, если бы вы действительно этого хотели, но это было бы довольно необычно.
Кроме того, с SVN существует ровно один репо. С git у каждого разработчика есть свой репо. Это означает, что разработчики могут работать в автономном режиме, но это также означает, что разные разработчики могут иметь разное представление о том, что находится в каждой ветви.
Благодаря тому, что каталоги и простая линейная модель истории svn, ветви svn имеют надежную историю. Если вы хотите узнать, что было на ветке x на дату y, вы можете легко задать этот вопрос.
С другой стороны, у веток Git нет истории. Существует «reflog», но он предназначен скорее как механизм аварийного восстановления, чем долгосрочная история. В частности, reflog не может быть прочитан удаленно и по умолчанию отключен для пустых репозиториев.
Конечно, у комитетов есть истории, но этих историй недостаточно, чтобы ответить на вопрос «что было на ветке х репо у на дату z».
Вы можете получить список всех локальных веток, набрав "git branch".
Вы можете перечислить все ветви как локальные, так и удаленные, используя "git branch -a"
Пара вариантов.
Вы можете зафиксировать свои изменения в «другой ветке», переключиться на master и выполнить свою работу там, а затем переключиться обратно.
Вы также можете создать дополнительное рабочее дерево. Google "git-worktree" для деталей о синтаксисе.
Я не думаю, что существует установленная конвенция. Проверка нескольких рабочих деревьев одновременно является исключением, а не правилом.
источник