title: Git workflow for a single developer on a local repository
body: <p>I'm trying to refine a personal git workflow to something a little easier to deal with.</p>
  
  <p>Here's some background of how I'm using git for purposes of this post:</p>
  
  <ul>
  <li><p>A single developer who is the only one working on the repository.</p></li>
  <li><p>A single copy of the repository that is stored on the local machine.</p></li>
  <li><p>Only two branches "dev" and "master".</p></li>
  <li><p>All work done on "dev".</p></li>
  </ul>
  
  <p>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. </p>
  
  <p>Effectively, what I'm looking to do is:</p>
  
  <ol>
  <li><p>When everything in "dev" is tested and ready to go, update "master" to be an exact clone of the "dev" branch file tree. </p></li>
  <li><p>Make minor modifications to "master" to update version numbers, etc...</p></li>
  <li><p>Commit to the updated "master" branch. </p></li>
  <li><p>Make a new tag from the "master" branch. </p></li>
  </ol>
  
  <p>The way that I'm approaching the first step is to checkout the "master" branch and then to run:</p>
  
  <pre><code>'git diff master dev | git apply -'
  </code></pre>
  
  <p>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. </p>
  
  <p>So, the first question: <em>Is that correct?</em></p>
  
  <p>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. </p>
  
  <p>So, the other question: <em>Is there anything in that process that is going to cause issues?</em></p>
  
  <p>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. </p>
  
  <p>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:</p>
  
  <pre><code>#!/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*" &gt; .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" &gt; test1.txt
  echo -e "File2 LINE\nVERSION-XXX\nFILE2 LINE" &gt; 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 &gt; output-dev-test1-a.txt
  cat test2.txt &gt; 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 &gt; output-master-test1-a.txt
  cat test2.txt &gt; 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 &gt; output-dev-test1-b.txt
  cat test2.txt &gt; 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
  </code></pre>
  
  <p>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:</p>
  
  <pre><code>### 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 &gt; output-master-test1-b.txt
  cat test2.txt &gt; 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 &gt; output-dev-test1-c.txt
  cat test2.txt &gt; 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 &gt; output-master-test1-c.txt
  cat test2.txt &gt; output-master-test2-c.txt
  </code></pre>
  
  <p>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.</p>