GitHub требует, чтобы у каждого разработчика было их собственное ветвление проекта?
Я хотел бы судить мерзавца (размещенный на GitHub) для нового проекта, но у меня есть сомнение о том, как он работает. Я работаю с другим парнем, мы должны иметь два ветвления проекта и затем объединить их каждый раз, когда один из нас вносит изменение в код, или действительно ли возможно работать в паре над единственным источником?
4 ответа
Можно иметь как можно больше дополнительные коммиттеры (называемые соавторами в терминах GitHub) над одним проектом по своему усмотрению. Однако максимальное количество зависит от тарифного плана. Обратите внимание, что общедоступные репозитории могут иметь неограниченное количество соавторов.
Что касается самого Git: любой, у кого есть доступ на запись в репозиторий, может нажать на него.
Используя git, вы оба получите локальные копии репозитория. Когда вы нажимаете (или извлекаете) репозиторий github, вы будете вынуждены объединиться, если другой человек внесет изменения в файл, в который вы также внесли изменения с момента последнего нажатия / извлечения. Вам обоим нет необходимости иметь собственный форк.
Прежде всего, позвольте мне заявить, что у меня самого нет большого опыта работы с git. Учитывая это, позвольте мне перейти к моему ответу.
Короткий ответ будет таким: да, в некотором смысле, так оно и будет. Но это не обязательно должно быть настолько большой проблемой, как вы об этом говорите.
Я почему-то предположил, что вы знаете SVN, но дайте мне знать, если это не так, и я постараюсь изложить все с другой точки зрения.
Способ SVN, централизованный способ, заключается в том, что есть один репозиторий и у каждого есть рабочая копия. В рабочей копии можно вносить изменения, а затем эти изменения могут быть зафиксированы в хранилище. Если два человека одновременно вносили изменения в свои рабочие копии, вам может понадобиться объединить изменения, но если это не так, то все будет происходить автоматически.
Git децентрализован. Это достигается за счет того, что не просто существует единый репозиторий, а у каждого пользователя есть свой репозиторий. Обычно репозиторий сопровождается рабочей копией (причем рабочая копия - это обычные файлы, а репозиторий размещается в .git. Вы вносите изменения в свою рабочую копию и затем фиксируете их в вашем репозитории. Затем, если вы решите, что изменения должны быть видны публике, вы можете переместить изменения в вашем репозитории в публичный репозиторий.
(Обратите внимание, что публичный репозиторий является публичным только потому, что вы относитесь к нему как к таковому, git не знает ничего другого. Если вы работаете над одной функцией вместе со своим коллегой Бобом, вы можете вместо этого отправить изменения в репозиторий Боба и только когда вы вдвоём закончите, отправить их в публичный репозиторий, или вообще не делать этого, если это только ваша личная модификация.)
В общем, при типичном использовании слияние в git будет более проблематичным, чем в SVN. К счастью, слияние в git также лучше, так что вам придется меньше делать это самостоятельно (или так мне говорили). Тем не менее, конфликтов не должно быть слишком много, если вы не будете ждать месяцами, прежде чем выложить что-то в публичный репозиторий. Еще лучше, если вы боитесь слияния (причин для этого немного, но если вы боитесь), вы можете выкладывать сразу после каждого коммита - в этом случае вы будете делать не больше слияний, чем в SVN. Вы отказываетесь от некоторой гибкости git, но значительную часть этой гибкости опять же можно уменьшить, если правильно использовать ветви (что автоматически означает использование явного слияния, но в git этого бояться не стоит).
Короткий ответ - нет, если вы используете публичный репозиторий. Перейдите в раздел администратора для репозитория, выберите панель «Соавторы» и добавьте столько пользователей, сколько вы хотели бы иметь возможность фиксировать в репозитории. Затем все пользователи будут использовать один и тот же адрес для клонирования и отправки.
Просто не забудьте отозвать их изменения, прежде чем продвигать свои собственные.