Как лучше всего использовать GIT в нашей рабочей среде?

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

Мы хотели бы начать использовать какую-то VCS (скорее всего, GIT). Я предполагаю централизованный рабочий процесс, в котором каждый разработчик имеет локальную копию кода на своей машине. Мы бы предпочли использовать GitHub Enterprise для общего репозитория, а не размещать код на GitHub.

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


git java eclipse version-control egit
person Tommo    schedule 13.12.2012    source источник
comment
Пожалуйста, дайте более подробную информацию об этой проблеме очистки/сборки. В чем проблема?   -  person ccleve    schedule 13.12.2012
comment
Просто кажется, что с несколькими разработчиками, которые одновременно открывают общий проект и редактируют файлы, мы будем постоянно застревать в цикле, когда я вношу изменения и сохраняю, Eclipse очищает/собирает проект, в то время как другой человек редактирует/сохраняет файл и их Eclipse пытается очистить/собрать проект, пока мой еще работает. Полная очистка/сборка также занимает более 5 минут, так как код хранится на сетевом диске, что замедляет работу.   -  person Tommo    schedule 13.12.2012
comment
Я думаю, что это лучше подходит для programmers.stackexchange.com, если таковые имеются. Никогда не бывает лучшего пути, только самый подходящий для моей ситуации, которая довольно субъективна.   -  person Felix Kling    schedule 14.12.2012
comment
Я согласен. По сути, мы просто ищем самый простой способ хранить код в центральном месте, чтобы у каждого разработчика была локальная копия на его машинах, которая оставалась синхронизированной. Очистка/создание такого большого проекта, как наш, будет происходить значительно быстрее локально, чем по сети.   -  person Tommo    schedule 14.12.2012

Ответы (6)


arrow_upward
3
arrow_downward

Сначала посмотрите это видео.

Во-вторых, если вы используете Eclipse, вы захотите использовать EGit. Очень подробное руководство здесь.

В-третьих, не бросайтесь на GIT. Примите во внимание SVN в какой-то момент (после документирования в GIT). Возможно, центральная система управления версиями подойдет вам лучше, чем распределенная система управления версиями.

Изменить:

Да, и, кстати... есть очень длинный и известный Q&A прямо здесь относительно этой темы. Удачи.

Второе редактирование:

Что касается SVN, здесь у вас есть простой учебник по Subversive и здесь вы можете найти полную версию в -your-face Подрывная документация.

person GGrec    schedule 13.12.2012
comment
Кажется, что многие функции, которые делают GIT полезным, к нам точно не применимы. Наше развитие довольно линейно. Время от времени мы выпускаем новую версию, но на самом деле мы не делаем много ответвлений, когда кто-то может вести проект в совершенно другом направлении. Определенно кажется, что GIT великолепен и полезен, но для того, что мы пытаемся сделать и в чем нуждаемся, он будет намного сложнее, чем должен быть. - person Tommo; 13.12.2012
comment
Тогда Subversion правильный путь. Его реализацией для Eclipse является Subversive, который является рекомендуемым подключаемым модулем для IDE. Его гораздо проще использовать, чем GIT - вы правы. :) - person GGrec; 13.12.2012
comment
На самом деле мы не делаем ветки и не работаем в автономном режиме, я просто думаю, что Subversion создана именно для того, что мы пытаемся сделать, и хотя у нее нет дополнительных наворотов, которые есть у GIT, они в любом случае не применимы к нам. - person Tommo; 13.12.2012
comment
Я призываю вас пересмотреть подрывную деятельность. - person Adam Dymitruk; 13.12.2012
comment
+1 - особенно за ссылку на отличное видео. У меня есть несколько лет опыта работы с svn (довольно хорошо), и мне нравится переключаться на git (во всяком случае). Теперь я понимаю, почему в данном случае очень важно думать по-другому :-). Спасибо. - person Michał Powaga; 02.03.2014
comment
@Tommo (отвечая на старый комментарий, но на случай, если кто-то еще это прочитает) «Наша разработка довольно линейна». Все говорили это до того, как попробовали Git. :) Ветки Git хороши для многих вещей, о которых вы изначально не подумали бы как о ветках. То есть, только потому, что вы думаете, что у вас линейный поток разработки, не сбрасывайте со счетов большую вероятность того, что ветки по-прежнему помогут вашему существующему потоку работать лучше. Это особенно верно для нескольких разработчиков, но я нахожу это верным и для своих сольных проектов. - person Marnen Laibow-Koser; 19.03.2019

