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

Question

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

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

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

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

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

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

То, что я пытаюсь сделать, это добраться до точки, где единственные коммиты, сделанные в "master" ветке, - это рабочие рабочие версии, основанные на стабильном стабильном "dev" коде.

По сути, я хочу сделать следующее:

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

2. Внести незначительные изменения в "master" для обновления номеров версий и т. Д. *

3. Зафиксировать обновленную ветку "master".

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

Способ, которым я подхожу к первому шагу, заключается в извлечении ветки "master" и последующем запуске:

'git diff master dev | git apply -'

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

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

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

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

ОБНОВЛЕНИЕ: Я должен был поставить это в первый раз, нопричина, по которой я не просто использую слияние, заключается в том, что изменение номера версии на ведущем устройстве, а затем попытка слияния с изменениями в dev вызывает конфликты слияния.Я знаю, что они не имеют значения, но это все равно останавливает процесс.Я использовал «merge -Xtheirs {branch}» прежде, чтобы иметь дело с этим, но я также не уверен в этом.

ОБНОВЛЕНИЕ 2: Вот некоторые вещи, которые, я знаю, не работают.Я собрал 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.

Answer 1

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

[master]$ git merge dev

Когда вы запустите это в главной ветке (показано в приглашении), вы объедините все изменения из 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

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

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

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

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

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

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

Answer 3

Я нашел другой способ приблизиться к этому, который, я думаю, делает все, что мне нужно.Суть этого заключается в том, чтобы сделать на главном:Также, глядя в gitk на историю ветки «master», вы можете увидеть, куда были добавлены конкретные версии «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

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