Lore

If it's worth remembering, it's worth writing down, if I find the time, and remember...

User Tools

Site Tools

Trace: • Building a Custom Windows Reference Image • Git Cheat-Sheet
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 [2018/05/09 15:51] – [Multiple Repos] thekojukinatorgit [2019/05/08 16:08] (current) – [PowerShell Visual Studio Code Template] thekojukinator
Line 7: Line 7:
   * https://www.atlassian.com/git/tutorials - More great tutorials here.   * https://www.atlassian.com/git/tutorials - More great tutorials here.
   * https://help.github.com - GitHub documentation.   * https://help.github.com - GitHub documentation.
 +  * https://guides.github.com/features/mastering-markdown - Markdown reference.
  
 I was using ''git version 2.16.2.windows.1'' in the //Bash// shell while documenting and testing these commands. I was using ''git version 2.16.2.windows.1'' in the //Bash// shell while documenting and testing these commands.
Line 16: Line 17:
 For further configuration options, see the [[https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration| Git documentation]]. For further configuration options, see the [[https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration| Git documentation]].
  
-=== Set name and e-mail address for commits ===+==== Contact Info for Commits ====
  
 <code bash> <code bash>
Line 23: Line 24:
 </code> </code>
  
-=== Set handling of line endings ===+==== Handling Line Endings ====
  
 <code bash> <code bash>
Line 34: Line 35:
 </code> </code>
  
