为本地存储库上的单个开发人员开发的Git工作流程 [英] Git workflow for a single developer on a local repository
问题描述
我正在尝试改进个人git工作流程，使其更容易处理。
以下是我如何使用git用于这篇文章：
-
一个开发人员是唯一一个在存储库中工作的开发人员。
-
存储在本地计算机上的存储库的单个副本。
只有两个分支dev和master 。 -
所有工作都是在dev完成的。 $ b
我试图达到的目标是，对主分支进行的唯一提交工作是基于受密码的稳定开发代码工作的生产版本。
实际上，我要做的是：
-
当dev中的所有内容都经过测试并准备就绪时，请将master更新为dev分支文件树的精确克隆。
-
对master进行小修改以更新版本号等等。
-
提交到更新的主分支。
-
从主分支创建一个新标签。
我接近第一步的方式是检出主分支，然后运行：
'git diff master dev | git apply - '
根据我的理解，这会有效地吹掉主中的任何内容并替换整个树与开发的内容。运行git status似乎表明这是基于上面的＃1做的。因此，第一个问题是：是否正确？
在主分支已收到这些更新，我运行我的脚本来更新文件中的版本号。然后，我只运行一个标准的git add。和git commit -a添加所有更改。最后，我创建一个新标签并返回到开发分支再次开始编码。所以，另一个问题是：那个过程中有什么会引起问题的？
更新：我应该在第一次使用它，但是我不是简单地使用merge，原因是更改master上的版本号，然后尝试合并dev中的更改会导致合并冲突。我知道他们是无关紧要的，但它仍然停止了这个过程。我之前使用过合并-Xtheirs {branch}来处理它，但我也不确定。
-
UPDATE2：这里有一些我知道不起作用的东西。我已经放在一起在Mac OSX上运行的bash脚本。第一个尝试使用merge：
＃！/ bin / bash -x
## ##################
### file：merge1 ###
############### #####
###清除旧东西，以便重新运行
rm -rf .git
rm * .txt
###设置存储库
git init
###为了清楚起见忽略合并和输出文件
echo -eoutput * \\\
merge *> .gitignore
git add .gitignore
###进行初始提交并移至开发
git commit -m初始提交
git checkout -b dev
###将东西添加到dev
中的test1.txt echo -eFILE1 LINE\\\
VERSION-XXX\\\
FILE1 LINE> test1.txt
echo -eFile2 LINE\\\
VERSION-XXX\\\
FILE2 LINE> test2.txt
###添加文件并提交
git add。
git commit -m在dev中创建了test1.txt和test2.txt。
###输出test1的状态。
cat test1.txt> output-dev-test1-a.txt
cat test2.txt> output-dev-test2-a.txt
###移动到master并执行第一次合并，这将工作
git checkout master
git合并开发
###更新master中的版本号并提交它
sed -i-e's / VERSION-XXX / VERSION-1.0 / g'test * .txt
git commit - 是在主版本上更新到1.0版本
cat test1.txt> output-master-test1-a.txt
cat test2.txt> output-master-test2-a.txt
###切换回开发并提交更新到test1.txt
git checkout dev
sed -i-e 's / LINE / CHANGED /'test * .txt
git commit -am在dev中更新测试* .txt中的内容
### dump test1.txt以供参考。
cat test1.txt> output-dev-test1-b.txt
cat test2.txt> output-dev-test2-b.txt
### swtich回到主
git checkout master
########### ################################################## #########
### BREAK
############################# #########################################
＃ ##这是由于冲突导致合并失败的地方
git merge dev
另一个我尝试过的方式是使用-Xtheirs，它看起来像起初有效，但它不会更新所有内容。要看到这一点，请删除上面BREAK后的最后几行，并将其替换为：
###与-X合并这里。正在显示XXX版本。
git合并-X他们的开发
###但是如果我们更新版本号再一次在master
sed -i-e's / VERSION-XXX / VERSION-2.0 / g'test * .txt
git commit -am在master上更新到2.0版本
###转储参考文件
cat test1.txt> output-master-test1-b.txt
cat test2.txt> output-master-test2-b.txt
###现在，回到开发并修改其中一个文件
git checkout dev
sed -i -e's / CHANGED / ALTERED / g'test2.txt
git commit -am仅更改了dev上的test2.txt。
cat test1.txt> output-dev-test1-c.txt
cat test2.txt> output-dev-test2-c.txt
###终于返回到master并重新合并
git checkout master
git merge -Xtheirs dev
###转储参考文件
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中会丢失，因为它无法识别VERSION sting的2.0部分。
您应该使用真正的合并而不是diff / apply hack。这很简单，就像
[master] $ git merge dev
当你在master分支上运行这个（在提示符中显示）时，你将会合并来自dev的所有更改。之后你可以更新版本号，提交并创建一个标签
[master] $ git commit -a -m新版本数。
[master] $ git tag version-1.x
就这么简单。
事实上，你根本不需要主分支，你可以创建一个基于dev的短暂版本分支，在那里创建一个标签，然后删除分支。
$ b $
[dev] $ git checkout -b release dev
[release] $ git commit -a -m新版本号。
[release] $ git tag version-1.x
[release] $ git checkout dev
[dev] $ git branch -d release
I'm trying to refine a personal git workflow to something a little easier to deal with.
Here's some background of how I'm using git for purposes of this post:
A single developer who is the only one working on the repository.
A single copy of the repository that is stored on the local machine.
Only two branches "dev" and "master".
All work done on "dev".
What I'm trying to accomplish is to get to the point where the only commits made to the "master" branch are working production versions based on the confrimed stable "dev" code.
Effectively, what I'm looking to do is:
When everything in "dev" is tested and ready to go, update "master" to be an exact clone of the "dev" branch file tree.
Make minor modifications to "master" to update version numbers, etc...
Commit to the updated "master" branch.
Make a new tag from the "master" branch.
The way that I'm approaching the first step is to checkout the "master" branch and then to run:
'git diff master dev | git apply -'
From what I understand, this effectively blows away anything in "master" and replaces the entire tree with the contents of "dev". Running "git status" appears to show that this is doing what's expected based on #1 above.
So, the first question: Is that correct?
After the "master" branch has received these updates, I run my script over to update version numbers in files. Then, I just run a standard "git add ." and "git commit -a" to add all the changes. Finally, I make a new tag and return to the "dev" branch to start coding again.
So, the other question: Is there anything in that process that is going to cause issues?
UPDATE: I should have put this in the first time, but the reason I'm not simply using merge is that changing the version number on master and then trying to merge with changes in dev causes merge conflicts. I know they are irrelevant, but it still stops the process. I've used "merge -Xtheirs {branch}" before to deal with it, but I'm not sure about that either.
UPDATE2: Here's some stuff that I know does not work. I've put together a bash script that works on Mac OSX. The first one attempts to use merge:
#!/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
The other way I tried this was with -Xtheirs, which looks like it works at first, but it doesn't update everything. To see that, remove the last few lines after the BREAK above and replace them with:
### 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
There are no conflicts, but 'output-master-test1-c.txt' shows 'VERSION-2.0' instead of 'VERSION-XXX' which is desired. This appears to have happened because there were no changes to the file. The 'output-master-test2-c.txt' file has the expected 'VERSION-XXX' sting. The problem, of course, is that the find and replace that tried to update to version 3.0 would miss in test1-c because it wouldn't recognize the 2.0 part of the VERSION sting.
You should use real merges instead of the diff/apply hack. This is as simple as
[master]$ git merge dev
When you run this on the master branch (shown in prompt) you will merge in all changes from dev. Afterwards you can update the version number, commit and create a tag
[master]$ git commit -a -m "New version number."
[master]$ git tag version-1.x
It's as simple as that.
In fact you don't really need a master branch at all, you can create a short lived release branch based on dev, create a tag there and delete the branch afterwards.
[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
这篇关于为本地存储库上的单个开发人员开发的Git工作流程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
