Какой рабочий процесс git использовать для 2-х не расположенных разработчиков?

Question

У меня есть контракт на написание части программы. Человек, пишущий другую часть, находится в другом городе. Я хочу найти удобный способ отправки изменений туда и обратно. По другим причинам я хотел бы научиться использовать git в качестве распределенной VCS и переписываться по электронной почте. (Я работал с SCCS, RCS и PVCS раньше, всегда с блокировками. Я хочу научиться тому, как лучше использовать ветвление и слияние и не зависеть от центрального сервера.)

Нам нужно выполнить следующие две задачи (довольно стандартный список):
(a) Каждый из нас вносит свой вклад в исправление ошибок и новые функции, которые требуют изменений в обеих частях.
(b) Компилировать и упаковывать двоичные файлы для клиентов.
(Нам также нужно отдельно работать над функциями, которые не зависят от других, но я предполагаю, что все, что работает для задачи (а), будет работать и для этого.)

Фон: другой парень никогда не использовал VCS прежде; он немного сопротивляется этой идее. Он даже не знал, что они все еще не используют блокировку кассовых аппаратов. Мне нужно было бы понять все, что мы делаем, достаточно глубоко, чтобы я мог помочь ему преодолеть трудные моменты, не испытывая особого разочарования с его стороны. Ему также очень неудобно хранить исходники на сервере, что является еще одной причиной, чтобы предпочесть изменения по электронной почте. Мы можем легко зашифровать их.

Другой, возможно, важный контекст: мы используем Delphi на Windows в качестве среды разработки. Крайне маловероятно, что мы когда-либо добавим другого разработчика. Нам нужно упаковывать версии клиентов только пару раз в год, если это так. Количество клиентов, вероятно, никогда не превысит десяти.

Вопросы:
1) Должен ли я использовать этот проект для изучения методов распределенной разработки? Или это настолько излишне, что я должен сделать что-то попроще? Я не против потратить дополнительное время на обучение, но не более пары недель.

2) Предполагая «Да» на вопрос 1, какой рабочий процесс мы должны использовать для каждой из перечисленных выше задач?

3) Какие программы Windows GUI будут выполнять все необходимые задачи? (Я очень хорошо разбираюсь в командной строке; он нет.)

Спасибо за вашу помощь.

Я написал довольно подробный учебник по «gitting start», который показывает, что я узнал об использовании git. Это на http://xorandor.com/GittingStarted, если вы хотите прочитать это до сих пор. Я попытался написать это для новичка в git, который знает немного, но не очень много о VCS в целом. Я планирую добавить к этому, как я узнаю больше.

Answer 1

Стоит ли использовать этот проект для изучения мерзавца? Я бы сказал, да.

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

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

Рабочий процесс будет выглядеть так:

1. Вы вносите изменения в свой локальный репозиторий git так часто, как можете.
2. Через фиксированный интервал (один раз в день, после исправления большой ошибки или функции и т. Д.) Переместите свое хранилище в центральное хранилище, расположенное на вашем веб-хосте или другом провайдере git-хостинга (он же, GitHub ).
3. Всегда извлекайте изменения из центрального репозитория, а не из репозитория друг друга. Вы можете относиться к центральному репозиторию как к своему репо-релизу, и это позволит избежать путаницы в отношении того, какой репозиторий (ваш или его) является наиболее актуальным.

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

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

Кроме того, поскольку ваш партнер является новичком в управлении источниками, я бы порекомендовал Эрика Синка превосходное Source Control HOWTO . Он дает вам много полезной информации о how управления исходным кодом.

Answer 2

Другой парень никогда не использовал VCS до; он немного устойчив к идея.

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

Зная это, я бы очень колебался, пытаясь помочь кому-то переключить вообще с VCS на git (который, вероятно, не самый удобный для пользователя VCS). Особенно, если они ненавидят идею VCS. Вдвойне, если ты не сможешь помочь им за их столом.

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

Answer 3

Похоже, в git есть встроенная функция исправлений по электронной почте . Я не использовал его, поэтому я не могу говорить о его полезности.

Answer 4

По моему опыту, Git пока не очень хорошо поддерживается в Windows.

Для аналогичного, но ИМХО более удобного DVCS, см. Mercurial (a.k.a. Hg). У него есть клиент-черепаха и довольно дружественный инструмент командной строки.

Есть также плагины Visual Studio и Eclipse для Mercurial (я тоже думаю, что NetBeans). Они работают достаточно хорошо и являются отличным дополнением к другим инструментам. (Stuff get добавляется / удаляется / переименовывается автоматически, и основные задачи синхронизации (push / pull) работают нормально.)

Answer 5

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

Мой предложенный рабочий процесс состоит из хранилища на вашей стороне, которое он может "git clone". Покажите ему, как он может извлечь из этого изменения, и пусть он отправит вам по почте свои изменения. Покажите ему, как Git может отправлять ревизии по почте. Таким образом, вам придется беспокоиться о конфликтах редактирования, которые могут стать источником путаницы для людей, которые никогда ранее не пользовались системами контроля версий.

Answer 6

Я бы просто настроил autosetuprebase для каждого и просто начал с довольно простой установки.

Примите конфликты, которые вы получаете - это те изменения, которые в противном случае были бы потеряны.

Answer 7

Я довольно новичок в git, но, возможно, самый быстрый способ начать это:
С помощью git вы можете создать два репозитория на вашем компьютере.
Один за вашу работу, а второй за работу, которую он вам посылает.
Есть хороший учебник для начала (как упомянуто Ником)
Этот инструмент хорош, если вы работаете с Windows / Subversion до TortoiseGit

Моя точка зрения: не начинайте учить его, пока вы не почувствуете себя очень хорошо в git, сделайте обе репо / ветки на вашем компьютере.