Всякий раз, когда вы задаете вопрос в форме: «Отличается ли A от B», вам лучше дать некоторые точные определения того, что A и B являются .
К сожалению, определение branch в Git (намеренно) нечетко. Могу поспорить, что у вас и ваших коллег немного другое определение. Они, наверное, тоже все не правы. ? Более серьезно, они, вероятно, согласны с некоторыми вещами, а не с другими , и существует множество разумных определений. Смотрите также Что именно мы подразумеваем под "ветвью"?
Git распространяется и распространяется , поэтому у каждого будет свой клон некоторого репозитория Git. Может быть, а может и не быть, какое-то конкретное выдающееся хранилище Git - часто это то, которое хранится в GitHub - которое каждый соглашается рассматривать как своего рода «основное», «главное», «доминирующее» или любое другое слово, которое вы предпочитайте централизованную версию репозитория «источник правды», чтобы фактически все остальные одноранговые репозитории воспринимались как несколько меньшие сущности. Но дизайн Git децентрализован, и каждый репозиторий достаточно автономен.
Из-за этого каждый репозиторий имеет свои собственные независимые имена веток . Даже если вы позвоните в ваш филиал в ваш Git dev, а Боб позвонит его его филиал в его Git dev, и Кэрол называет свою ветку в ее Git dev, и так далее, на самом деле это все независимые имена веток . Это все прекрасно работает в изоляции. Проблема, с которой вы столкнетесь, состоит в том, что, когда Боб пытается поговорить с Кэрол, он скажет «в dev ...», и Кэрол будет думать, что Боб имеет в виду ее dev, когда Боб на самом деле означает его dev. Если Боб и Кэрол попытаются заставить своих двух Гитов заниматься Git-repo-sex 1 друг с другом, это станет еще хуже, потому что без тщательного инструктажа их Гиты будут пытаться спарить своих двух dev с. .
Что означает , так это то, что полезно предоставить каждому свое ответвление Имена . 2 Это верно независимо от того, используется ли Боб Git говорит напрямую с Кэрол, или Боб и Кэрол оба заставляют своих Гитов вызвать Git на GitHub, чтобы исполнить Git-repo-mating-dance. Нам, людям с неясной головой, гораздо проще говорить о «двух последних коммитах в моей ветке xyz», чем нам сказать «совершить b697d92f56511e804b8ba20ccbe7bdc85dc66810 и зафиксировать 6ee1eaca3e996e69691f515742129645f453e0e8». Последний является точным и будет работать во всех случаях - эти два коммита всегда , это точно два коммита, но идентификаторы хеша просто не подходят для использования человеком.
1 Извините, жарко. ? Вы соединяете два Gits вместе, используя git fetch или git push. Обратите внимание, что git pull запускает git fetch, а затем вторую команду Git, так что он на самом деле просто использует git fetch для обмена коммитами.
2 Обратите внимание, что я продолжаю говорить здесь о ветвях names . Это различие полезно: если мы определим branch как серию коммитов, заканчивающихся коммитом tip, идентифицированным по имени ветки , то в какой-то момент каждый разработчик будет иметь свою собственную ветку - каждый раз, когда кто-то делает новый коммит, находясь в имени ветви, он или она делает новый уникальный коммит, который обновляет это имя ветви, которое создает новую ветку. Таким образом, с или без уникальной ветви names , эти разработчики будут иметь уникальные branch .