Преподавание мерзавцев, сохраняя их «так же легко, как SVN»

Question

Я в университете, и моя группа вместе начинает проект по программированию.

В предыдущем предмете нас учили основам svn и тому, как совершать, а также как использовать Toitosesvn.Нам сказали не беспокоиться о ветвлении (и поэтому не учили об этом), так как это была довольно маленькая программа.Во время проекта svn-сервер вышел из строя, и все не могут работать, однако люди не думают об этом.

В этом проекте я стремлюсь иметь DVCS.После объяснения того, как git отличается от svn, они сказали, что все будет в порядке, но хотят, чтобы это было так же просто, как использовать svn.Поскольку мы будем использовать Eclipse ^, им просто нужны инструкции о том, как использовать git с Eclipse.(Я планирую использовать EGit )

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

Как мне представить концепции git таким образом, чтобылегко для разработчиков svn привыкли к графическому интерфейсу?

Примечание: Git используется, потому что я толкаю его, и я знаю его (и не знаю, Mercurial или базар)

^:собирать программу для Android.

Answer 1

Несколько заметок:

• Git Ready - хорошее, нежное введение в Git.

• Мне также нравится визуальная природа Git для компьютерных ученых .

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

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

В конечном счете, git - это большое повышение производительности, но не в том случае, если оно идет за счет замедления всего остального для вашей команды.

Answer 2

Mercurial на самом деле может быть проще, потому что он более автоматический.Вы можете думать о Hg как о «мерзавце без индекса», со всеми вытекающими отсюда последствиями.:-) Hg также запрещает переписывать историю, что имеет свои плюсы и минусы;в частности, это означает, что вам нужны надстройки, такие как очереди, чтобы люди могли предоставлять патчи друг другу во время разработки.

При всем этом я бы на самом деле склонялся к git сам, отчасти потому, что он "работает правильно"даже если пользовательский интерфейс чрезвычайно сложен.Если вы начинаете людей с git 1.7.x, они могут просто вспомнить «git commit -a».

Answer 3

Краткий ответ: Ноу

---

Чтобы избежать всех острых углов, вы должны забыть о

• Филиалы
• Прогулки по истории
• Множество пультов (таким образом - D -VCS nature)

В этом случае у вас почти ничего нет от VCS как такового

Кстати, фон Subversion для Git-новичков больше минус, чем плюс

• Git-терминология как минимум раздражает и нечист (GUI не скрывает базовые понятия)
• Git-jargon и его отказ от использования традиционной терминологии контроля версий

«Ускоренный курс Git-SVN» каким-то образом помогает, но не решает все проблемы полностью

PS: Возможно, кросс-платформенный SmartGit может сделать Git-жизнь более легкой

Answer 4

Вы можете установить SubGit (subgit.com) на сервер SVN. После этого сервер получит 2 интерфейса: SVN и Git. Я имею в виду, что если вы нажмете на репозиторий Git, изменения будут автоматически переведены в репозиторий SVN; и наоборот.

Он сохраняет основные понятия Subversion, такие как ignore, EOLs-management, теги, слияния и т. Д. (Намного лучше, чем git-svn).