Curriculum

User Tools

Site Tools

Trace:
git

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
git [2026/06/07 00:19] – [commit] jhagstrandgit [2026/06/14 09:18] (current) – [Squash Merge] jhagstrand
Line 29: Line 29:
   * HEAD - ?   * HEAD - ?
   * detached head - ?   * detached head - ?
 +  * tree-ish ?
   * commit-ish   * commit-ish
   * SHA-1 value   * SHA-1 value
Line 91: Line 92:
 The commit command creates a commit. The commit command creates a commit.
  
-Each commit is a version of the source code.+Each commit is a new version of the source code.
  
 Initial edits to a text file are tentative.  The commit command makes those edits permanent. Initial edits to a text file are tentative.  The commit command makes those edits permanent.
Line 112: Line 113:
   line 2 is blank, this is what signals git to split title and body   line 2 is blank, this is what signals git to split title and body
   line 3+ is body, max 72 chars per line, hit enter to hardcode each newline   line 3+ is body, max 72 chars per line, hit enter to hardcode each newline
 +
 +The commit message title style guide.
 +  * Like a document sub-heading
 +  * Imperative
 +  * Start with capital letter, no period at the end
 +  * No articles or filler
 +
  
 The history log of commit messages, combined with skillful use of the branch, merge, reset, and rebase commands enable a programmer to communicate to future developers exactly what he changed and how, why and when. The history log of commit messages, combined with skillful use of the branch, merge, reset, and rebase commands enable a programmer to communicate to future developers exactly what he changed and how, why and when.
Line 128: Line 136:
   git show       # details of latest commit   git show       # details of latest commit
   git tag -d 1.0 # delete a tag   git tag -d 1.0 # delete a tag
 +
 +Tags are often used to implement public release versioning.  There are three common version formats.
 +
 +  * Marketing Versioning, like macOS Sonoma
 +
 +  * Calendar Versioning, like 2026.06.04
 +
 +  * Semantic Versioning (SemVer)
 +    * see https://semver.org/
 +    * major.minor.patch, like v3.6.2
 +    * minor and patch releases maintain backward compatibility
 +    * as soon as backward compatibility is broken, the major number must be incremented
 +    * important for a library with a public api, for example
 +
 +(I remember the good old days, when broken backward compatibility was a sign of incompetence.)
 +
 ====worktree==== ====worktree====
  
Line 161: Line 185:
  
 in the the meantime, to bring master changes into the feature, do a rebase,  in the the meantime, to bring master changes into the feature, do a rebase, 
- handle the conflicts now, so the future feature merge will run without conflicts+  * handle the conflicts now, so the future feature merge will run without conflicts 
 +  * handle conflicts conflicts in the feature branch, not when attempting the final feature merge
  
-handle conflicts conflicts in the feature branch, not when attempting the final feature merge+ 
 +==== Merge ==== 
 + 
 +  # merge a feature branch back into the master branch 
 +  git checkout master 
 +  git merge feature 
 + 
 +That simple command "git merge feature" operates in three different ways. 
 + 
 +First it checks whether any changes have been made to the master branch. And if so, it checks whether there are conflicts with changes made to the feature branch. 
 + 
 + - No changes made on master branch.  The merge will execute a **fast-forward**.  No actual merge is necessary.  Git just moves the master pointer to the top of the feature branch. 
 + 
 + - Changes have been made on the master, but no conflicts. Now we are in a merge situation. Instead of doing a fast forward, it merges the updated files as necessary and then automatically commits those updated files.  That is called the merge commit. All of the commits made in the branch stay in the log but in a loop. 
 + 
 + - Changes have been made on the master, and there are conflicts.  That means changes were made to the same lines in the same file in both the master and the feature branch.  Human decision-making is required here.  The merge stops.  The human resolves the conflicts, executes git merge --resume, and then does the merge commit manually. 
 + 
 + 
 +Starting situation\\ 
 +There are commits on the feature branch.\\ 
 +What about the master branch?  There are three possibilities: 
 +  * no commits on the master 
 +  * commits on the master but no conflicts 
 +  * commits on the master with conflicts 
 + 
 +Desired outcome.\\ 
 +The master branch is up-to-date, and the feature branch is gone.\\ 
 +But how will the log look?  There are three possibilities: 
 +  * Linear. The feature branch commits are all present in the master branch, as if the branch never existed. 
 +  * Indented. The feature branch commits have are all present, but indented under a merge commit, so you can see there must have been a branch there at one time.  
 +  * Collapsed. The feature branch commits are all gone, replaced by a single merge commit with a hand-written merge message that summarizes all the commits of the branch. 
 + 
 +==== Squash Merge ==== 
 + 
 +The --squash option, the merge command does not really do a merge.  Instead it copies all of the changed files from the feature branch to the master branch.  So now you do a single commit on the master branch, write a commit message summarizing all the individual commits made on the feature branch. 
 + 
 +This is one of the ways to collapse a developer's many chaotic commits into a single nice-looking well-thought-out commit.  
 + 
 +  # Make sure you're on the branch you want to merge into 
 +  git checkout master 
 +   
 +  # merge the feature branch with --squash option 
 +  # this stages all the file changes into the master branch 
 +  git merge --squash feature 
 +   
 +  # ask for status now and you'll see all the changes ready for commit 
 +  git status 
 +   
 +  # now commit 
 +  git commit -m "feat: add feature command" 
 +   
 +  # delete the feature branch 
 +  git branch -D feature 
 +   
 +  # for fun do a log all between these commands to see what's going on  
 +  git log --all --oneline -15 --graph --decorate 
 + 
 +==== Log ==== 
 + 
 +git commit adds an entry to the log. 
 + 
 +How to fuck with the log. 
 + 
 +  * git merge 
 +  * git rebase 
 +  * git reset 
 + 
 +git reset --hard HEAD^ 
 +Effectively deletes the most recent commit.  Equivalent to aider /undo.
  
  
