фиксация в одной ветке с git

Question

Допустим, что в git-ветке работают два человека, они проверяют в одно и то же время, но один из них фиксирует сначала, а потом другой. Будет ли новейшая фиксация все еще объединена с предыдущей или может ли одновременно работать несколько человек в одной и той же ветке?

Answer 1

Что ж, когда вы клонируете git-репозиторий (это то, что вы имели в виду под «извлечением»?), Вы фактически создаете новую ветку. Ветви Git являются локальными для каждого хранилища, а не глобальными. Тем не менее, у вас есть протокол для того, как обновления веток передаются между репозиториями - когда вы извлекаете данные с удаленного компьютера, по умолчанию ветвь "master" удаленного узла, например, объединяется с вашей "master" веткой. И когда вы нажимаете, ваша «основная» ветвь может быть добавлена ​​ к главной ветке пульта. Таким образом, ваш мастер и мастер пульта («источник / мастер», если хотите) являются разными ветвями, но они связаны по соглашению.

Возвращаясь к сути - вы заметили, что я сказал, что ваша ветка master может быть добавлена ​​, когда вы нажимаете на пульт. Если два человека взяли копию оригинала / мастера и внесли независимые изменения (помните, что это похоже на локальное внесение изменений в две ветви), как только один человек внес свои изменения, изменения другого человека не являются простым добавлением к источнику / мастер больше --- они должны быть объединены. Это не может произойти, когда вы нажимаете, только когда вы вытягиваете (сбивает с толку, «вытягивание» не совсем противоположно «подталкиванию»: «извлечение» противоположно толчку - извлечение - это извлечение, за которым следует объединение ребаз)).

Так что, если вы находитесь в такой ситуации, то, кто бы ни пытался выдвинуть свои изменения, сначала должен отойти от обновленного источника / мастера, объединить или перебазировать свою версию мастера, а затем нажать. По умолчанию вы не можете удалить чьи-либо изменения в ветке и заменить их своими собственными: для этого вам нужно, по крайней мере, выполнить «git push -f», а в удаленном репозитории могут быть настройки или хуки, чтобы сделать его значительно сложнее.

Или двое из них могли бы сотрудничать заранее: один из них извлекает изменения другого, выполняет слияние, а затем выдвигает результат. Это может быть полезно, если изменения могут перекрываться или влиять друг на друга. Помните Первый Закон систем контроля версий: VCS не является заменой для связи .

Answer 2

В Git ветки строго локальные . Один разработчик не может изменить удаленные ветви другого разработчика (см. Примечание внизу). Однако в случае bare репозитория вы можете «протолкнуть» свои изменения в него, чтобы обновить ветви удаленного репозитория, если ваши изменения приведут к ускоренной перемотке вперед.

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

Например, допустим, Алиса и Боб работают над главной веткой в ​​своих локальных репозиториях, каждый из которых клонируется из общего (пустого) репозитория на сервере. Если Алиса заканчивает свою работу первой, когда она вносит свои зафиксированные изменения в общий голый репозиторий, она ускоряет пересылку главной ветки голого репо.

Теперь Боб не может ускорить пересылку мастер-ветви голого репо без предварительного обновления своей локальной ветки, чтобы включить коммиты, добавленные Алисой (поскольку добавленные коммиты не являются предками коммитов, созданных Алисой).

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

Возможны другие рабочие процессы: Алиса и Боб могут совместно извлекать друг друга напрямую, не используя общий открытый репозиторий. На самом деле возможностей практически нет. Но, как правило, объединение в Git выполняется путем изменения .

[примечание: на самом деле можно загружать репозитории, не являющиеся открытыми, и, таким образом, обновлять ветки других людей, однако это часто дает неинтуитивные результаты, не считается типичным рабочим процессом git и, как правило, не рекомендуется]

Answer 3

Короче, ответ такой:

commit -m "my changes"

Получить общую версию

git fetch sharedrepo

один из этих двух для синхронизации вашей локальной ветки с другим репо

git merge sharedrepo/sharedbranch
git rebase sharedrepo/sharedbranch

Rebase сериализует историю, если вы не хотите много веток в окончательной истории. Оба варианта могут заставить вас решать конфликты, прежде чем вы закончите.

После слияния / перебазировки и разрешения конфликтов вы возвращаетесь к репо

git push sharedrepo HEAD:sharedbranch

Не используйте здесь -f, так как это должно быть ускоренное выполнение. Если вам не повезло, кто-то другой, возможно, выдвинул новую версию. Если это произойдет, перезапустите эту процедуру.

Answer 4

Вы можете работать отдельно, а затем всякий раз, когда вам нужно нажать / потянуть изменения, выполните:

git add --all .
git commit -m "Commit desc"
git pull
git push

Разъяснения:

git add --all .

Добавить все изменения, включая удаленные файлы

git commit -m "Commit desc"

Объявить коммит

git pull

Первое нажатие, которое слится, вам может понадобиться исправить конфликты

git push

Нажмите последнюю объединенную версию [необязательно - если вы хотите отправить свои изменения]

Если вам нужен дополнительный контроль, например возможность работать с несколькими локальными / удаленными версиями одновременно, взгляните на branch .

Я рекомендую эту простую, но полезную страницу в качестве рекомендуемого рабочего процесса http://genomewiki.ucsc.edu/index.php/Working_with_branches_in_Git описывает некоторые замечательные процедуры.

Answer 5

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