1

Случай использования:

У меня есть MyApp, который будет развернут на ClientX. Я пишу сценарий оболочки, чтобы извлечь эту ветку из моего репозитория Bitbucket

мой сценарий оболочки (который отлично работает)

git clone -b $BRANCH_NAME https://$USER_NAME@bitbucket.org/MyApp/ecodrone.git

Вопрос:

Теперь с обновлениями, лучше иметь

  1. мерзкий клон каждый раз
  2. один git-clone.sh и один git-pull.sh?

2 ответа2

2

Если у вас есть постоянное хранилище, то повторное клонирование будет очень неэффективным (особенно клонирование всей истории, так как вы не используете --depth=).

Между тем, извлечение / извлечение будет принимать только объекты, которые фактически изменились. Использование:

  • git fetch && git reset --hard "origin/$BRANCH_NAME" чтобы всегда получать последний коммит,

  • или git pull --ff-only если вы предпочитаете, чтобы он потерпел неудачу, если кто-то попытался переписать историю.

Не используйте обычные git pull как в последнем случае это может привести к большому беспорядку.

1

Короткий ответ:

  1. мерзавец

Для обновления лучше использовать git pull или git fetch, rebase и merge, если вы работаете с другими людьми в одной и той же ветке (и / или файлах), поскольку git pull пытается выполнить слияние, только если нет конфликтов слияния.

Также было бы лучше создать новую ветвь на основе клонированной вами ветки, чтобы легче разрешать локальные конфликты на вашем компьютере. Обычно это называется функциональной ветвью в рабочем процессе. Таким образом, как только ваша работа будет завершена и зафиксирована, вы можете запустить git pull для главной ветви (из-за отсутствия имени, которое я называю веткой, которую вы клонировали ведущим), это должно произойти без каких-либо проблем, а затем вы можете перебазировать функцию с главного и объединить (использовать флаг --no-ff, если вы хотите сохранить историю ветвлений / фиксаций ветки компонента, в противном случае она будет сведена в один коммит) к мастеру. Затем продвиньте свою работу (главную ветвь) вверх по течению.

должно идти что-то вроде:

git checkout -b feature
...work, stage changes & commit...
git checkout master
git pull upstream/master #or git pull origin master based on git remote urls
git checkout feature
git rebase -i upstream/master
git checkout master 
git merge --no-ff master feature
git push upstream #or git push origin

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .