Назад | Перейти на главную страницу

Как создать сценарий Bash для Git Checkin / Checkout?

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

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

РЕДАКТИРОВАТЬ: Меня не особо интересует использование Git с его фантастическими функциями различий. Я двигаюсь со скоростью 100 миль в час, и у меня нет времени играть в разные игры с другими разработчиками. Вот почему мы используем Git. Если другие разработчики захотят поиграть в игру с различиями, они все равно смогут это сделать. Но когда я что-то проверяю, я хочу, чтобы это было заблокировано для всех, пока я не проверю это снова.

Но когда я что-то проверяю, я хочу, чтобы это было заблокировано для всех, пока я не проверю это снова.

Эээ ... извините, DVCS (с D как "Распределенный") работает совсем не так.

a / вы не "проверяете" файл (как, например, в ClearCase). Вы просто начинаете его изменять, и Git обнаружит изменение как кандидата на индексацию (git add) и для совершения (git commit, "проверочная" часть)

b / Когда вы «оформляете» (т.е. изменяете) или проверяете файл, другие разработчики и связанные с ними другие репозитории ничего об этом не знают.
Вы «запираете» всех, что никто не может получить доступ к вашему репо и изменить ваши файлы.

Но когда вы публикуете (т.е. нажимаете эти изменения), затем вам нужно решить любую одновременную модификацию. В DVCS нет центральной ссылки, способной обнаруживать одновременное изменение и / или записывать «блокировку».

Git был разработан не совсем так. То есть это не типичный рабочий процесс git. Если вам действительно нужен этот рабочий процесс, подумайте об использовании чего-то, построенного на этом рабочем процессе, например SubVersion. Заблокированные файлы приводят к уведомлениям, если кто-то еще хочет файл, но вы являетесь его владельцем:

http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.advanced.locking

Я не знаю, поддерживает ли шлюз git-svnserver блокировку, но может. Если да, то вы можете получить лучшее из обоих миров.

Однако Git очень гибкий. Если вы хотите быть злым, он это поддержит. Git позволяет слепо стереть любые изменения, которые могли произойти, пока вы использовали файл. Каждый раз, когда вы хотите нажать на главный репозиторий, просто сделайте:

git pull --strategy ours ; git push

Нет необходимости в этой функции слияния.

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

Другой вариант, который следует рассмотреть, - это «git pull --strategy recursive -Xours».

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

Если вы настаиваете на блокировке, распределенная модель Git вам не подходит. Вместо Git вам, вероятно, следует использовать централизованный система контроля версий, такая как SVN. Это позволяет вам заблокировать файлы в репозитории. Ваш коллега-программист получит предупреждение, когда он / она попытается зафиксировать репо.

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

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