Git - несколько машин на разработчика - фиксация на разных машинах, но не в основной ветке

Question

Мы переходим на git из SVN, и есть некоторые концепции, которые я не могу обернуть вокруг себя.

У нас есть следующие настройки:

• живой сервер, "живой"
• внутренний сервер разработчика, "локальный" (git server, svn daemon, все репозитории находятся на этом)
• рабочих станций (iMacs)
• домашние компьютеры (в первую очередь ПК с Linux)

Я преобразовал наш источник в git-репо и передал его в "local". Все это работает хорошо, и когда я клонирую его, он копирует главную ветку в мою локальную среду, дома ли я или на работе. Вытягивание на живом сервере также работает хорошо, и оно переносит изменения главной ветви в живую среду. Но я хочу иметь следующие возможности:

• Я хочу иметь возможность разрабатывать и фиксировать на рабочей станции, не переходя в основную ветку, но я бы хотел, чтобы эти изменения были отражены и на моей домашней машине. Другими словами, я хочу иметь возможность сделать частичное обновление или функцию, зафиксировать и продолжить работу над ним дома, даже не добавляя его в живую ветку. Это достигается с помощью ветвления? Чтобы я зафиксировал, а затем нажать на определенную ветку? Имейте в виду, об отслеживании git-репозитория рабочей станции с домашним компьютером не может быть и речи, поскольку рабочая станция не всегда включена (любой, кто когда-либо запускал Java-приложение на Mac, знает, что он может оставаться включенным максимум пару часов)

• Я хочу, чтобы каждый разработчик мог работать над своей частью приложения, без зависимости друг от друга. Желательно ли делать это с ветвями для каждого разработчика или мы должны делать ветки для каждого элемента?

• Когда работа с компонентом завершена, целесообразно ли объединить ветвь с главным репо, а затем перенести обновления основного репо в оперативную среду, или же у нас должна быть отдельная «производственная» ветка для них. цели? Как обычно выполняется live-развертывание через git? Поскольку у нас частота выпусков составляет около 10 ревизий в день (чрезвычайно быстрые циклы разработки), SVN до сих пор работал довольно хорошо, поскольку наш действующий сайт является всего лишь проверкой хранилища, и когда обновление готово, мы просто вызывали svn update эти файлы на живом сервере. Какие-нибудь лучшие практики по этому поводу с git?

Edit:

Практический пример с моими предположениями о том, как все это работает: допустим, наш проект - «проект», и у нас есть разработчики «dev1», «dev2» и «dev3», каждый из которых имеет 2 машины. У команды есть 3 задачи: «ошибка», «функция» и «сотрудничество». Ошибка назначена dev1, функция - dev2, а совместная работа - это функция, над которой всем троим нужно работать вместе ($ REMOTE - это URL основного репо на нашем локальном сервере dev, т.е. user @ local: repo.git):

=========

I. Работаем локально

Поскольку dev1 назначен на «жучка», он позаботится об этом. Он делает следующее:

