git

• The Universe of Discourse : Things I wish everyone knew about Git (Part I)
  
  • Git from the Bottom Up
    
• First Git Mental Model
  

• Official Documentation and manual
  
• Interactive git tutorial
  
• Flight rules for Git
  
• Oh Shit, Git!?!
  
• https://wizardzines.com/zines/oh-shit-git/
  
• GIT PURR! Git Commands Explained with Cats! – GirlieMac! Blog
  
• game about learning git
  

• https://stevelosh.com/blog/2013/04/git-koans/
  Triggers “Aha!” moments about git concepts. Example:
  

    "How should I change to a different branch?" asked the programmer.
    "Use git checkout."
    "And how should I create a branch?"
    "Use git checkout."
    "And how should I update the contents of a single file in my working directory, without involving branches at all?"
    "Use git checkout."
  

• firstcontributions/first-contributions: 🚀✨ Help beginners to contribute to open source projects
  
• https://my-learning.w3schools.com/tutorial/git
  
• Git+Jupytext+Google Colab Workflow:
  
  • git_and_github_tips.ipynb - Colaboratory
    
  • 2. Version control with Git — BE/Bi 103 a documentation
    
• A Visual Git Reference
  
• Explain Git with D3
  

How do I delete a branch?

and then I have to ask them:

Well, what do you want to do? Do you wanna delete a local branch, and then just get it recreated when you pull again from the same remote? Or delete the remote tracking branch? Or delete the remote branch?

Fred Brooks described conceptual integrity as “the most important consideration in system design” and gave three principles upon which it is based:

• propriety – a product should have only the functions (concepts) essential to its purpose and no more, and
  
• generality a single function (concept) should be usable in many ways.
  

The authors add a fourth:

• consistency – requiring for example that actions behave in a similar way irrespective of the arguments they are presented with or the states in which they are invoked.
  

https://github.com/jonas/tig

TortoiseGit – TortoiseGit – Documentation – TortoiseGit – Windows Shell Interface to Git
https://tortoisegit.org/docs/tortoisegit/
https://tortoisegit.org/about/

https://apps.kde.org/dolphin_plugins/

• rebase squash
  git rebase -i HEAD~<number of commits to maybe squash>
  https://thoughtbot.com/blog/git-interactive-rebase-squash-amend-rewriting-history
  
• git pull sin cambiarse a esa rama
  git fetch origin master:master
  
• Mostrar un archivo de otra rama
  git show branch:file
  

• https://superuser.com/questions/232373/how-to-tell-git-which-private-key-to-use
  In ~/.ssh/config, add:
  

      Host github.com
       HostName github.com
       IdentityFile ~/.ssh/id_rsa_github
  

  Más sencillo:
  GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa_example" git clone example
  

• https://stackoverflow.com/questions/1143796/remove-a-file-from-a-git-repository-without-deleting-it-from-the-local-filesyste/21404811#21404811
  Ignore file changed
  

    git update-index --assume-unchanged superimportant-secret-key
  

A changelog is a kind of summary of commits

• GitHub - GavinMendelGleason/syntactic_versioning: What if Git worked with Programming Languages?
  
• https://github.com/afnanenayet/diffsitter
  
• https://github.com/auntbertha/ASTdiff
  
• difftastic
  
• locust
  
• gumtree
  
• diffr
  
• delta
  
• Semantic Diff Tool
  

https://github.com/lu0/syncthing-config/blob/master/pre-commit → alerta cuando comiteas código que no debes
Para pillar todo lo que hay en .env y pasarlo como credencial:

cat .env | awk -F = '{$1=""; print $0}' | sed -Ez 's/\n+/\n/g' | sed 's/^ //' | tr '\n' '|' | copy

#!/bin/bash

sensitive="apikey|password|urUniqueID"

flags=$(git diff -U0 --no-ext-diff --staged | grep -E -i --count "$sensitive")
if [ "$flags" -ne "0" ]; then
   echo "WARNING! You are attempting to commit sensitive data from:"
   git diff --no-ext-diff --staged --name-only -i -G "$sensitive" | sed 's/^/\t*/'
   echo -e "\nPlease review and unstage relevant hunks of those files with"
   echo -e "\tgit reset --patch"
   echo -e "\nCommit using the '--no-verify' option to ignore this warning (not recommended)\n\n"
   echo -e "Sensitive matches found:"
   git diff --no-ext-diff --staged | grep -E -i "$sensitive"
   exit 1
fi

