Рабочий процесс Git для одного разработчика в локальном репозитории

Question

Я пытаюсь усовершенствовать личный рабочий процесс git для чего-то, с чем немного легче справиться.

Вот некоторые фоне того, как я использую Git для целей этого поста:

• Один разработчик, который является единственным один работает в хранилище.

• Единая копия репозитория, хранящегося на локальном компьютере.

• Только две ветви "dev" и "master".

• Все работы выполнены на «dev».

То, что я пытаюсь выполнить, чтобы добраться до точки, где только коммиты из филиала «мастера» работает версию производства на основе confrimed стабильного «Dev» код.

Эффективно, что я ищу, чтобы сделать это:

1. Когда все в «разработчика» протестирован и готов к работе, обновление «мастер», чтобы быть точным клоном филиала «Dev» дерево файлов.

2. внести незначительные изменения в «мастер» для обновления номеров версий, и т.д. ...

3. Обязаться обновленной ветви «мастер».

4. Создайте новый тег из ветки "master".

То, как я приближаюсь первый шаг является проверка филиала «мастер», а затем запустить:

'git diff master dev | git apply -' 

Насколько я понимаю, это эффективно сдувает ничего «мастера "и заменяет все дерево содержимым" dev ". Выполнение «git status» показывает, что это делает то, что ожидается на основании № 1 выше.

Итак, первый вопрос: Верно ли это?

После того, как филиал «master» получил эти обновления, я запустил свой сценарий для обновления номеров версий в файлах. Затем я просто запускаю стандартный «git add». и «git commit -a», чтобы добавить все изменения. Наконец, я создаю новый тег и возвращаюсь в ветку «dev», чтобы снова начать кодирование.

Итак, другой вопрос: Есть ли что-нибудь в этом процессе, которое вызовет проблемы?

ОБНОВЛЕНИЕ: Я должен был поставить это в первый раз, но причина, по которой я не просто использую слияние, заключается в том, что изменение номера версии на главном, а затем попытка слиться с изменениями в 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, который выглядит, как он работает в первый, но не обновлять все. Для того, чтобы увидеть, что удалить последние несколько строк после перерыва выше, и заменить их:

### 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 

Там нет никаких конфликтов, но «выход-мастер-test1-c.txt» показывает «ВАРИАНТ-2,0» вместо Желательно "VERSION-XXX". Это, похоже, произошло потому, что никаких изменений в файле не было. Файл 'output-master-test2-c.txt' имеет ожидаемое значение "VERSION-XXX". Проблема, конечно, в том, что поиск и замена, которые пытались обновить до версии 3.0, пропустили бы в test1-c, потому что он не узнал бы 2.0 часть жалобы VERSION.

Answer 1

Вы должны использовать настоящие слияния вместо разлома diff/apply. Это так же просто, как

[master]$ git merge dev 

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

[master]$ git commit -a -m "New version number." 
[master]$ git tag version-1.x 

Это так просто.

На самом деле вам вообще не нужна главная ветка, вы можете создать короткую ветвь разветвления на основе dev, создать там тег и удалить ветвь позже.

[dev]$ git checkout -b release dev 
[release]$ git commit -a -m "New version number." 
[release]$ git tag version-1.x 
[release]$ git checkout dev 
[dev]$ git branch -d release 

Answer 2

Я придумал другой способ приблизиться к этому, что, я думаю, делает все, что мне нужно. Сердце его, чтобы сделать следующее на мастера:

### pull the diff to make sure there are no conflict 
git diff master dev | git apply - 

### do merge without commit to make branch tree behave 
git merge --no-commit --no-ff -s ours dev 

### update the version numbers 
sed -i "" -e "s/VERSION-XXX/VERSION-$1/g" *.txt 

### now, add everything to master and commit 
git add . 
git commit -m "Master commit $1" 

Это гарантирует, что все номера версии «Dev» пребывания в «XXX», но будут обновлены надлежащим образом во всех файлах в «мастер». Кроме того, глядя в gitk в истории филиала «мастер», вы можете увидеть, где конкретные версии «Dev» были добавлены в Например:.

dev:  d1----d2----d3----d4----d5 
     /\   \  \ 
master: x m1   m2 m3 

Это дерево, что я искал и делает его Легче, чтобы я точно понял, что происходит.

Вот сценарий bash (написанный на Mac OSX, если это имеет значение), который я использовал для тестирования и выяснил это. Если есть интерес к попыткам других стратегий, вы должны просто обновить функцию doMerge и запустить сценарий, чтобы узнать, что произойдет.

#!/bin/bash 

###################################################################### 
# Setup functions 
###################################################################### 

function doMerge { 

    ### add everything in dev 
    git add . 
    git commit -m "Commiting dev $1" 

    ### switch to master 
    git checkout master 

    ### pull the diff to make sure there are no conflict 
    git diff master dev | git apply - 

    ### do merge without commit to make branch tree behave 
    git merge --no-commit --no-ff -s ours dev 

    ### update the version numbers 
    sed -i "" -e "s/VERSION-XXX/VERSION-$1/g" *.txt 

    ### now, add everything to master and commit 
    git add . 
    git commit -m "Master commit $1" 

    git tag -m "Created tag v-$a" -a "v-$1" 

    ### and then switch back to dev so you are ready to work 
    git checkout dev 

} 


### this just lets you see what's going on in the output 
function showReport { 

    echo "############################################################" 
    echo "##### 'dev' branch files #####" 
    echo "############################################################" 

    DEVCNT=1 
    while [ $DEVCNT -lt 4 ]; do 
    cat $DEVCNT.txt 
    echo "############################################################" 
    let DEVCNT=DEVCNT+1 
    done 

    git checkout master 


    echo "############################################################" 
    echo "##### 'master' branch files #####" 
    echo "############################################################" 

    MASTCNT=1 
    while [ $MASTCNT -lt 4 ]; do 
    cat $MASTCNT.txt 
    echo "############################################################" 
    let MASTCNT=MASTCNT+1 
    done 
    echo "" 

    git checkout dev 

} 


###################################################################### 
# Main 
###################################################################### 

### 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 "check-history" > .gitignore 
git add .gitignore 

git commit -m "added .gitignore" 

### switch to dev 
git checkout -b dev 

### add some files 
COUNTER=1 
while [ $COUNTER -lt 10 ]; do 
    echo "File $COUNTER - VERSION-XXX" > $COUNTER.txt 
    echo "The quick brown fox jumps over the lazy dog" >> $COUNTER.txt 
    let COUNTER=COUNTER+1 
done 

### run the diff/apply/merge strategy and show the results 
doMerge 1; showReport 


echo "File 2 - VERSION-XXX" > 2.txt 
echo "New Data" >> 2.txt 

git commit -am "dev tmp commit 1" 

echo "Additional data" >> 1.txt 
echo "Additional data" >> 2.txt 

doMerge 2; showReport 

sed -i "" -e 's/quick/EXTREMELY FAST/' 3.txt 

doMerge 3; showReport 

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

Answer 3

я сделать что-то очень похожее (только тогда, когда я являюсь единственным разработчиком на моем собственном программном обеспечении) ...

я работаю ИСКЛЮЧИТЕЛЬНО на главной ветви. И в разных «версиях» я создаю висячую ветку.

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

A - B - C - D - E - F 
    \    \ 
     1.0    1.1 

Легко и работает достаточно хорошо для моих нужд.

Если мне нужно исправить некоторые ошибки в предыдущих версиях, я просто отработаю эту ветку и сделаю это.