git-process 0.9.4 → 0.9.5

data/Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    git-process (0.9.4)
+    git-process (0.9.5)
       highline (~> 1.6.12)
       json (~> 1.7.3)
       launchy (~> 2.1.0)

data/README.md

@@ -1,22 +1,39 @@
 [![Build Status](https://secure.travis-ci.org/jdigger/git-process.png)](http://travis-ci.org/jdigger/git-process)
 
-# Purpose #
+# Purpose and Motivation #
 
 This provides an easy way to work with a sane git workflow process.
-
+Short-lived feature branches can work quite well, but the formal git-flow process can be rather heavy in cost.
 
 # Installation #
 
-    $ gem install git-process
+    $ sudo gem install git-process
+
+## Configurables ##
+See notes for more details
 
+* OAuth2 Token 
+* The name of the integration branch (defaults to `origin/master`, but can be set to `develop` or other)
 
+---
 # Overview #
 
+## Anticipated Use Cases ##
+
+1. User Creates new local branch
+1. User pushes local branch to remote (as feature branch) by rebasing integration branch, then pushing branch to remote
+1. User closes local branch by rebasing integration branch first, then pushing local to integration
+1. User initiates GitHub "pull request"
+
+## Command List ##
+
 * `git new-fb` - Create a new feature branch based on the integration branch.
 * `git sync` - Gets the latest changes that have happened on the integration branch, then pushes your changes to a "private" branch on the server.
 * `git pull-request` - Creates a Pull Request for the current branch.
 * `git to-master` - Rebase against the integration branch, then pushes to it.
 
+**All commands are well documented within themselves: Use the "-h" switch to see the full documentation.** (e.g., "`git sync -h`")
+
 # Workflow #
 
 _The following assumes that the integration branch is "origin/master"._
@@ -26,7 +43,7 @@ _The following assumes that the integration branch is "origin/master"._
 1. When starting work on a new feature, use "`git new-fb feature-name`".
     * This creates a new branch called "`feature-name`" based on "`origin/master`".
 2. After making some changes, if you want to pick up any changes other people have made, as well
-   as save your work on the server, do "`git synch`".
+   as save your work on the server, do "`git sync`".
     * That will merge in the changes that have occurred in "`origin/master`" and then push the
       result to the "`feature_branch`" branch to the server.
 3. When you feel your work is ready for others to look at, do another "`git sync`" to post your
@@ -41,7 +58,7 @@ _The following assumes that the integration branch is "origin/master"._
 1. When starting work on a new feature, use "`git new-fb feature-name`".
     * This creates a new branch called "`feature-name`" based on "`origin/master`".
 2. After making some changes, if you want to pick up any changes other people have made, as well
-   as save your work on the server, do "`git synch`".
+   as save your work on the server, do "`git sync`".
     * That will merge in the changes that have occurred in "`origin/master`" and then push the
       result to the "`feature_branch`" branch to the server.
 3. When you are ready to merge your work into the mainline, "`git to-master`".
@@ -71,6 +88,45 @@ _The following assumes that the integration branch is "origin/master"._
 * This tries to respond "intelligently" to the use of 'rerere'.
 
 
+# FAQ #
+
+## Q: How is this different from git-flow or GitHub flow? ##
+
+["git-flow"](http://nvie.com/posts/a-successful-git-branching-model/) is designed around having a very strongly defined process around keeping new development, hotfixes, release process changes, etc. all clearly separated. The problem I have with it is that it's too much "process" for not enough gain. (It has a waterfall feel to it, very much against the more modern [Continuous Delivery](http://continuousdelivery.com/) approach.)
+
+["GitHub Flow"](http://scottchacon.com/2011/08/31/github-flow.html) is a lot cleaner, but relies too heavily (IMHO) on web-based tools and on merging instead of rebasing. It is also focussed very tightly on a Continuous Deployment process, which is great for them, but not practical for everyone.
+
+
+## Q: Wait, I heard "branches are evil." Why should I do something evil? ##
+
+Branches are extremely powerful tools that allow for clean organization/modularization of development.
+
+* Branches make it easy to sandbox changes while they are in a state of flux, while at the same time be very fearless about making potentially breaking changes.
+    * For example, I commit "green to green": Doing [TDD](http://en.wikipedia.org/wiki/Test-driven_development), I commit every time I have a newly passing test case. So, assuming I'm in a regular development flow, I'm committing my changes every five minutes. Tiny commits, but lots of them. What that means is that if I make a "less than wise choice" at some point, it's trivial to rewind to before I'd made the mistake, potentially keep the throw-away code in another branch while I do my cleanup, and generally use the full power of a revision control system to make my life safer and easier. The branch(es) are pretty chaotic, but that's not a problem because before integrating with the mainline, I take a moment to cleanup: Squash related commits together, write clearer commit messages (since now I know what "the answer" is), and generally move from my drafts to a more finished result. (See below on objections related to "lying with rebase.") That may just be me, though, because I'm very paranoid when it comes to computers. I tend to automatically hit Cmd/Ctl-S every time I type a period when I'm writing, or when I close a block when I'm programming. I have a minimum of three copies/backups around the world of all my important documents. And I "`git sync`" frequently to make sure my machine isn't the only place where all my hard work is being stored. Have I mentioned I don't trust computers?
+
+* Branches allow for focused collaboration. Because a branch is about exactly one thing, it means that a team can collaborate around a feature/bug (especially when used in conjunction with a "pull request"), and keep such changes sandboxed until such time that they are ready to bring a larger audience into the mix.
+    * Branches encourage being less "shy" about your code. I have heard, on a number of occasions, developers say "I'm not ready to push this to the server yet because [it's still rough (and embarrassing)]/[it may break other people]/etc." All of those reasons for "hoarding" code are moot with branches.
+
+Jez Humble, a brilliant Principle at ThoughtWorks Studios, talks a lot about how "branches are evil." Unfortunately, people hear that, know how smart he is, and simply repeat it without really understanding what his objections are. Fortunately, he [posted clarification about what's really meant by that](http://continuousdelivery.com/2011/07/on-dvcs-continuous-integration-and-feature-branches/). He essentially says that the problem is that developers abuse branches by not merging with mainline (i.e., "master") on a regular basis. Not constantly getting changes *from* mainline makes life rough when it comes time to integrate. Not putting your changes *into* mainline means that your changes are not being validated (via [Continuous Integration](http://martinfowler.com/articles/continuousIntegration.html), or -- better -- with [Continuous Delivery](http://continuousdelivery.com/)). Both are, in fact, sins akin to not doing automated testing.
+
+Making it "easier to do things right than wrong" (i.e., using branches and keeping them synced with mainline) was the primary motivation for this project. This should be especially evident in the "`git sync`" and "`git to-master`" commands.
+
+
+## Q: Why so much emphasis on rebasing? Isn't rebasing a dangerous lie? ##
+
+Like any powerful tool, "`git rebase`" is "dangerous" if used incorrectly, just like "`rm -rf`". You simply need to know when and how to use it safely. And in the world of version control systems, "rebasing" is easily one of the most _**useful**_ tools to come around since the "`commit`" command.
+
+[A famous article](http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-ammend.html) that people have been parroting in various forms for a while makes the case that rebasing (and its various forms, such as squashing, amending commits, etc.) is a "lie." As with so many things, context is everything.
+
+You almost certainly should *not* rebase things that you have "published." Generally this really means "Don't rebase the 'master' branch!" Fortunately, these scripts make it impossible to rebase the mainline by accident. By default "`git sync`" uses "merge" instead of "rebase" to encourage collaboration. (Though you can easily use "-r" if you know no one else is working on the branch.) When it's time to actually merge your work into the mainline (and thus no one is working against it except in the context of mainline), that's when it gets rebased in.
+
+Rebasing "your" code is an extremely useful way of communicating clearly. In the "green to green" scenario above about branches, a lot of noise is generated. If someone wants to review my code, or cherry-pick in my changes, it's too much of a mess to effectively do so. Also, as part of the process of squashing, I have the opportunity to write clearer commit message based upon my newly enhanced understanding. The intermediate commits were my "drafts" and I'm now submitting my cleaned up copy.
+
+If you have ever seen an "active" project that uses a process like "git-flow" that encourages a lot of branching and merging, you've seen how hard it can be to follow a particular line of development. Branch lines are flying around everywhere, and half the commits are pretty much pure noise. (e.g., "Merge branch 'develop' of ... into develop".) It's also hard to follow the order in which commits actually impacted the mainline. In many ways, in practice merges turn into "a truth effectively being a lie (because it's buried in the noise)" versus rebases that are "a lie (changed from it's 'original' form) to tell an effective truth (clean and very clear about its impact)."
+
+I am trying to promote clear communication about current reality over micro-management over no-longer-relevant history. Thus the judicious use of rebase.
+
+
 # Contributing #
 
 ## Coding Setup ##

data/bin/git-sync

@@ -17,7 +17,7 @@ DESCRIPTION
 
 This fetches the latest repository from the server, rebases/merges the current branch \
 against the changes in the integration branch, then pushes the result up to a branch on \
-the server of the same name.
+the server of the same name. (Unless told not to.)
 
 If there is a problem, such as a merge conflict, this tries to \
 resolve it automatically. If it can not do so in an automated way, \
@@ -40,8 +40,10 @@ DESC
     parser.opt :rebase, "Rebase instead of merge against the integration branch"
     parser.opt :merge, "Merge instead of rebase against the integration branch", :short => :none, :default => true
     parser.opt :force, "Force the push; defaults to true if --rebase is used", :short => :f, :default => false
+    parser.opt :local, "Do not do a push; gets remote changes, but does not update the server", :short => :l, :default => false
 
     parser.conflicts :rebase, :merge
+    parser.conflicts :local, :force
   end
 
 

data/lib/git-process/git_process.rb

@@ -71,6 +71,11 @@ module GitProc
     end
 
 
+    def integration_branch
+      has_a_remote? ? remote_master_branch : master_branch
+    end
+
+
     def Process.log_level(opts)
       if opts[:quiet]
         Logger::ERROR

data/lib/git-process/new_fb.rb

@@ -31,7 +31,7 @@ module GitProc
         mybranches.parking.delete
         new_branch
       else
-        checkout(@branch_name, :new_branch => remote_master_branch)
+        checkout(@branch_name, :new_branch => integration_branch)
       end
     end
 

data/lib/git-process/sync.rb

@@ -21,8 +21,17 @@ module GitProc
   class Sync < Process
 
     def initialize(dir, opts)
+      opts[:force] = true if opts[:rebase]
+
+      if !opts[:merge].nil? and opts[:merge] == opts[:rebase]
+        raise ArgumentError.new(":merge = #{opts[:merge]} and :rebase = #{opts[:rebase]}")
+      end
+
+      raise ArgumentError.new(":rebase is not set") if opts[:rebase].nil?
+
       @do_rebase = opts[:rebase]
       @force = opts[:force]
+      @local = opts[:local]
       super
     end
 
@@ -31,8 +40,8 @@ module GitProc
       raise UncommittedChangesError.new unless status.clean?
       raise ParkedChangesError.new(self) if is_parked?
 
-      current_branch = branches.current
-      remote_branch = "#{server_name}/#{current_branch}"
+      @current_branch ||= branches.current
+      @remote_branch ||= "#{server_name}/#{@current_branch}"
 
       fetch(server_name)
 
@@ -42,19 +51,30 @@ module GitProc
         proc_merge(remote_master_branch)
       end
 
-      old_sha = command('rev-parse', remote_branch) rescue ''
-
-      unless current_branch == master_branch
-        fetch(server_name)
-        new_sha = command('rev-parse', remote_branch) rescue ''
-        unless old_sha == new_sha
-          logger.warn("'#{current_branch}' changed on '#{server_name}'"+
-                      " [#{old_sha[0..5]}->#{new_sha[0..5]}]; trying sync again.")
-          sync_with_server(@do_rebase, @force)
-        end
-        push(server_name, current_branch, current_branch, :force => @force)
+      if @local
+        logger.debug("Not pushing to the server because the user selected local-only.")
+      elsif @current_branch == master_branch
+        logger.warn("Not pushing to the server because the current branch is the mainline branch.")
       else
-        logger.warn("Not pushing to the server because the current branch is the master branch.")
+        old_sha = rev_parse(@remote_branch) rescue ''
+
+        handle_remote_changed(old_sha)
+
+        push(server_name, @current_branch, @current_branch, :force => @force)
+      end
+    end
+
+
+    private
+
+
+    def handle_remote_changed(old_sha)
+      fetch(server_name)
+      new_sha = rev_parse(@remote_branch) rescue ''
+      unless old_sha == new_sha
+        logger.warn("'#{@current_branch}' changed on '#{server_name}'"+
+                    " [#{old_sha[0..5]}->#{new_sha[0..5]}]; trying sync again.")
+        runner # try again
       end
     end
 

data/lib/git-process/version.rb

@@ -14,7 +14,7 @@ module GitProc
   module Version
     MAJOR = 0
     MINOR = 9
-    PATCH = 4
+    PATCH = 5
     BUILD = nil
 
     STRING = [MAJOR, MINOR, PATCH, BUILD].compact.join('.')

data/spec/new_fb_spec.rb

@@ -56,6 +56,15 @@ describe GitProc::NewFeatureBranch do
     end
 
 
+    it "should use 'integration_branch' instead of 'remote_master_branch'" do
+      change_file_and_commit('a', '')
+
+      new_branch = gitprocess.run
+
+      new_branch.name.should == 'test_branch'
+    end
+
+
     it "should bring new/uncommitted changes on _parking_ over to the new branch" do
       gitprocess.branch('origin/master', :base_branch => 'master')
       gitprocess.checkout('_parking_', :new_branch => 'master')

data/spec/sync_spec.rb

@@ -15,51 +15,69 @@ describe GitProc::Sync do
   end
 
 
+  def log_level
+    Logger::ERROR
+  end
+
+
   def create_process(dir, opts)
-    opts[:rebase] = false
-    opts[:force] = false
-    GitProc::Sync.new(dir, opts)
+    GitProc::Sync.new(dir, opts.merge({:rebase => false, :force => false}))
   end
 
 
-  describe "#run" do
+  it "should work when pushing with fast-forward" do
+    change_file_and_commit('a', '')
 
-    def log_level
-      Logger::ERROR
+    gitprocess.branch('fb', :base_branch => 'master')
+
+    clone('fb') do |gp|
+      change_file_and_commit('a', 'hello', gp)
+      gp.branches.include?('origin/fb').should be_true
+      gp.runner
+      gp.branches.include?('origin/fb').should be_true
+      gitprocess.branches.include?('fb').should be_true
     end
+  end
 
 
-    it "should work when pushing with fast-forward" do
-      change_file_and_commit('a', '')
+  it "should work with a different remote server name" do
+    change_file_and_commit('a', '')
 
-      gitprocess.branch('fb', :base_branch => 'master')
+    gitprocess.branch('fb', :base_branch => 'master')
 
-      clone('fb') do |gp|
-        change_file_and_commit('a', 'hello', gp)
-        gp.branches.include?('origin/fb').should be_true
-        gp.run
-        gp.branches.include?('origin/fb').should be_true
-        gitprocess.branches.include?('fb').should be_true
-      end
+    clone('fb', 'a_remote') do |gp|
+      change_file_and_commit('a', 'hello', gp)
+      gp.branches.include?('a_remote/fb').should be_true
+      gp.runner
+      gp.branches.include?('a_remote/fb').should be_true
+      gitprocess.branches.include?('fb').should be_true
     end
+  end
 
 
-    it "should work with a different remote server name" do
-      change_file_and_commit('a', '')
+  it "should fail when pushing with non-fast-forward and no force" do
+    change_file_and_commit('a', '')
 
-      gitprocess.branch('fb', :base_branch => 'master')
+    gitprocess.branch('fb', :base_branch => 'master')
 
-      clone('fb', 'a_remote') do |gp|
-        change_file_and_commit('a', 'hello', gp)
-        gp.branches.include?('a_remote/fb').should be_true
-        gp.run
-        gp.branches.include?('a_remote/fb').should be_true
-        gitprocess.branches.include?('fb').should be_true
+    clone('fb') do |gp|
+      gitprocess.checkout('fb') do
+        change_file_and_commit('a', 'hello', gitprocess)
       end
+
+      expect {gp.runner}.should raise_error GitProc::GitExecuteError
     end
+  end
+
 
+  describe "when forcing the push" do
+
+    def create_process(dir, opts)
+      GitProc::Sync.new(dir, opts.merge({:rebase => false, :force => true}))
+    end
 
-    it "should fail when pushing with non-fast-forward and no force" do
+
+    it "should work when pushing with non-fast-forward" do
       change_file_and_commit('a', '')
 
       gitprocess.branch('fb', :base_branch => 'master')
@@ -69,81 +87,84 @@ describe GitProc::Sync do
           change_file_and_commit('a', 'hello', gitprocess)
         end
 
-        expect {gp.run}.should raise_error GitProc::GitExecuteError
+        expect {gp.runner}.should_not raise_error GitProc::GitExecuteError
       end
     end
 
   end
 
 
-  describe "when forcing the push" do
+  describe "when rebasing" do
 
     def create_process(dir, opts)
-      opts[:force] = false
-      opts[:force] = true
-      GitProc::Sync.new(dir, opts)
+      GitProc::Sync.new(dir, opts.merge({:rebase => true, :force => false}))
     end
 
 
-    it "should work when pushing with non-fast-forward" do
+    it "should work when pushing (non-fast-forward)" do
       change_file_and_commit('a', '')
 
       gitprocess.branch('fb', :base_branch => 'master')
 
       clone('fb') do |gp|
         gitprocess.checkout('fb') do
-          change_file_and_commit('a', 'hello', gp)
+          change_file_and_commit('a', 'hello', gitprocess)
         end
 
-        expect {gp.run}.should_not raise_error GitProc::GitExecuteError
+        expect {gp.runner}.should_not raise_error GitProc::GitExecuteError
       end
     end
 
   end
 
 
-  describe "sync_with_server with different remote name" do
-
-    def log_level
-      Logger::ERROR
-    end
-
+  describe "when forcing local-only" do
 
     def create_process(dir, opts)
-      opts[:force] = false
-      opts[:force] = true
-      gp = GitProc::Sync.new(dir, opts)
-      gp.instance_variable_set('@server_name', 'a_remote')
-      gp
+      GitProc::Sync.new(dir, opts.merge({:rebase => true, :force => false, :local => true}))
     end
 
 
-    it "should work with a different remote server name" do
+    it "should not try to push" do
       change_file_and_commit('a', '')
 
       gitprocess.branch('fb', :base_branch => 'master')
 
-      clone('fb', 'a_remote') do |gp|
-        change_file_and_commit('a', 'hello', gp)
-        gp.branches.include?('a_remote/fb').should be_true
-        gp.run
-        gp.branches.include?('a_remote/fb').should be_true
-        gitprocess.branches.include?('fb').should be_true
+      clone('fb') do |gp|
+        gitprocess.checkout('fb') do
+          change_file_and_commit('a', 'hello', gitprocess)
+        end
+
+        gp.should_receive(:fetch) # want to get remote changes
+        gp.should_not_receive(:push) # ...but not push any
+
+        gp.runner
       end
     end
 
   end
 
 
-  describe "remove current feature branch when used while on _parking_" do
+  it "should work with a different remote server name than 'origin'" do
+    change_file_and_commit('a', '')
 
-    it 'should fail #sync_with_server' do
-      gitprocess.checkout('_parking_', :new_branch => 'master')
-      change_file_and_commit('a', '')
+    gitprocess.branch('fb', :base_branch => 'master')
 
-      expect {gitprocess.runner}.should raise_error GitProc::ParkedChangesError
+    clone('fb', 'a_remote') do |gp|
+      change_file_and_commit('a', 'hello', gp)
+      gp.branches.include?('a_remote/fb').should be_true
+      gp.runner
+      gp.branches.include?('a_remote/fb').should be_true
+      gitprocess.branches.include?('fb').should be_true
     end
+  end
+
+
+  it 'should fail when removing current feature while on _parking_' do
+    gitprocess.checkout('_parking_', :new_branch => 'master')
+    change_file_and_commit('a', '')
 
+    expect {gitprocess.runner}.should raise_error GitProc::ParkedChangesError
   end
 
 end

metadata

@@ -5,8 +5,8 @@ version: !ruby/object:Gem::Version
   segments: 
   - 0
   - 9
-  - 4
-  version: 0.9.4
+  - 5
+  version: 0.9.5
 platform: ruby
 authors: 
 - Jim Moore
@@ -14,7 +14,7 @@ autorequire:
 bindir: bin
 cert_chain: []
 
-date: 2012-07-10 00:00:00 -06:00
+date: 2012-07-18 00:00:00 -06:00
 default_executable: 
 dependencies: 
 - !ruby/object:Gem::Dependency