it defaults to using seven characters:

git log --oneline or --abbrev-commit

At its core, the Git version control system is a content addressable filesystem. It uses the SHA-1 hash function to name content.

• these simple names are called “references” or “refs”; (.git/refs directory.)

CLA (Contributor License Agreement)

Copyright transfer/assignment agreement - an agreement that transfers the copyright for a work from the copyright owner to another party. ex: a video game developer who wants to pay an artist(painter) to draw a boss to include in a game

DCO (Developer Certificate of Origin) - way for contributors to certify that they wrote or otherwise have the right to submit the code they are contributing to the project.

• aggree to "the contributor is allowed to make the contribution and that the project has the right to distribute it under its license"
• introduced in 2004[1] by the Linux Foundation
• Sign-off is a requirement for getting patches into the Linux kernel and a few other projects, but most projects don't actually use it.
• Sign-off is a line at the end of the commit message which certifies who is the author of the commit. Its main purpose is to improve tracking of who did what, especially with patches.
  • Signed-off-by: Humpty Dumpty <humpty.dumpty@example.com>

-s::–signoff:: - add line to commit message to signal that you created this commit, have permission to submit it, and you adhere to the project licensing.

-S –gpg-sign - adds a gpg signature to the commit which requires one to have gpg installed and a private key. GitHub will mark commits that you sign with the verified label. If you sign your tags, they will also be marked as verified.

file

• filename:my_filename.txt or "path:**/your-file-name" or "path:your-file-name"

stars

• cats stars:>1000 matches repositories with the word "cats" that have more than 1000 stars.

filesize

• cats size:<10000 matches code with the word "cats" in files that are smaller than 10 KB.

dates

• cats created:>2016-04-29 matches issues with the word "cats" that were created after April 29, 2016.

label

• build label:"bug fix"

issues

• is:issue assignee:@me matches issues assigned to the person viewing the results

exclude:

• -org:github - not in repositories in the GitHub organization.
• -language:javascript
• hello NOT world matches repositories that have the word "hello" but not the word "world."

• git config –global user.email "<larry@gentoo.org>"
• git config –global user.name "Larry the cow"
• git config –global core.editor emacs
• git init
• git add .
• git commit

man gitrevisions

• <rev> - revision - commit or blobs ("files") or trees ("directories of files") whis is conteined in commit.
  • <sha1> - extended SHA-1 syntax
• <describeOutput> Output from git describe; i.e. a closest tag, optionally followed by a dash and a number of commits,
• <refname>, e.g. master, heads/master, refs/heads/master
• [<refname>]@{<date>}
• <refname>@{<n>}, e.g. master@{1}
  • n-th prior value of that ref.
• @{<n>}, e.g. @{1}
• <rev>^[<n>], e.g. HEAD^, v1.5.1^0 - n-th parent
  • A suffix ^ to a revision parameter means the first parent up to tree of that commit object. <rev>^ is equivalent to <rev>^1
  • A^<n> - mean <n> parent where a commit has more than one parent
  • A^0 = A
• <rev>~[<n>], e.g. HEAD~, master~3
  • A~2 - seond parent up to branch = A^^
• r1 .. r2 - revision range
  • r1..r3 = r2 r3 = r3 ^r1
  • r1^..r3 = r1 r2 r3
• r1 … r2 - all parents of both

http://www.vogella.com/tutorials/Git/article.html https://www.tutorialspoint.com/git/git_basic_concepts.htm

Version Control System (VCS) [ˈvɜːʃən] is a software that helps software developers to work together and maintain a complete history of their work.

Git - distributed version control system.

Repository - software storage local or remote. contains the history and branches.

• Bare repository - git init –bare For sharing in collaborating. repository without working tree. Not allow tocreate new versions. (commit i guess)
• Local Repository - .git folder at local machine

Working tree - folder for the repository (tracked and untracked). staging area (Index) - git add list of files with sha1 of content - tracked files. Stagging or cached - changes that will be included in next commit. (after git add)

Checkout - Updates files(remove changes) in the working tree to match the version in the index or the specified branch.

Commit 1)commit the staged changes into Git repository 2)commit object - uniquely identifies(SHA-1 hash) a revision(state) of the repository(content). Has pointer to parent commit.

If commit has miltiple parent commits - was created by merging.

• First parent commit is the branch you were on when you merged A^, A^2 - second parent

Version graph formed by all commits in the repository

HEAD - symbolic reference. If you switch branches, the HEAD pointer points to the branch pointer which in turn points to a commit. If you checkout a specific commit, the HEAD points to this commit directly.

.gitignore the root directory of your project, the ignore settings will be applied to all sub-directories automatically.

