===== Merging multiple git commits into a single commit ===== Here is a link to a good article on this: https://cswiki.cs.byu.edu/cs431/index.php/Git_Basics#Flattening_Revision_History The useful part: ==== Flattening Revision History ==== When working on a feature in an existing code base, you'll probably want to commit often to keep track of your progress. However, when you finish your feature and you're ready to send a patch to an upstream repository, you probably won't want to send them all of your revision history including your commits, lame comments, and bad choices. So the question becomes, how do you coax Git to generate a single commit (patch) for an upstream repository with an appropriate comment when your current revision history is riddled with many commits? The answer depends on whether you did your work in a branch, as suggested above. === If your changes are in a development branch === First, bring your devel branch and master branch up to the current revision HEAD in the upstream repository (i.e., origin): $ git rebase origin git rebase first unwinds your commits to the branch point, applies all the changes form matching upstream branch, and reapplies your commit history marking conflicts as they arise. For each conflict, the rebase stops to allow you to resolve the conflict before moving to the next commit to apply. Once you have fixed any conflicts etc. to synchronize with any changes on the master branch that occurred after you branched devel from master, then you are ready to flatten your revision history into a single commit. $ git checkout master $ git merge --squash --no-commit myDev The merge command applies all of your revision history to the master branch, but it does not perform the intermediate commits on the revision history. In other words, it makes all of the changes, but commits none of the changes. Again, fix any conflicts that happen during the merge. Once you have fixed conflicts, you are ready to perform a single commit with all of your changes: $ git commit -a -m "Added new feature ...." From here you can create a patch or push upstream depending on the rules for the origin. For this course, you'll be creating and emailing patches. To format a patch for emailing: $ git format-patch origin..HEAD As a note, you actually do not even need to do the commit if it is not desired. The roll back to master is easy if needed. On the master branch, do $ git-checkout -f Regardless, all your work is rolled into one single change that you can either commit, use to generate a patch, or toss out completely. In any case, your development branch and revision history is preserved. === If your changes are on the master branch === If you made your changes on the master branch, you'll have to create a new branch that's synced to the latest upstream commit, and then apply your changes to the branch. Pull the latest changes from the upstream repository and merge them into the local copy $ git rebase origin List commit history $ git log Look through log results until you find the latest upstream commit; note its id create a new branch named "upstream", branched from the last upstream commit, identified from the log $ git branch upstream <upstream commit id, e.g. d1bdb9e7dea3099cd2466edd2fe45af1e55c2a11> Switch to the new, clean branch $ git checkout upstream Merge and squash everything from master into the clean branch $ git merge --squash --no-commit master Commit the merged changes $ git commit -a -m "Your log message here" Create a patch file $ git format-patch origin..HEAD