Line 170: Line 263:
 The checkout command has two different functions.  This can be confusing if you ever have a branch and a file with the same name.  In 2019 the switch and restore commands were introduced.  They eliminate the confusion and the command names are more self-explanatory. The checkout command has two different functions.  This can be confusing if you ever have a branch and a file with the same name.  In 2019 the switch and restore commands were introduced.  They eliminate the confusion and the command names are more self-explanatory.
  
-^ old                   ^ new                  ^ +^ old                    ^ new                  ^ 
-| git checkout <branch> | git switch <branch>  | +| git checkout <branch>  | git switch <branch>  | 
-| git checkout <file>   | git restore <file>   |+| git checkout <file>    | git restore <file>   | 
 +| git checkout <commit>  | (none)   |
  
 The old checkout commands still work as always.  And kudos to the git developers for honoring backward compatibility. The old checkout commands still work as always.  And kudos to the git developers for honoring backward compatibility.
  
 +(Note that checkout of a commit is extraordinary and results in a detached HEAD.)
 ====diff==== ====diff====
  
Line 211: Line 306:
 git log --oneline --graph # shows a hierarchy of branches git log --oneline --graph # shows a hierarchy of branches
  
 +==== interactive rebase ====
  
 +If you don't like the way the log looks now, the interactive rebase command lets you fix, reorder, drop and squash the commits, and reword the commit messages.  Do this in a branch you are working solo, not a public branch or one that has already been pushed.
 +
 +  $ git switch mybranch
 +  $ git rebase -i HEAD~3
 +  $ git rebase -i b619fca0
 +
 +The log is displayed in reverse chronological order.
 +
 +The interactive rebase editor window displays the commits in chronological order.
 +
 +A note about reordering the commits.  The interactive rebase operation will start at the base and reapply your commits in new new order, rewriting your source code files in each commit.  It is possible to break code if you make a mistake.
 +
 +https://www.sitepoint.com/git-interactive-rebase-guide/
 ===== How to use ===== ===== How to use =====
  
 +
 +==== Configuration ====
 +
 +Use git config --global to set name and email.  
 +  * Support anonymity by using a shielded email, like for example the private GitLab noreply masked email.
 +  * Consider using a pair-programming persona as user.name to give credit to the AI author.
 +
 +  $ git config --global user.name "Your Name"
 +  $ git config --global user.name "Your Name & Gemini 1.5 Flash"  # pair-programming personna
 +  $ git config --global user.email "jerry@gmail.com"              # protect privacy on public host like gitlab
 +
 +Aider automatically adds a Co-authored by: line to the body.  Tell aider to skip that by adding parameters to .aider.conf.yml file:
 +  attribute-author: false
 +  attribute-committer: false
  
 ====Create a new repository==== ====Create a new repository====
git.1780805953.txt.gz · Last modified: 2026/06/07 00:19 by jhagstrand
Except where otherwise noted, content on this wiki is licensed under the following license: Public Domain
Public Domain Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki