问题
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.
回答1:
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
回答2:
I do something very similar (only when I'm the sole developer on my own software)...
I work SOLELY on the master branch. And at different 'versions', I create a dangling branch.
This enables me to get back to any previous version just by checking it out.
A - B - C - D - E - F
\ \
1.0 1.1
Easy and works good enough for my needs.
If I need to do some bug fixes to previous versions, i just work off of that branch and get them done.
回答3:
I've come up with another way to approach this that I think does everything I need. The heart of it is to do the following on 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"
This makes sure that all the version numbers in "dev" stay at "XXX" but are updated properly across all files in "master". Also, looking in gitk at the history of the "master" branch, you can see where the specific "dev" versions were added in. For example:
dev: d1----d2----d3----d4----d5
/ \ \ \
master: x m1 m2 m3
This tree is what I was looking for and makes it easier for me to get my head around exactly what is going on.
Here is a bash script (written on Mac OSX in case that matter) that I used to test and figure this out. If there is interest in trying other strategies, you should be able to just update the "doMerge" function and run the script to see what happens.
#!/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
From what I can tell, this works. I'll be giving it a shot and will report back here if I discover something. Of course, if you know of any, I'm also interested in other ways to do this that are less hacky.
来源：https://stackoverflow.com/questions/4056372/git-workflow-for-a-single-developer-on-a-local-repository