У меня есть контракт, чтобы написать часть программы. Человек, пишущий другую часть, находится в другом городе. Я хочу найти удобный способ отправки изменений взад и вперед. По другим причинам я хотел бы научиться использовать git в качестве распределенного VCS и изменения электронной почты взад и вперед. (Я работал с SCCS, RCS и PVCS раньше, всегда с блокировкой. Я хочу подтолкнуть себя, чтобы узнать, как лучше использовать ветвление и слияние и не зависеть от центрального сервера.)
Нам нужно выполнить следующие две задачи (довольно стандартный список):
(a) Каждый из нас вносит свой вклад в исправления ошибок и новые функции, требующие изменений в обеих частях.
(б) Компилировать и упаковывать двоичные файлы для клиентов.
(Мы также должны работать отдельно над функциями, которые не зависят друг от друга, но я предполагаю, что для этого также будет работать все, что работает для задачи (а).)
Предыстория: другой парень никогда не использовал VCS раньше; он немного сопротивляется этой идее. Он даже не знал, что они все еще не используют блокировку. Мне нужно было бы понять все, что мы делаем, на достаточной глубине, чтобы я мог помочь ему по грубым местам с небольшим разочарованием с его стороны. Ему также очень неудобно хранить исходный код на сервере, что является еще одной причиной для предпочтений электронной почты. Мы можем легко их зашифровать.
Другой возможный контекст: мы используем Delphi для Windows в качестве среды разработки. Очень маловероятно, что мы когда-нибудь добавим еще одного разработчика. Нам нужно всего лишь пару раз в год упаковывать клиентские версии. Количество клиентов, вероятно, не превысит десяти.
Вопросы:
1) Должен ли я использовать этот проект для изучения методов для распределенного развития? Или это так много, что я должен просто сделать что-то более простое? Я не прочь потратить дополнительное время на обучение, но не более, чем на пару недель.
2) Предполагая "Да" на вопрос 1, какой рабочий процесс мы должны использовать для каждой из вышеперечисленных задач?
3) Какие программы Windows GUI будут выполнять все требуемые задачи? (Мне очень удобно работать с командной строкой, он нет.)
Спасибо за вашу помощь.
Я написал довольно подробное руководство по "gitting started", которое показывает, что я узнал до сих пор об использовании git. Он находится в http://xorandor.com/GittingStarted, если вы хотите его прочитать до сих пор. Я попытался написать его для новичка git, который знает немного, но не очень много о VCS вообще. Я планирую добавить к этому, когда узнаю больше.
Какой рабочий процесс git использовать для 2 разработчиков, не являющихся разработчиками?
Ответ 1
Другой парень никогда не использовал VCS до; он немного устойчив к идея.
Я участвовал в обучении и поддержке пользователей, которые были вынуждены сделать переход от безопасного источника к подрывной деятельности. Было удивительное количество пользовательских сопротивлений. Прошло уже больше года, и мне все еще регулярно звонят, чтобы исправить ситуацию, когда "подрывная деятельность сломала мои вещи" (это никогда не бывает, конечно).
Зная это, я бы очень не решался попробовать и помочь кому-то сделать переход от VCS вообще до git (что, вероятно, не является самым удобным для пользователя VCS). Особенно, если они ненавидят идею VCS. Вдруг так, если вы не можете быть там, помогая им за своим столом.
Итак, рассмотрим: некоторые причины - просто потерянные причины. Если вы не собираетесь работать с этим человеком в течение длительного времени, вам может быть лучше создать репозиторий только для себя. Вы можете позволить ему отправлять вам измененные файлы и наоборот. По крайней мере, git поможет вам увидеть, какие файлы были изменены с момента последней точки интеграции.
Ответ 2
Если вы используете этот проект для изучения git? Я бы сказал, да.
Помимо неотъемлемых преимуществ управления версиями, я использую git, имеет преимущество наличия полных копий репозитория в каждой системе разработчиков,
Одна вещь, которую я делал бы поверх каждого, имеющего репозиторий, - это каждый из вас синхронизировать с центральным сервером каждый день или около того.
Рабочий процесс будет выглядеть следующим образом:
- Вы вносите изменения в локальный репозиторий git так часто, как можете.
- При фиксированном интервале (один раз в день, после исправления или функции исправления) и т.д., нажмите репозиторий до центрального хранилища, расположенного на вашем веб-хосте или другом хостинге git (aka, GitHub).
- Всегда извлекайте изменения из центрального репозитория вместо репозитория друг друга. Вы можете обработать центральный репозиторий как ваш репозиторий выпуска, и это позволит избежать путаницы в отношении того, какой репо (ваш или ваш) является самым текущим.
Я знаю, что весь смысл системы управления распределенной версией - не иметь центрального репо, но мне очень нравится иметь эту дополнительную копию вне сайта. Если что-то оно дает вам еще одну копию репозитория для целей резервного копирования.
Что касается git в окнах, я бы посмотрел иллюстрированное руководство по запуску git в окнах. Встроенный git -gui оставляет желать лучшего, но он функциональный и удобный.
Кроме того, поскольку ваш партнер новичок в управлении версиями, я бы рекомендовал Eric Sink отлично Source HOWTO. Это дает вам много отличной информации о том, как управлять исходным кодом.
Ответ 3
Im мой опыт, Git пока не очень хорошо поддерживается в Windows.
Для аналогичного, но IMHO более удобного DVCS, см. Mercurial (a.k.a. Hg). У него есть Tortoise-клиент и довольно дружественный инструмент командной строки.
Также есть плагины Visual Studio и Eclipse для Mercurial (я думаю, NetBeans тоже). Они работают достаточно хорошо и являются отличным дополнением к другим инструментам. (Материал добавляется/удаляется/переименовывается автоматически, а основные задачи синхронизации (push/pull) работают нормально.)
Ответ 4
Похоже, что git имеет встроенную функциональность исправлений по электронной почте. Я не использовал его, хотя, поэтому я не могу говорить о его полезности.
Ответ 5
Я новичок в git, но, возможно, самый быстрый способ начать это:
С помощью git вы можете создать два репозитория на своем компьютере.
Один для вашей работы, а второй для работы, которую он посылает вам.
Там хороший учебник для начала (как упоминалось Ником)
Этот инструмент хорош, если вы работаете с окнами/подрывной деятельностью до TortoiseGit
Моя точка зрения: не начинайте учить его, пока вы не почувствуете себя очень хорошо в git, сделайте оба репозитория/ветки на вашем компьютере.
Ответ 6
Я бы просто сконфигурировал autosetuprebase для каждого и просто начал с довольно простой настройки.
Объявите конфликты, которые вы получаете - это те изменения, которые в противном случае были бы потеряны.
Ответ 7
Поскольку другой разработчик не знаком с концепциями управления версиями, я предлагаю начать медленно.
Мой предложенный рабочий процесс состоит из репозитория на вашей стороне, что он может "git clone". Покажите ему, как он может получить изменения от этого, и попросите его отправить ваши изменения обратно вам. Покажите ему, как git может отправлять изменения по почте. Таким образом, вам будет нужно беспокоиться о конфликтах редактирования, которые, как правило, являются отличным источником путаницы для людей, которые раньше никогда не использовали системы контроля версий.