• Rebase:
  
  • fearless-git: Rewrite Git History Like There’s No Tomorrow
    
  • Learn to change history with git rebase!
    One of Git’s core value-adds is the ability to edit history. Unlike other version control systems that treat the history as a sacred record, in git we can change history to suit our needs.
    
  • Branching and the power of rebase | Git from the Bottom Up
    
• Not Rebase:
  git is an historical archive of how the code was at a given moment of time, so rebasing is destroying that history
  
• You only Git Merge?!? feat Theo : DevHour #1 - YouTube
  
  • Rebasing creates source code states that never existed, since you take some change and reapplying them on top of a different history. For example git bisect doesn’t work with this
    
• Should You Squash Merge or Merge Commit? - Wait, so why don’t you like rebasing?
  Fundamentally, I dislike rebasing because of it’s possibly destructive nature. Sure, there are also a number of proponents of rebasing - usually spouting pithy advice such as “It’s not destructive, if you use Git right”.
  Git is already hard enough to use with a very poor and inconsistent developer experience that leads to too many mistakes. Telling developers to just “use Git right” when rebasing could result in you overwriting a team members work feels somewhat thoughtless
  Finally, merge conflicts during a rebase result in some of the worst developer experience imaginable. Each conflict will be represented one commit at a time ad nauseam. This is confusing and an easy way to pick the wrong side of the conflict. Reversing a rebase is difficult. Merge conflicts during a merge are presented all at once
  Discussion: https://www.reddit.com/r/programming/comments/whav9l/should_you_squash_merge_or_merge_commit/
  
• SQLite Doesn’t Use Git
  
  • Fossil: Rebase Considered Harmful
    
    1. Rebasing is dangerous
       
    2. Rebase provides no new capabilities
       
       1. A rebase is just a merge with historical references omitted
          
       2. Rebase does not actually provide better feature-branch diffs
          
    3. Rebase encourages siloed development
       
    4. Rebase causes timestamp confusion
       
    5. Rebase misrepresents the project history
       
    6. Collapsing check-ins throws away valuable information
       
       1. Individual check-ins support mutual understanding
          
       2. Bisecting works better on small check-ins
          
       3. Multiple check-ins require multiple check-in comments
          
       4. Cherry-picks work better with small check-ins
          
       5. Back-outs also work better with small check-ins
          
    7. Cherry-pick merges work better than rebase
       
    8. Summary and conclusion
       Rebasing is an anti-pattern. It is dishonest. It deliberately omits historical information. It causes problems for collaboration. And it has no offsetting benefits.
       For these reasons, rebase is intentionally and deliberately omitted from the design of Fossil.
       

• Squash, Merge, or Rebase?
  
  

  • Rebase rewrites history on top of a branch. This provides a linear history, meaning context is lost of where a feature branched off. You may also have to force push changes (since you are rewriting history) if you have already pushed to a remote.
    
  • Merge will create a merge commit that joins two branches together. With the fast-forward-only flag ff-only, git will attempt to merge without a merge commit, but this isn’t possible if the branches have diverged (i.e., there has been a commit to the parent branch that’s not on the feature branch).
    
  • Squash + Merge acts like merge but creates a single new squashed commit that encompasses all commits in the feature branch.
    

  I use rebase. Rebase retains a linear commit history, which is important for rollbacks. In addition, rebase is the most flexible workflow – larger and more difficult merges can be tough to do with a squash and merge. Interactive rebase has a bit of a steeper learning curve, but with practice, it can work in all scenarios. Squash and merge is OK for smaller changes, but it might be smarter to break large feature branches into multiple logical commits. This is useful for cherry-picking commits to other branches or repositories.
  

• Git team workflows: merge or rebase? | Atlassian Git Tutorial
  Rebase as team policy is a different thing than rebase as cleanup.
  
  • Rebase as cleanup, even when sharing your feature branch
    
    • You’re developing locally and have not shared your work even if you have pushed it. Rebase is fine
      
    • Your code is ready for review. You create a pull request, others are reviewing your work and are potentially fetching it into their fork for local review. You should not rebase
      You should create ’rework’ commits and update your feature branch. This helps with traceability in the pull request, and prevents the accidental history breakage.
      
    • Review is done and ready to be integrated into the target branch. Given that other developers won’t be fetch-merging, you can rebase now
      
  • Rebase as a team policy
    
    • ↑ Code history remains flat and readable. Clean, clear commit messages are documentation, do not to pollute history
      
    • ↑ Manipulating a single commit is easy (e.g. reverting them).
      
    • ↓ Squashing the feature down to a handful of commits can hide context, unless you keep around the historical branch with the entire development history.
      
    • ↓ Rebasing doesn’t play well with pull requests, because you can’t see what minor changes someone made if they rebased (never rebase during a pull request).
      
    • ↓ Rebasing can be dangerous and is prone to team work breakage
      This can be mitigated by doing the rebase/squash on a copy of the feature branch
      
    • It’s more work: Using rebase to keep your feature branch updated requires that you resolve similar conflicts again and again.
      You can reuse recorded resolutions (rerere) sometimes, but merges win here: Just solve the conflicts one time, and you’re set.
      
    • you need to force push at some point. If people haven’t set git push.default ⇒ updates to all branches having the same name, both locally and remotely, and that is dreadful to deal with.
      