$git branch bug
$git checkout bug // switches to bug branch
( // edit some files)
$git commit -a -m 'I fixed the bug!'
$git push $REMOTE bug

Как этот разработчик теперь объединяет свое исправление с главным репозиторием и как он удаляет ветку ошибок на всех машинах после завершения этого слияния? Я бы хотел, чтобы ветка с ошибками исчезла, когда люди делают обновление или загрузку, или что-то еще, в случае, если они их проверили или как бы вы их ни извлекли.

========

II Работа локально, а затем продолжение той же синхронизированной ветви в другом месте

"функция" была назначена для "dev2", и он делает это:

$git branch feature
$git checkout feature // switches to feature branch
( // edit/add some files etc. )
$git commit -a -m 'I made some updates, will continue at home'
$git push $REMOTE feature
// at home, the developer does the following, right?
$git clone $REMOTE -b feature /some_new_folder // if he didn't clone the whole repo previously
or
cd previously_cloned_repo_master_or_whatever
$git fetch
$git checkout $REMOTE feature
( // right? )
( // edit some files then ... )
$git commit -a m 'I finished!'
$git push
// Same as above, what next? How to merge it into all other branches and safely delete the branch afterwards. What happens when someone is in a branch that has been deleted, and makes a pull?

========

III Многие люди на одной ветке, отдельно от основной ветки

«Сотрудничество» - это совместное усилие, над которым будут работать все три разработчика из всех 6 мест. Он создан dev3.

$git branch collaboration
$git checkout collaboration // switches to needed branch
( // add something, so we have something to commit)
$git commit -a -m 'Initialized new branch'
$git push $REMOTE collaboration
( // The other two devs can then simply call .. )
$git fetch
$git checkout $REMOTE collaboration
( // And they're ready to go, right? )
( // Each dev then makes his own edits on some areas, commits, and pushes. All pushes change the content of the branch, so that if dev2 pushed and dev1 makes $git pull in the root of the project while on this branch, dev1 will get his changes, right? )

========

Кроме того, можно ли ограничить ветку определенным создателем ветки? Например, я хотел бы увидеть, что dev1 сделал с «ошибкой», прежде чем он ее удалит, но в случае, если я хочу внести в нее некоторые свои собственные изменения, мне НЕ следует позволять это делать, вместо этого мне придется сделайте запрос на извлечение для данной ветви, и dev1 должен будет вручную принять мои изменения - я не смогу заставить его это сделать.

Answer 1

TL; DR

Использование git flow .

Это удалит вопросы и автоматизирует некоторые вопросы, о которых вы спрашиваете,Когда вы знакомы с git flow и ветвлением и т. Д., Вы можете легко сделать что-то по-другому - или вручную.

Изменения, которые будут отражены и на моей домашней машине

На вашем imac push / pull для not-master и на домашней машине push / pull от not-master.

Где «not-master» - это любая ветка, над которой вы сейчас работаете.

Разветвленные ветви

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

Отдельная производственная ветвь

Однако вы делаете это - ваше живое приложение должно тянутьиз известного стабильного тега / ветви и, как правило, не переходите непосредственно к мастеру , потому что ломать вещи - это часть разработки, а ломать код, из которого извлечет ваше живое приложение, - то, что вам абсолютно необходимоизбежать.Вы должны быть в состоянии в любой момент установить свою живую установку, не сомневаясь, что вы можете использовать поврежденный код.Если вы используете сервер Continuous Integration , вы можете легко автоматизировать слияние из вашей ветки разработки в мастер, если все тесты пройдены, и даже автоматически развернуть.

Когда ветвьзакончили с

Все сомнения рабочего процесса - это одно и то же.когда ветка закончена, вы объединяете ее с вашей основной веткой.

то есть

$ git branch working-on-this master
$ git add ...
$ git commit ...
$ # rinse and repeat
$ git push --set-upstream $REMOTE working-on-this

А когда приходит время:

$ git checkout master
$ git pull
$ git merge working-on-this
$ git push
$ git branch -d working-on-this
$ git push $REMOTE :working-on-this

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

$ git branch --merged master

, который, если ветка закончена, будет выглядеть следующим образом:

$ git branch --merged master
master
working-on-this
$ git branch -d working-on-this

Что означает, что работа над этим может быть безопасно удалена,В любом случае - git branch -d выдает предупреждение и прерывает работу, если вы пытаетесь удалить ветку, которая не объединена с веткой, в которой вы находитесь при выполнении команды.

Если вы обнаружите, что у вас есть несколько удаленныхветви, которые, как считается, уже завершены - вы можете очистить их одной командой:

$ git remote prune -n origin

Флаг -n означает, что он будет сообщать только о том, какие ветви он собирается удалить - убрать этот флаг на самом делеудаление устаревших удаленных веток

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

Ограничение разрешений на принятие изменений в филиале

Да, вы можете это сделать, но действительно ли вы этого хотите?Вам лучше использовать общение и соглашения.

Некоторые предложения:

• любой может создать удаленную ветку
• никто не фиксирует / не объединяется с мастером (только лидерство)это делает dev)
• никто не удаляет удаленную ветвь (это делает только ведущий разработчик)
• никто не удаляет удаленный сервер (это делает только ведущий разработчик)

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

Answer 2

Вы можете ввести соглашения об именах для своих веток и позволить всем им жить счастливо на local. Например:

На работе:

work$ git branch -a
  master
* user1/my-work
  remote/local/master
  remote/local/user1/my-work
work$ git push local user1/my-work

и дома:

home$ git branch -a
  master
* user1/my-work
  remote/local/master
  remote/local/user1/my-work
home$ git pull local user1/my-work

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

Answer 3

Я хочу иметь возможность развиваться и совершать ..

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

Я хочу, чтобы каждый разработчик был ..

Я бы рекомендовал ветки функций, а не ветки разработчиков. Это имеет больше смысла, когда несколько разработчиков сотрудничают над функцией.

Когда работа над функцией завершена, рекомендуется ли ...

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

Я не думаю, что есть лучшие практики. Это зависит от того, что вы делаете, то есть от того, что вы разрабатываете. Если вы хотите сохранить рабочий процесс, git позволит вам это сделать. Вместо «svn update» вы делаете «git pull».