Рабочий процесс Git для одного разработчика в локальном репозитории
Я ' м пытаюсь усовершенствовать личный рабочий процесс git так, чтобы с ним было легче справиться.
Вот некоторая предыстория того, как я использую git для целей этого сообщения:
Один разработчик, единственный, кто работает над репозиторий.
Одна копия репозитория, которая хранится на локальной машине.
Только две ветки «dev» и «master».
Вся работа выполняется на «dev».
What I ' m пытается достичь того момента, когда единственные коммиты, сделанные в ветке master, являются рабочими производственными версиями, основанными на подтвержденном стабильном коде dev.
Фактически, я хочу сделать следующее:
Когда все в «dev» проверено и готово к работе, обновите «master», чтобы он стал точным клоном дерева файлов ветки «dev».
Внесите незначительные изменения в «master» для обновления номеров версий и т. Д.
Зарегистрируйтесь в обновленной ветке «master».
Создайте новый тег из ветки master.
Подходя к первому шагу, я проверяю ветвь "master" и затем запускаю:
'git diff master dev | git apply -'
Насколько я понимаю, это эффективно удаляет все, что есть в "master", и заменяет все дерево веткой содержимое «dev». Запуск «git status» показывает, что это делает то, что ожидается на основании пункта 1 выше.
Итак, первый вопрос: Правильно?
После того, как «главная» ветвь получила эти обновления, я запускаю свой скрипт, чтобы обновить номера версий в файлах. Затем я просто запускаю стандартный «git add». и "git commit -a" чтобы добавить все изменения. Наконец, я создаю новый тег и возвращаюсь в ветку "dev", чтобы снова начать кодирование.
Итак, другой вопрос: Есть ли в этом процессе что-нибудь, что может вызвать проблемы?
ОБНОВЛЕНИЕ: Я должен был поставить это в первый раз, но причина, по которой я не просто использую слияние заключается в том, что изменение номера версии на master, а затем попытка слияния с изменениями в dev вызывает конфликты слияния. Я знаю, что они неуместны, но это останавливает процесс. Раньше я использовал "merge -Xtheirs {branch}", чтобы справиться с этим, но и в этом я не уверен.
UPDATE2: Я знаю, что кое-что не работает. Я собрал bash-скрипт, который работает в Mac OSX. Первая попытка использовать слияние:
#!/bin/bash -x
####################
### file: merge1 ###
####################
### clear out the old stuff so you can rerun
rm -rf .git
rm *.txt
### setup the repository
git init
### ignore merge and output files for clarity sake
echo -e "output*\nmerge*" > .gitignore
git add .gitignore
### make the intial commit and move over to dev
git commit -m "Initial commit"
git checkout -b dev
### add stuff to test1.txt in dev
echo -e "FILE1 LINE\nVERSION-XXX\nFILE1 LINE" > test1.txt
echo -e "File2 LINE\nVERSION-XXX\nFILE2 LINE" > test2.txt
### add the files and commit
git add .
git commit -m "Created test1.txt and test2.txt in dev."
### output the state of test1.
cat test1.txt > output-dev-test1-a.txt
cat test2.txt > output-dev-test2-a.txt
### move to master and do a first merge which will work
git checkout master
git merge dev
### Update the version numbers in master and commit it
sed -i "" -e 's/VERSION-XXX/VERSION-1.0/g' test*.txt
git commit -am "Updated version to 1.0 on master"
cat test1.txt > output-master-test1-a.txt
cat test2.txt > output-master-test2-a.txt
### switch back to dev and commit an update to test1.txt
git checkout dev
sed -i "" -e 's/LINE/CHANGED/' test*.txt
git commit -am "Updated content in test*.txt on dev"
### dump test1.txt for reference.
cat test1.txt > output-dev-test1-b.txt
cat test2.txt > output-dev-test2-b.txt
### swtich back to master
git checkout master
######################################################################
### BREAK
######################################################################
### this is where the merge fails because of a conflict
git merge dev
Другой способ, которым я это пробовал, был с -Xtheirs, который, похоже, сначала работает, но он не обновляет все. Чтобы убедиться в этом, удалите несколько последних строк после BREAK выше и замените их на:
### merge with -Xtheirs works here. Proper version "XXX" is showing.
git merge -Xtheirs dev
### but if we update the version number one more time on master
sed -i "" -e 's/VERSION-XXX/VERSION-2.0/g' test*.txt
git commit -am "Updated version to 2.0 on master"
### dump reference file
cat test1.txt > output-master-test1-b.txt
cat test2.txt > output-master-test2-b.txt
### Now, go back to dev and change something in only one of the files
git checkout dev
sed -i "" -e 's/CHANGED/ALTERED/g' test2.txt
git commit -am "Altered only test2.txt on dev."
cat test1.txt > output-dev-test1-c.txt
cat test2.txt > output-dev-test2-c.txt
### are finally return to master and merge again
git checkout master
git merge -Xtheirs dev
### dump reference file
cat test1.txt > output-master-test1-c.txt
cat test2.txt > output-master-test2-c.txt
Конфликтов нет, но 'output-master-test1-c.txt' показывает 'VERSION-2.0' вместо 'VERSION-XXX 'что желательно. Похоже, это произошло потому, что в файл не было изменений. Файл 'output-master-test2-c.txt' имеет ожидаемую строку 'VERSION-XXX'. Проблема, конечно же, в том, что поиск и замена, которые пытались обновить до версии 3.0, пропустили в test1-c, потому что он не распознал часть 2.0 VERSION.