Рабочий процесс GIT с несколькими рабочими станциями и централизованным сервером

Question

Хорошо, несколько вещей, в которых я не совсем уверен.

Для начала:

• У меня есть «голое» репо на VPS в удаленном DC.
• У меня есть рабочая станция, на которой я тоже пишу код.
• У меня дома есть рабочая станция, на которой я также пишу код.

1 - Когда я настраиваю свой первоначальный репо на одной из моих рабочих станций (я думаю, что Git называет это мастером), я должен проверить и работать из другого каталога? Как подрывная деятельность.

2 - Когда я хочу поработать над кодом на работе, я запутался, как мне выполнить коммиты с локальным репозиторием на рабочем столе, а затем в конце дня перенести мои изменения в «голое» репо на моем VPS, чтобы я мог вытащить обновления на домашний рабочий стол.

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

Answer 1

1 - master - это имя Git по умолчанию для главной ветви репозитория. Это относится не ко всему хранилищу, а к этой единственной линии развития. Вам не нужен отдельный рабочий каталог - общая идея локальной разработки git заключается в том, чтобы работать в каталоге, фиксировать изменения в репозитории, а затем при необходимости передавать их в апстрим.

2 - у вас должен быть пульт в вашем домашнем и рабочем репо, направленный на голое VPS репо. Если вы создали свое репо путем клонирования репозитория VPS, оно будет «origin». Толчок к исходной точке и тянет к ней - это значения по умолчанию, поэтому твои толчки идут туда. Это спроектированное поведение - есть большая вероятность, что когда вы клонируете репозиторий, именно от него вы хотите получать обновления и возвращать свои изменения обратно.

Я бы предложил, чтобы и дома, и на работе рассматривали репо VPS как источник. Затем вы можете при необходимости нажимать и извлекать его на каждом компьютере, просто используя git push и git pull. Если одно из ваших репозиториев еще не настроено таким образом, вы можете либо отложить VPS-репо, чтобы сделать это автоматически, либо использовать

git remote add origin <url-of-VPS-repo>
git config branch.master.remote origin
git config branch.master.merge = refs/heads/master

Последние две строки сообщают git, что вы хотите, чтобы ваша основная ветка была связана с главной веткой на удаленном источнике (вашем VPS).

Answer 2

В Git вы можете (и обычно должны) переключать ветки «на месте». Например, если вы находитесь на ветке 'master' и хотите начать работать с веткой 'devel', вы можете просто использовать

$ git checkout devel

и ваша рабочая область будет отражать ветку 'devel'. Обычно вам нужно быть в чистом состоянии, то есть не иметь несвязанных изменений.

---

Что касается настройки между «рабочим», «домашним» и «пустым» хранилищами:

Во-первых, вопрос конфигурации . Я предполагаю, что как на «рабочем», так и на «домашнем» компьютере настроен «пустой» (или как вы его называете свой пустой репозиторий) с конфигурацией, которая выглядит следующим образом (вы можете использовать «git remote add» для создать его):

[remote "bare"]
    url = user@example.com:/path/to/repo.git
    fetch = +refs/heads/*:refs/remotes/bare/*
    push = refs/heads/*:refs/heads/*

Может быть другая удаленная конфигурация, например, для тегов (например, fetch = +refs/tags/*:refs/tags/* и т. Д.), Но я опускаю ее для простоты.

Во-вторых, давайте предположим, что вы работаете над веткой 'master', и у вас есть следующая конфигурация для такой ветки как в репозиториях "work", так и в "home":

[branch "master"]
    remote = bare
    merge = refs/heads/master

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

Давайте теперь рассмотрим несколько примеров сессий . Вы либо на «работе», либо «дома».

1. Первое, что вы должны сделать перед началом работы, - это получить обновления из «пустого» хранилища. Здесь я предполагаю, что вы находитесь в «основной» ветке. Вы можете сделать это с помощью «git pull bare» или с помощью указанной выше конфигурации веток просто «git pull»:

   $ git pull bare
   Updating 8818df8..9ad6770
   Fast forward
    foo |    1 +
    1 files changed, 1 insertions(+), 0 deletions(-)
   

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

2. Теперь сделайте некоторую работу (это пример только сеанс):

   $ edit, edit, edit
   $ git commit -a
   $ git add somefile
   $ git commit -a
   $ git commit --amend
   

   Обратите внимание, что вам лучше закончить свою работу, чтобы не было никаких незавершенных изменений, но это не является строгим требованием. Если вы оставите некоторые несвязанные изменения, вы можете закончить коммит до "git pull", но тогда вы не получите ускоренную перемотку вперед, а только слияние. Или вы можете использовать «git stash», чтобы спрятать внесенные изменения, а затем применить stash (распаковать) их после извлечения.

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

   $ git push bare
   Counting objects: 8, done.
   Compressing objects: 100% (3/3), done.
   Writing objects: 100% (6/6), 493 bytes, done.
   Total 6 (delta 0), reused 0 (delta 0)
   Unpacking objects: 100% (6/6), done.
   To user@example.com:/path/to/repo.git
      9ad6770..4230584  master -> master
   

Я надеюсь, что такой пример поможет.