markrebec

Git Workflow Comparison: Squash-and-Merge vs. Merge Commits

This guide outlines the technical trade-offs between "Squash and Merge" and standard "Merge Commits." While squashing offers a simple aesthetic, it introduces significant friction for complex engineering and historical recovery.

1. The "Stacked PR" Friction (Phased Work)

Squash Workflow (The "Manual" Way)

When you Squash and Merge, Git replaces all original commits with one brand-new commit hash on main. This "orphans" any follow-up branches.

1. Identify the Boundary: You must manually find the exact commit hash where Phase 2 diverged from Phase 1.
2. Run Rebase --onto: git rebase --onto main phase-2-branch

markrebec

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: httpbin
spec:
  hosts:
  - "*"
  gateways:
  - istio-system/cluster-gateway
  http:

markrebec

require 'net/http'
require 'json'

gem_name = ARGV[0]

def rubygems_get(gem_name: "", endpoint: "")
  path = File.join("/api/v1/gems/", gem_name, endpoint).chomp("/") + ".json"
  JSON.parse(Net::HTTP.get("rubygems.org", path))
end

markrebec

namespace :logs do

  desc "Download all log files from all hosts"
  task :fetch do
    on roles(:all) do
      capture(:ls, "#{shared_path}/log/").split(' ').each do |logfile|
        download! File.join(shared_path, 'log', logfile), File.join('.', 'tmp', "#{host}.#{logfile}")
      end 
    end 
  end