-=== Set alias for pretty log output ===+A complementary setting in //Visual Studio Code// when developing on Windows is to enforce CRLF. 
 + 
 +<code css settings.json> 
 +{ 
 +    // this assumes Windows dev environment with Git config option "core.autocrlf=true" 
 +    "files.eol": "\r\n" 
 +} 
 +</code> 
 +==== Pretty Log Alias ====
  
 More helpful aliases are demonstrated [[https://githowto.com/aliases|here]]. More helpful aliases are demonstrated [[https://githowto.com/aliases|here]].
  
 This log command will give nice and pretty output: This log command will give nice and pretty output:
 +
 <code bash> <code bash>
 git log --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short git log --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short
 +# or without pagination
 +git --no-pager log --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short
 </code> </code>
  
 It can be configured in to a global alias like so: It can be configured in to a global alias like so:
 +
 <code bash> <code bash>
 git config --global alias.hist "log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short" git config --global alias.hist "log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short"
 +# unfortunately these won't work...
 +git config --global alias.hist "--no-pager log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short"
 +git config --global alias.hist "!git --no-pager log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short"
 +# but, this will disable pagination for all calls to 'log'
 +git config --global pager.log false
 +
 +# I've recently discovered some prettier log outputs, so my .gitconfig aliases are like so...
 +hist = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n''          %C(white)%s%C(reset) %C(dim white)- %an%C(reset)'
 +hist1 = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)'
 +hist2 = log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short
 +# first two are courtesy of https://stackoverflow.com/a/9074343
 </code> </code>
  
 So now it's simply enough to do: So now it's simply enough to do:
 +
 <code bash> <code bash>
 git hist git hist
Line 55: Line 80:
 </code> </code>
  
-=== Visual Studio Code as Git editor and diff tool ===+==== VSCode as Editor and Diff Tool ====
  
 More info [[https://code.visualstudio.com/docs/editor/versioncontrol|here]] about //Git// integration with //Visual Studio Code//. More info [[https://code.visualstudio.com/docs/editor/versioncontrol|here]] about //Git// integration with //Visual Studio Code//.
  
 Set //Visual Studio Code// as the default //Git// editor, and configure it to wait for the editor to close before continuing: Set //Visual Studio Code// as the default //Git// editor, and configure it to wait for the editor to close before continuing:
 +
 <code bash> <code bash>
 git config --global core.editor "code --wait" git config --global core.editor "code --wait"
Line 65: Line 91:
  
 Now it's possible to edit the //Git// config in //Visual Studio Code// like so: Now it's possible to edit the //Git// config in //Visual Studio Code// like so:
 +
 <code bash> <code bash>
 git config --global -e git config --global -e
Line 70: Line 97:
  
 Leveraging the above, add the following to ''.gitconfig'': Leveraging the above, add the following to ''.gitconfig'':
 +
 <code> <code>
 [diff] [diff]
Line 83: Line 111:
 git config -l git config -l
 # show global settings only # show global settings only
 +# these live in the user profile
 git config --global -l git config --global -l
 # show system settings only # show system settings only
 +# these live in the git installation path
 git config --system -l git config --system -l
-# show repo settings only (must be in repo folder)+# show local settings only 
 +# these live in the repo
 git config --local -l git config --local -l
 </code> </code>
Line 95: Line 126:
  
 Create a **repo** in the current folder: Create a **repo** in the current folder:
 +
 <code bash> <code bash>
 git init git init
Line 100: Line 132:
  
 Create a **repo** in the folder ''MyRepo''(folder will be created if it doesn't exist): Create a **repo** in the folder ''MyRepo''(folder will be created if it doesn't exist):
 +
 <code bash> <code bash>
 git init MyRepo git init MyRepo
Line 105: Line 138:
  
 From the parent folder, it's possible to clone a **repo** with: From the parent folder, it's possible to clone a **repo** with:
 +
 <code bash> <code bash>
 git clone <origin> <dest> git clone <origin> <dest>
Line 113: Line 147:
 NOTE: A cloned **repo** will have a single ''master'' **branch** and remote **branches** tracked from the origin **repo**. NOTE: A cloned **repo** will have a single ''master'' **branch** and remote **branches** tracked from the origin **repo**.
  
-=== Bare Repos ===+==== Bare Repos ====
  
 Doing ''git init'' or ''git clone'' commands with the ''--bare'' switch will make a **repo** without a working directory, only //Git// data. A **bare repo** is intended for sharing (fetch/push/pull) only. Doing ''git init'' or ''git clone'' commands with the ''--bare'' switch will make a **repo** without a working directory, only //Git// data. A **bare repo** is intended for sharing (fetch/push/pull) only.
Line 130: Line 164:
 ===== Multiple Repos ===== ===== Multiple Repos =====
  
-=== Syncing ===+==== Syncing ====
  
 Commits are pulled down from a remote **repo** via ''git fetch'', however this doesn't automatically merge them in to the local **branches**. Commits are pulled down from a remote **repo** via ''git fetch'', however this doesn't automatically merge them in to the local **branches**.
Line 142: Line 176:
  
 However, [[#merging]] remote fetched commits is the same as any other commits. This will merge all the commits from ''origin/master'' in to the currently checked out **branch**: However, [[#merging]] remote fetched commits is the same as any other commits. This will merge all the commits from ''origin/master'' in to the currently checked out **branch**:
 +
 <code bash> <code bash>
 git merge origin/master git merge origin/master
Line 166: Line 201:
 If, as mentioned in [[#managing remote repos]], local **branches** are already configured to track remote **branches**, it shouldn't be necessary to specify any parameters. Simply running ''git push'' should be enough. If, as mentioned in [[#managing remote repos]], local **branches** are already configured to track remote **branches**, it shouldn't be necessary to specify any parameters. Simply running ''git push'' should be enough.
  
-=== Tracking Branches ===+==== Tracking Branches ====
  
 When a **repo** is cloned, the only local **branch** is ''master'', and while the other remote **branches** are tracked, ''git pull'' and ''git push'' are only setup between the local and remote ''master'' **branches**. This can be confirmed by reviewing the remote configuration. When a **repo** is cloned, the only local **branch** is ''master'', and while the other remote **branches** are tracked, ''git pull'' and ''git push'' are only setup between the local and remote ''master'' **branches**. This can be confirmed by reviewing the remote configuration.
Line 180: Line 215:
  
 It is possible to create a local **branch** that tracks commits from a remote **branch**: It is possible to create a local **branch** that tracks commits from a remote **branch**:
 +
 <code bash> <code bash>
 # create a new localbranch to track remotebranch # create a new localbranch to track remotebranch
Line 188: Line 224:
  
 It is also possible to modify an existing local **branch** and set it to track commits from a remote **branch**: It is also possible to modify an existing local **branch** and set it to track commits from a remote **branch**:
 +
 <code bash> <code bash>
 # for currently checked out branch # for currently checked out branch
Line 206: Line 243:
 </code> </code>
  
-=== Managing Remote Repos ===+==== Managing Remote Repos ====
  
 <code bash> <code bash>
Line 263: Line 300:
 git remote set-branches --add origin dev1 git remote set-branches --add origin dev1
 </code> </code>
 +
 +When a tag is removed from the local **repo** it will not be removed from the remote **repo** via standard ''git push'' or even ''git push --all'', but there is a way to do it.
 +
 +<code bash>
 +# delete <tag> from <remoterepo>
 +git push <remoterepo> :<tag>
 +# ex:
 +git push origin :v1.0
 +</code>
 +
 +Alternatively, if new tags were created but there are no new commits, it's possible to push the tags to the remote **repo** via ''git push --tags''.
  
 ===== Stage, Confirm, Commit, and Tag ===== ===== Stage, Confirm, Commit, and Tag =====
Line 269: Line 317:
  
 Stage files: Stage files:
 +
 <code bash> <code bash>
 # a single file # a single file
Line 283: Line 332:
  
 Confirm **repo** status: Confirm **repo** status:
 +
 <code bash> <code bash>
 git status git status
Line 288: Line 338:
  
 Commit changes: Commit changes:
 +
 <code bash> <code bash>
 # commit and launch default editor to provide comment # commit and launch default editor to provide comment
Line 299: Line 350:
   * Stage the necessary files   * Stage the necessary files
   * Perform a new commit with the ''--amend'' switch   * Perform a new commit with the ''--amend'' switch
 +
 <code bash> <code bash>
 git commit --amend -m "Commit comment" git commit --amend -m "Commit comment"
Line 304: Line 356:
  
 Tag commits for easier management: Tag commits for easier management:
 +
 <code bash> <code bash>
 # tag the current commit with a friendly name # tag the current commit with a friendly name
Line 329: Line 382:
  
 This is not an undo, but instead of checking out files, it's possible to checkout a commit via the first 7 digits of the hash (from ''git hist'' if the [[#set alias for pretty log output|alias]] is defined), or tags: This is not an undo, but instead of checking out files, it's possible to checkout a commit via the first 7 digits of the hash (from ''git hist'' if the [[#set alias for pretty log output|alias]] is defined), or tags:
 +
 <code bash> <code bash>
 git checkout <hash> git checkout <hash>
Line 336: Line 390:
  
 To return to the latest commit do: To return to the latest commit do:
 +
 <code bash> <code bash>
 git checkout <branch> git checkout <branch>
Line 343: Line 398:
  
 Staged changes can be rolled back via ''git reset''. Staged changes can be rolled back via ''git reset''.
 +
 <code bash> <code bash>
 # unstage all currently staged changes # unstage all currently staged changes
Line 353: Line 409:
  
 NOTE: The working directory still has modified and unstaged files, use ''git checkout'' to replace them with committed version: NOTE: The working directory still has modified and unstaged files, use ''git checkout'' to replace them with committed version:
 +
 <code bash> <code bash>
 git checkout . git checkout .
Line 362: Line 419:
  
 This will cancel wherever ''HEAD'' is, which is usually the last commit: This will cancel wherever ''HEAD'' is, which is usually the last commit:
 +
 <code bash> <code bash>
 git revert HEAD git revert HEAD
Line 369: Line 427:
  
 To revert the working directory to a specified commit, and remove all later commits from history: To revert the working directory to a specified commit, and remove all later commits from history:
 +
 <code bash> <code bash>
 git reset --hard <hash> git reset --hard <hash>
Line 376: Line 435:
  
 NOTE: If removed commits had tags, those tags need to be removed or the commits will remain in history. This can be done after ''git reset'': NOTE: If removed commits had tags, those tags need to be removed or the commits will remain in history. This can be done after ''git reset'':
 +
 <code bash> <code bash>
 git tag -d BadVersion git tag -d BadVersion
Line 412: Line 472:
 Branches are managed via ''git branch'', switched via ''git checkout'', and merged via ''git merge''. Branches are managed via ''git branch'', switched via ''git checkout'', and merged via ''git merge''.
  
-=== Create, List, Checkout, and Delete ===+==== Create, List, Checkout, and Delete ====
  
 <code bash> <code bash>
Line 433: Line 493:
 </code> </code>
  
-=== Merging ===+==== Merging ====
  
 <code bash> <code bash>
Line 443: Line 503:
 </code> </code>
  
-=== Rebasing ===+==== Rebasing ====
  
 Branches can be rebased with ''git rebase''. Rebasing merges the **branch** histories in to a single thread, effectively performing a merge and then flattening the commit tree. Branches can be rebased with ''git rebase''. Rebasing merges the **branch** histories in to a single thread, effectively performing a merge and then flattening the commit tree.
Line 456: Line 516:
  
 NOTE: Rebasing can get tricky in some scenarios and cause issues, check the documentation for further details: NOTE: Rebasing can get tricky in some scenarios and cause issues, check the documentation for further details:
 +
 <code bash> <code bash>
 git rebase --help git rebase --help
Line 486: Line 547:
 </code> </code>
  
-=== PowerShell Visual Studio Code Template ===+==== PowerShell Visual Studio Code Template ====
  
 This is my baseline template for starting a //PowerShell// project in //Visual Studio Code//. It's effectively a white-list. This is my baseline template for starting a //PowerShell// project in //Visual Studio Code//. It's effectively a white-list.
Line 497: Line 558:
 !*/ !*/
  
-# allow .gitignore at top level +# allow .git* at top level 
-!.gitignore+!.git*
  
-# whitelist these file types everywhere +# allow .md at top level 
-!**/*.ps1 +!*.md 
-!**/*.psm1 + 
-!**/*.psd1 +# whitelist VSCode settings at the top level 
-!**/*.xml+!/.vscode/settings.json 
 + 
 +# whitelist contents of these folders at the top level 
 +!/ProjectFolderContainingAllTheGoodies/** 
 + 
 +# regardless of above, ignore these folders and files everywhere 
 +**/_logs* 
 +**/_testing*
  
-# regardless of above, ignore '.vscode' folder everywhere 
-**\.vscode/ 
 </code> </code>
  
git.1525895503.txt.gz · Last modified: 2018/05/09 15:51 by thekojukinator