Detached HEAD mode - If you checkout a commit or a tag

ref - symbolic references (symrefs)

Upstream branch - branch tracked on remote repository by your local remote "tracking" branches.

• Local remote "tracking" branches - local branches that has remote associatied in .git/config
• remote tracking branches - branches on remote version of local repository
• "remotes" - remote repository, configured in git remote. ex. origin

• git init/clone
• git stash - save working directory state and allow list saves
• git rm [file] - remove files from the index and maybe(–cached) working tree
• git mv - move file, directory symlink, index updated, but changes must be commited
• git add - update the Index = add files and update check-sum.
• git clean - Remove untracked files from the working tree
• git log
• git reflog - local actions history - git reset HEAD@{index}
• git show
• git diff
  • git diff HEAD - between Staging Area and HEAD commit (git diff "s" HEAD - "s"=a, HEAD=b)
  • git diff –staged/cached HEAD - between Stagging and HEAD
• git branch
• git switch - switch branches
• git checkout -switch
• git commit
  • –amend - replace last commit of current branch
• git merge - combines branches
  • git merge –abort
• git revert - revert one commit and record new one
• git reset - sets HEAD to comment (and reset index and/or working tree)
  • –mixed - reset index but not working tree
  • –soft - do not touch index and working tree
  • –hard - index and working, changes are lost
  • –merge - reset index and update files in working if they different in past commit
  • –keep - reset index and update files in working if they dont have local changes
• git reset file - reset file to HEAD
• git remote - manage remote repositories
• git fetch - harmless download changes
• git pull - download changes and change working tree

switch

• git switch branch name

create

• git branch name # create a branch from the current branch, do not switch to it
• git branch <name> <hash> - <hash> is optional to which the branch pointer original points
• git checkout [[-b|-B|–orphan] <new_branch>] [<start_point>] # git branch -f <branch> [<start-point>] ; git checkout <branch>
  • git checkout -b name # new branch and start at the start poing
  • -B <new-branch> # <new-branch> is created if it doesn’t exist otherwise, it is reset
• git switch -c new-branch # git branch <new-branch> ; git switch <new-branch>
• git switch -c dev –track master # If the starting point is a local branch, you can force the tracking

delete

• git branch -d testing - delete local branch
• git branch -d -r origin/dev origin/stage origin/prod # delete remote-tracking branches.
• git push [remote] –delete [branch] - delete branch in a remote repository

list

• get branch -r # remote branches (red)
• git branch # show local branches (green with * is current)
• git branch -a - lists all branches including the remote branches
• git branch -r - lists branches in the remote repositories
• git branch -v - info of tracking branches
• git remote show origin - show all remote and tracking branches for origin
• git branch -vv - to see local tracking branches.
• git branch –merged/–no-merged [commit] # Only list branches whose tips are reachable

other

• git branch -D name # delete a local copy of a branch.
• git checkout -b develop -
• –orphan - no parents, totally disconnected. no commits before first
• # tracking branches
• git checkout -b newbranch origin/newbranch - setup a tracking branch called newbrach which tracks origin/newbranch
• git branch [new_branch] origin/master
• git checkout –track origin/serverfix - create local serverfix branch tracking remote one if remote exist.
  • git checkout serverfix - the same
• git branch –unset-upstream # Remove a current tracking relationship
• git push -u origin feature # Link a branch to an upstream branch
• git branch –set-upstream-to # set remote tracking branch

• git remote - show "remotes" whose branches you track
• git branch -r - remote tracking branches (branches on remote version of local repository)
  • * - currently viewing
  • origin/HEAD -> origin/master - default branch and current commit of origin. may be changed with: git remote set-head origin <remote> <branch>
  • origin/master - remote branch
• cat .git/config
  • remote = origin - remote associated with branch (upstream configuration)
  • merge = refs/heads/master - branch and HEAD on remote

• git config credential.helper store
• after next push credentials will be saved

git log

• –oneline -
• –graph
• –decorate[=short|full|auto|no] lenght of ref name - default short

git log HEAD~4..HEAD git log HEAD~4 - the same git log testing..master - list all commints in master but not in testing git log master…testing - commits reached by master or testing but not both

git log HEAD – git log -1 – HEAD - one last commit for HEAD file git log HEAD^ - one parent commit for HEAD

fast-forward is merge operation when Git moves the current branch HEAD pointer to the target local branch HEAD pointer, without having extra commits.

merge branch

• git checkout master
• git merge development

if CONFLICT

1. undo
   • git merge –abort
   • git merge –continue
2. resolve
   • open conflicted file to see
   • remove <<<<<, == amd >>> lines to resolve conflict
   • git add ./path/file ( if new)
   • git commt -m "Merge development fixed conflict"

GitHub Flavored Markdown with a few unique writing features (один из диалектов Markdown)

• file.md

repo -> Settings ->pages

Preview:

• https://htmlpreview.github.io/?https://github.com/Anoncheg1/awesome-chinese/blob/main/index.html

HTML:

• touch .nojekyll
• /_site/index.html
  • Settings -> pages https://anoncheg1.github.io/awesome-chinese/

pages

• GitHub Pages supports two Markdown processors: kramdown and GitHub's own Markdown processor, which is used to render GitHub Flavored Markdown (GFM)

/etc/conf.d/git-daemon

• GIT_USER="t"
• GIT_GROUP="t"
• GITDAEMON_OPTS="–syslog –export-all –enable=receive-pack –base-path=/home/t/share"
  • If desired to accept git push and allow access all direct, it needs two options –enable=receive-pack and –export-all in GITDAEMON_OPTS

or use sshfs to directly access folder

• Central Workflow - one master branch
• Forking Workflow - 1) original or main branch 2) fork branch owned by another contributor which going to suggest merges to main
• Developer Branch Workflow - one main and every developer has one or more own branches. finally forks will be merged to main.
• Github Flow - (good for agile teams) - extension to provide high-level repository operations for Vincent Driessen's branching model
  • main branch - code works and ready to deploy at any time
  • all brancches (features) - checked by leader of the team + one more specialist then merged to main
• Feature Branch Workflow -
  • main - stable
  • dev -
  • features branches - created from dev. finally merged to dev
• Git Flow - big projects
  • main branch or production - stable
  • develop - may be not stable
  • release1-9 branches - stabilization work take place here and merged to develop and master
  • hotfix1-9 branches - for fast solving of critical problem of production branch. merged to develop and master.
• Issue Branch Workflow - like a "Feature Branch Workflow" but with for issues

consist of

• action
• subject
• comments

vocabulary:

• init — инициализация;
• add — добавление;
• delete — удаление;
• update — изменение;
• fix — исправление;
• refactor — рефакторинг кода приложения;
• style — исправление опечаток, форматирования;
• docs — всё, что касается документации;
• test — всё, что связано с тестированием;
• merged, fix conflict — слияние, решение конфликта.

• Just drag and drop your image from your local pc to github readme in editable mode.
• You can create a .github/images directory in your repo and add all your assets there. Assets added here will be available on

https://raw.githubusercontent.com/{github_user_name}/{repo_name}/{branch}/.github/images/{asset_name}.{asset_extension}

Link in README.md:

![Alt Text](/assets/{asset_name}.{asset_extension})

merge two last commits together:

git rebase --interactive HEAD~2

or

git merge --squash bigix # Takes all commits from the bugfix branch and groups it for a 1 commit with your current branch.

merge in history:

: git rebase -i <commit_hash> # after which others will be squashed
select commits that will be squashed

; git push –force-with-lease

when the Internet connection lost: "Looks like something went wrong!"

You have divergent branches and need to specify how to reconcile them.

• There is a merge conflict, you should one of:
  • git merge or git pull –no-ff # create merge
  • git rebase or git pull –rebase # temporarily removes commits from our local branch and do fast-forward
• This is the default setting. It means that git pull will use a merge strategy to combine the changes. This creates a new merge commit that combines the changes from the remote branch with your local branch.
• This configuration tells git pull to use a rebase strategy instead of a merge. This means that your local changes will be replayed on top of the remote changes, creating a linear history with no merge commits.
• This configuration tells git pull to only perform fast-forward merges, which means that the local branch will be updated only if it can be fast-forwarded to the remote branch. If there are any divergent changes, git pull will fail and you will need to resolve the conflicts manually.

https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/adding-a-workflow-status-badge

![example workflow](https://github.com/github/docs/actions/workflows/main.yml/badge.svg)

select branch:

![example branch parameter](https://github.com/github/docs/actions/workflows/main.yml/badge.svg?branch=feature-1)

event:

![example event parameter](https://github.com/github/docs/actions/workflows/main.yml/badge.svg?event=push)
![example event parameter](https://github.com/github/docs/actions/workflows/main.yml/badge.svg?event=release)

• python/miss-islington
• python/bedevere
• python/the-knights-who-say-ni

tig log [options] [revisions] [–] [paths]

.

tig show [options] [revisions] [–] [paths]

Open diff view using the given git-show(1) options.

tig reflog [options] [revisions]

.

tig blame [options] [rev] [–] path

given file annotated by commits

tig grep [options] [pattern]

.

tig refs [options]

.

tig stash [options]

tig status

.

tig <

.

tig +N

show +2 = +1 commit from HEAD