arrow_upward
2
arrow_downward

У вас есть свои потребности сейчас, но они изменятся. Избавьте себя от головной боли, связанной с последующим переходом на Git из SVN, и начните с Git. Вот причины, по которым лучше использовать Git, а не Subversion:

  1. Скорость — Git НАМНОГО быстрее
  2. Место на диске — история Git маленькая. Большую часть времени он занимает 1/10 часть истории SVN.
  3. Нет сервера - DVCS не позволяет администратору, и вы можете вообще пропустить централизованный сервер. Ваш центральный репозиторий может быть просто файлами на сетевом ресурсе.
  4. Целостность - повреждение данных очень легко обнаружить и исправить.
  5. История снэпшотов — для каждой версии создается снэпшот всего проекта. Нет смешивания и сопоставления путей с версиями.
  6. Зависимости с открытым исходным кодом — большинство проектов, которые вы, возможно, захотите использовать, находятся на Github. Вы можете легко просто добавить подмодуль и версию этой зависимости.
  7. Power:
    • git bisect - find a where a bug was introduced quickly
    • rerere — повторно используйте то, как вы устранили конфликты, если они возникнут снова
    • поддерживает любой рабочий процесс
    • правильное трехстороннее слияние — это сэкономит массу головной боли в будущем
    • перебазирование - вы можете сохранить свою историю линейной, даже после того, как кто-то слился

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

person Adam Dymitruk    schedule 13.12.2012
comment
Можете ли вы расширить без сервера - DVCS не допускает администратора, и вы можете вообще пропустить централизованный сервер. Ваш центральный репозиторий может быть просто файлами на сетевом ресурсе. Как мне настроить его так, чтобы репозиторий был просто файлами на сетевом ресурсе? - person Tommo; 14.12.2012
comment
Предполагая, что ваша доля отображается как z, cd /z/ && mkdir centralrepo && cd centralrepo && git init --bare. Сделанный. Вам даже не нужно устанавливать git на машине, на которую указывает z. - person Adam Dymitruk; 14.12.2012
comment
Затем я просто выгружаю файлы и клонирую их локально? - person Tommo; 14.12.2012
comment
Неа. Сначала вы инициализируете репозиторий на своем компьютере, а затем отправляете его на удаленный компьютер: cd yourproject && git init && git add . && git commit -m "my first commit" && git remote add origin /z/centralrepo && git push origin master Теперь ваш проект существует как в центральном репо, так и локально. Теперь один из ваших коллег может получить проект с помощью git clone /z/centralrepo. Но вы также можете просто получать изменения напрямую от других разработчиков и не иметь ничего центрального, если вы можете связаться друг с другом через общие сетевые ресурсы. - person Adam Dymitruk; 14.12.2012
comment
Проголосовал, но должен не согласиться с тем, что ребаз - это хорошо. Если есть слияние, ваша история должна показать это. - person Marnen Laibow-Koser; 19.03.2019

arrow_upward
2
arrow_downward

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

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

Начните с примера проекта с несколькими файлами и поэкспериментируйте с ним, так как вам потребуется некоторый опыт работы с системой контроля версий. Также изучите инструменты командной строки git (для Windows используйте msysgit), поскольку большинство примеров в Интернете написано для тех. Для получения дополнительной информации о git обязательно прочитайте бесплатную книгу по git: http://git-scm.com/book< /а>

Также см. этот вопрос об использовании git на общем ресурсе Windows: Как git клонировать репозиторий в Windows с другого компьютера в локальной сети?

person Niels van Reijmersdal    schedule 13.12.2012
comment
Используйте Git CLI-команды, потому что вы не можете более или менее разумно использовать Git только с графическим интерфейсом. Более правильным и справедливым будет определение: все графические интерфейсы Git скрывают многое за кадром - person Lazy Badger; 14.12.2012
comment
чтобы использовать git по назначению со всеми преимуществами, вы используете его из командной строки. - person Adam Dymitruk; 14.12.2012
comment
Графический интерфейс, такой как SourceTree или GitX, полезен, но в качестве дополнения к командной строке, а не в качестве ее замены. - person Marnen Laibow-Koser; 19.03.2019

arrow_upward
0
arrow_downward

EGIT для eclipse — это хороший инструмент для интеграции git в среду вашего проекта eclipse.

Кроме того, если вы используете Windows, вы можете загрузить Github для Windows, это действительно просто и эффективно.

person mtk    schedule 13.12.2012

arrow_upward
0
arrow_downward

GIT, безусловно, предпочтительнее и прекрасно интегрируется с Eclipse IDE. Но вы также можете использовать Subversion, так как все, что вам нужно, это локальная копия кода на пользовательской машине (назовем ее веткой subversion). Я говорю предпочтительный способ, потому что GIT слишком гибок: автономные коммиты, полная копия тела кода вместо только ветки и т. д. список слишком длинный.

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

  1. Просто зарегистрируйтесь для этого
  2. создать репозиторий.
  3. Получите ссылку на репозиторий и укажите ее как новый репозиторий git в Eclipse.
  4. Нажмите свой код. Соверши это.

У вас будут файлы кода на github. Это будет работать, если у вас установлен Git в Eclipse. Я считаю, что Eclipse Juno уже настроен с EGit (плагин для Git)

Для решения проблем со сборкой вы можете настроить некоторые инструменты непрерывной интеграции, такие как Jenkins. Это также можно настроить как плагин Eclipse.

person Vikram    schedule 13.12.2012

arrow_upward
0
arrow_downward

Как уже отмечалось, на вопрос

лучший способ использовать GIT?

в вашей ситуации (нулевой SCM-опыт) лучшим и справедливым непредвзятым ответом будет

Не используйте Git вообще!

Вопреки «Почему Git лучше, чем Subversion?» тема, которую вы также можете прочитать (некоторое подмножество в результате быстрого отзыва)

и проверьте другие темы под тегом git с несколькими жалобами от Git-boys.

В то время как Subversion является довольно хорошим выбором (в любом случае, с некоторыми краевыми углами: вы можете попасть в «ад слияния», даже если вы думаете о разработке как о линейной: некоторые ответвления могут и должны случается, в «Кошмар рефакторинга» со знаменитой ошибкой «Конфликт дерева» ...) вы можете подумать об альтернативах «Используется как Subversion и мощнее, чем Git» (даже вы будете использовать только небольшую необходимую часть или общую мощность): - Mercurial «DVCS с человеческим лицом, созданные программистами для программистов, а не для модных чуваков».

  • MercurialEclipse — это ответ на запрос Eclipse (в рекомендация Aragost доверяют пользователям Mercurial)
  • TortoiseHG — это удобный кроссплатформенный графический интерфейс для всех и любых потребностей Mercurial за пределами Затмение
  • Сервер Mercurial требует гораздо меньше головной боли (особенно «под Windows»), чем эквивалентный Git-сервер.
  • Mercurial настоящих экспертов найти несложно (в то время как Git-boys — это более веселый клуб восторженных подростков)
person Lazy Badger    schedule 13.12.2012
comment
Согласен, git - это бардак. Github, однако, чрезвычайно полезен и помогает справиться с проблемами git. Git стоит использовать хотя бы для того, чтобы получить возможности Github. - person ccleve; 14.12.2012
comment
@ccleve - BitBucket не хуже для Mercurial (частично - лучше /бесплатное приватное репо/), для Git все равно выберу Assembla - person Lazy Badger; 14.12.2012
comment
Понижение. Хотя я сам начинал с CVS (!), я знаю множество людей, которые начинали с Git и смогли его изучить. Git очень логичен, если вы потратите время на изучение нескольких основных концепций (все дело в создании деревьев коммитов и синхронизации коммитов между репозиториями). Я рекомендую Git всем и сделал бы это в 2012 году, когда был опубликован этот ответ. - person Marnen Laibow-Koser; 19.03.2019