NOTE: When history is rewritten in a shared branch touched by multiple developers breakage happens.

• The Biggest and Weirdest Commits in Linux Kernel Git History
  
• dolthub/dolt: Dolt – It’s Git for Data
  
• Developers: Your Git will change in 2022, with Dura | Dev Genius
  
• My favourite git commit
  
• Git Things
  

https://github.com/GavinMendelGleason/excel_as_code

La idea es hacer un montón de commits en local y luego juntarlos antes de subirlos

alias gwip='git commit -a -m "work in progress - fixup"'

Things I wish Git had: Commit groups → Un poco relaccionado con todo esto
-—

1. Commit en local al principio
   
2. Hacer commits que tengan wip para que los vea en zsh
   
3. Squash de todos ellos antes de subirlos
   
   1. Suele pasar que tienes cambios en local (el repo no está limpio) → hacer un gsp git rebase -i HEAD~N donde N son los commits que te indica zsh
      
4. A veces la lías con squash → reflog para hacer un reset a como estabas antes
   
5. Utilizar Git Worktrees para poder trabajar en varias ramas a la vez, o guardar marcas en distintos archivos en distintas ramas
   

• Fossil: Home
  
• Pijul
  

• Sacar todos los commits de un mismo autor
  https://stackoverflow.com/questions/12174276/github-list-commits-by-author
  https://github.com/search?o=desc&s=committer-date&type=Commits&q=author:torvalds
  
• Sacar los grupos a los que pertenece un usuario
  https://github.com/orgs/%7Borganization%7D/teams?query=@user
  
• Sacar todos los issues de un usuario
  https://github.com/search?o=desc&q=author:lytex&s=created&type=Issues
  

• https://radicle.xyz/
  
• https://giveupgithub.org/
  
  • Alternative Hosting Services:
    
    • CodeBerg
      
    • SourceHut
      
  • Self-Host (or join a group that self-hosts). A few options:
    
    • Gitea
      
    • GitLab Community Edition (note, the GitLab Enterprise Edition, which is provided to the public on gitlab.com, is (like GitHub) trade-secret, proprietary, vendor-lock-in software)
      
    • SourceHut
      

• hercules Estadísticas avanzadas de git (hay hacer alias labours“python3 -m labours”= porque por defecto pilla el python2, y luego también se les olvida el pipe:.
  Funciona con versiones antiguas de python (3.6, 3.7), si no te tienes que compilar tú tus paquetes con dependencias binarias
  
• hercules --burndown --burndown-people file://$PWD | labours -m overwrites-matrix
  
• https://github.com/augmentable-dev/askgit Queries sql contra git (renombrado https://github.com/mergestat/mergestat)
  
  • Funciona con docker:
    docker run --rm -v `pwd`:/repo:ro augmentable/askgit "SELECT path FROM files limit 10"
    
• AmrDeveloper/GQL: Git Query language is a SQL like language to perform queries on .git files with supports of most of SQL features such as grouping, ordering and aggregations functions
  
• acaudwell/Gource: software version control visualization
  
  • https://www.youtube.com/@gourceryt
    
  • dolthub/dolt - Grource visualisation
    
• forgit
  git + fzf
  
• Git History (GitHub, GitLab, BitBucket): Quickly browse the history of files in any git rep
  
• 20+ tools to help you mine and analyze GitHub and Git data
  
  • chaoss/augur: Python library and web service for Open Source Software Health and Sustainability metrics & data collection. You can find our documentation and new contributor information easily here: https://chaoss.github.io/augur/ and learn more about Augur at our website https://augurlabs.io
    
  • cregit/cregit
    
  • chaoss/grimoirelab: GrimoireLab: toolset for software development analytics