It uses main branch only.

When you enable GitHub Actions, GitHub installs a GitHub App on your repository.

• automatically add the appropriate labels whenever someone creates a new issue in your repository
• provides Linux, Windows, and macOS virtual machines to run your workflows, or you can host your own self-hosted runners in your own data center or cloud infrastructure

event

in repository

workflow

defined by a YAML file in .github/workflows/. Triggered by: event, manually, at schedule.

jobs

part of workflow, set of steps. run sequential or parallel(default) in one workflow. May depend on other job.

runner

Each job will run inside its own virtual machine or container.

steps

of job. run a script or run an action. executed in order.

default environment variables

that GitHub sets automatically

custom variables

user definde

activity type

specify which activity trigger event.

workflow is divided into jobs, and each job performs a set of steps

specifies what commands or scripts to run, the default settings, the environment for the commands, etc.

name (optional)

name of your workflow, if not specified GitHub sets it to the workflow file path.

run-name (optional)

name for workflow runs, if omitted then for a workflow triggered by a push or pull_request event, it is set as the commit message.

• ex. Deploy to $inputs.deplo{y}_{t}argetby@${{ github.actor }}

on

events if just list. ex. [push, fork]

jobs

check-bats-version

example job name

ubuntu-latest

ex. ubuntu-latest.

custom variable

• env key in workflow file.
  • env:\n\t DAY_OFWEEK: Monday
  • jobs: env:\n\t DAY_OFWEEK: Monday
  • jobs: steps: env:\n\t DAY_OFWEEK: Monday
• define it at the organization, repository, or environment level

on: {release: {types: [published]}}
on: {schedule: [cron:  '30 5,17 * * *']}
"on": [push]

Every event has "activity type" which describe it further.

events https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows

Repository -> settings -> Secrets and variables -> Actions

referencing secrets: ${{ secrets.GITHUB_TOKEN }}

• jobs.<job_id> - a unique string identifier.
• jobs.<job_id>.name - a name for the job, which is displayed in the GitHub UI.
• jobs.<job_id>.runs-on - type of machine to run the job on https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#choosing-self-hosted-runners
• jobs.<job_id>.needs - any jobs that must complete successfully before this job will run.
• jobs.<job_id>.steps - YAML sequence or list of tasks called steps

• steps[*].name - string id
• steps[*].uses - action ex. uses: actions/checkout@v4
• steps[*].Runs - command-line programs
• steps[*].working-directory

https://github.com/actions/

• setup-python https://github.com/actions/setup-python
• checkout https://github.com/actions/checkout
• stale https://github.com/actions/stale
• setup-java https://github.com/actions/setup-java
• setup-go https://github.com/actions/setup-go
• pypa/gh-action-pypi-publish https://github.com/pypa/gh-action-pypi-publish

https://docs.github.com/en/actions/learn-github-actions/variables

reffered as $GITHUB_WORKSPACE:

GITHUB_WORKSPACE

The default working directory on the runner for steps, and the default location of your repository when using the checkout action.

RUNNER_OS

Each job runs in a fresh instance of the virtual environment specified by runs-on.

• actions/upload-artifact and actions/download-artifact
• volumes - to share data between services or other steps in a job.
• outputs - maximum of 1 MB. The total of all outputs in a workflow run can be a maximum of 50 MB.

1. create new release
   • https://github.com/elgohr/Github-Release-Action
   • gh release create –title "$INPU{T}_{T}ITLE"--generate-notes"$(date +%Y%m%d%H%M%S)"
2. add asset to existent release
   • gh release upload ${{ github.ref_name }} ./dist/*{.exe,.exe.sha512.txt}

• main https://docs.github.com/en/actions
• https://codefresh.io/learn/github-actions/github-actions-tutorial-and-examples/
• file https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions
• env variables https://docs.github.com/en/actions/learn-github-actions/variables

README.md:

[Contribution guidelines for this project](docs/CONTRIBUTING.md)

or in your root directory

think of it as a anchor for your project, around which you will build community and keep things tidy. provides potential project contributors with a short guide to how they can help with your project or study group

• Project contributors - users of the file who want to know items they're welcome to tackle, and tact they need in navigating the project/respecting those involved with the project
• Project consumers - users who want to build off the project to create their own project

Contains commit hashes with big refactorings that you don't want to be shown in history of review.

notifications for pull requests, for feedback

path name of owner

Security Policy

how to report

• .gitignore - will be added to repository
• .git/info/exclude - without adding .gitignore to repo
• ~/.gitignore_global - global for all repositories

remove ignored files from current repository:

• git rm -r –cached .
• git add .
• git commit -am 'Drop files from .gitignore'

obsolate?

https://docs.github.com/en/search-github/github-code-search/understanding-github-code-search-syntax

.git/config [user] section:

• git config user.email ""
• git config user.name "(none)"

~/.gitconfig git config –global –list git config –list - repository config

git supported protocols:

• http: git clone http://domain.com/dir/repository.git
• https: git clone https://domain.com/dir/repository.git
• git: git clone git://domain.com/dir/repository.git
• git over ssh: git clone git+ssh://domain.com/dir/repository.git

set proxy:

git config --global http.proxy 'socks5://127.0.0.1:1081' # for http protocol  http://proxyuser:proxypwd@proxy.server.com:8080
git config --global ssh.gitproxy /path/to/bin/git-proxy.sh # for git protocol

/path/to/bin/git-proxy.sh where $1 and $2 is remote host and port:

nc -x 127.0.0.1:1081 $1 $2

git config –list # should look like this:

http.proxy=socks5://127.0.0.1:1081
core.gitproxy=/home/user/git-proxy.sh

core.gitproxy is not working, idk why.

Host github.com ServerAliveInterval 55 ForwardAgent yes CheckHostIP no ProxyCommand nc -xlocalhost:9050 -X5 %h %p

from remote repository instance to local one.

from local to remote

https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches Branch - are local for the repository. A branch is a named pointer to a commit.

Remote-tracking branches - there are remote branches. Looks like origin/master. not stored localy. but may be checkout.

• “Upstream Remote” - link to original repository, allowing you to fetch updates and track changes from the original repository.
• upstream branch - the branch which tracking branch tracks. Always Remote-tracking branches.

local branches - looks like master. they are stored in local repository.

To have an upstream branch(tracking branches) - –track This configuration will tell git to show the relationship between the two branches in git status and git branch -v. If you clone a Git repository, your local master branch is created as a tracking branch for the master branch of the origin repository (short:_origin/master_) by Git. Always local.

Default branch - named _master

Setting Upstream Tracking - bind branch to track remote branch added as “Upstream Remote”.

• when create new branch: git checkout -b my-local-branch origin/main
• after creation:
  • git branch –set-upstream-to <upstream> <local-branch>
  • git branch –set-upstream-to upstream/main main-origin

Tag - points to a commit.

Lightweight tag - without properties, annotated tag - with additional info

Release tags - common applying of tag.

Fetchurl, Pushurl - the location of the repository

Remote - remote repository pointer with properties e.g. URL, branches to fetch or branches to push.

Origin - default name for remote. after clone

Git-submodule - via a .gitmodules file located at the root of the parent repository. They’re too intrusive, requiring submodules to be initialised and updated. And switching between branches, which is where Git really shines, suddenly becomes painful because submodules don’t do what you expect.

git merge git rebase - like merge but add current branch commits at the top of rebase branch

git fetch - move local Remote-tracking branche to what at remote repository. it may add commits not existing in another local branches.

By default you can only push to bare repositories.

release tags are labeled based on the [major].[minor].[patch] naming scheme, for example "1.0.0". Several projects also use the "v" prefix. the minor version is incremented if new, backwards compatible functionality is introduced to the public API and the major version is incremented if any backwards incompatible changes are introduced to the public API.

To get submodules for project:

• git checkout –recurse-submodules
• git submodule update –depth 1 –init –checkout –recursive

act of picking a commit from a branch and applying it to another.

most of this can be made with git merge

upstream tracking branch: master ⇒ origin/master

by default both “git merge” and “git rebase” will use the upstream tracking branch

when you checkout a new branch and you are using a remote branch as the starting point, the upstream tracking branch will be setup automatically.

git symbolic-ref

• .git/HEAD, pointing at somewhere under refs/heads/ hierarchy;
• .git/refs/remotes/{some remote name}/HEAD, pointing at somewhere under refs/remotes/{the same remote name}/ hierarchy.

• Markdown rus https://doka.guide/tools/markdown/
• https://github.com/mattcone/markdown-guide/tree/master

https://view.genial.ly/633ae76d9e26ed001866821c/interactive-content-dst-30-bonus-mdnandgitunit8

• Vincent Driessen's branching model https://nvie.com/posts/a-successful-git-branching-model/

git checkout origin/another_branch

git checkout master git merge hotfix

git reset –hard

git commit –amend -m "asd"

git reset –hard a43e2d13 git push origin development –force

git tag 1.6.1 -m 'Release 1.6.1'

git push origin [tagname]

git push origin tag <tagname>

git push --tags

git push origin v0.1

git tag -d 1.7.0

git push origin :refs/tags/1.7.0

git show 1.6.1
git chechout <tag_name>
git tag -n

ref~ is shorthand for ref~1 and means the commit's first parent ref¹ ref² - two parents for merge commit

git diff-tree –name-only -r <commit_id> git diff HEAD^ HEAD

git blame -w -L 1,2 [filename]

git shortlog git shortlog -s - only users

git pull = git fetch + git merge git pull –rebase = git fetch + git rebase - clear changes

git checkout - reset file to latest commit or stagged state

git status - Displays paths that have any differences

git config –global –list git config –list - repository config

git clone git://github.com/vogella/gitbook.git git - default protocol 9148 port git clone http://github.com/vogella/gitbook.git clone via HTTP git clone ssh://git@github.com/vogella/gitbook.git git - name for ssh URL for remote: git@github.com/vogella/gitbook.git

git remote show origin - get a full list of Remote references are references (pointers) in your remote repositories, including branches, tags, and so on. git ls-remote origin - like above git remote -v

### Stagging area ### git add [path] -add to staging area git reset [path] -remove staging area git diff –cached -shows the differences between the staging area and the last commit git add -n . - on’t actually add the file(s), just show if they exist and/or will be ignored.

#clean git reset –hard - clean stagging area but do not touch untracked files git clean -fdx - remove untracked files -f force -d directories -x hidden files

#reset to origin git fetch origin git reset –hard origin/master git checkout master

git reset HEAD~1 - move HEAD and branch pointer - do nothing with untracked files Reset Branch pointer Working tree Staging area soft Yes No No mixed (default) Yes No Yes hard Yes Yes Yes

git reflog - show HEAD movements and found reseted commits

git show HEAD:./pom.xml -show file

Create patch:

echo "new content for test01" >test01

git add . git diff -p –stat > 0001-First-commit-in-the-branch.patch

git commit -m "first commit in the branch"

git format-patch origin/master

git format-patch -3 HEAD # for last 3 commits

git checkout master

git apply 0001-First-commit-in-the-branch.patch

git add . git commit -m "apply patch"

rm 0001-First-commit-in-the-branch.patch #short git am *.patch -order in which the patches are applied by specifying them on the command line.

#remove last commit git reset –hard HEAD~ git commit –amend git push -f origin master

#fix detached HEAD git checkout master

#Subtree https://help.github.com/articles/about-git-subtree-merges/ git remote add -f test-subtree git@github.com:Anoncheg1/test-subtree.git #–no-commit perform the merge but pretend the merge failed and do not autocommit

git merge -s ours –squash –no-commit –allow-unrelated-histories test-subtree/master git read-tree –prefix=test-subtree/ -u test-subtree/master

#pull changed subtree in parent git pull –allow-unrelated-histories –squash -s subtree test-subtree master

#push subtree from parent ???

git submodule add [URL to Git repo] git submodule init git submodule update –remote -remote if you need branches. updates the working tree to the commit described by the branch cd [submodule directory] git checkout master git pull

git clone –recursive

#push submodule from parent #cd submodule git status - check that we on master git checkout master - if detached HEAD mode commit submodule cd parent commit parent git submodule update

#commit main git submodule update git commit

• git diff myfile.txt # haven't git added yet
• git diff –cached myfile.txt # already added

remove commits to another branch

• git checkout -b new
• git checkout old
• git reset –hard commit
• git push origin –force

remove commits from remote branch

merge range of commits

• cherry-pick
  • git checkout old_ormaster
  • git checkout -b new_branch
  • git cherry-pick a..e # from development

update branch from master

1. chechout + merge + push
   • git checkout b1
   • git merge origin/master
   • git push origin b1
2. fetch + rebase
   • git fetch
   • git rebase origin/master

• git branch -a (all or -r remote)
• git log –graph –oneline
• fetch/push: git remote -v
• authors: git shortlog –summary –numbered –email –since "2 year ago" or git shortlog -sne
• git tag # get all tags and versons

git reset –hard git pull

• git checkout –orphan latest_branch
• git add -A
• git commit -am "commit message"
• git branch -D main
• git branch -m main
• git push -f origin main

git checkout –orphan latest_branch git add -A git commit -am "commit message" git branch -D master git branch -m master -rename current branch to master git push -f origin master git branch -u origin/master master - to track remote

git –work-tree="." pull –allow-unrelated-histories git merge git rebase

• git reset –hard commit
• git push origin HEAD –force ??????
• git push origin +HEAD:development

one of:

• git status -s
• git diff –name-only

git diff HEAD

git status -u - display untacked files

in files git grep WHAT

• -n add line number
• –count print only sum occurances
• –heading –break - more readable

in content of commits git log -S WHAT –oneline

git restore file

• git shortlog -sn –since "2 year ago"

• git checkout HEAD^
• git switch - and/or git checkout master

git remote add upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git

git remote add upstream https://github.com/<aUser>/<aRepo.git>
git fetch upstream
git checkout master
git merge upstream/master

git clone --single-branch --branch main https://github.com/username/repository.git
cd repository
git fetch --tags

git remote add upstream https://github.com/ORIGINAL-USERNAME/ORIGINAL-REPOSITORY.git
git fetch upstream --tags
git push origin --tags

git checkout main
git branch -c main main-origin
git push origin main-origin
git remote add upstream https://github.com/ORIGINAL-USERNAME/ORIGINAL-REPOSITORY.git
git fetch upstream (may be not needed)
git ls-remote --heads upstream
git branch -u upstream/main main-origin
git branch -vv

Approach: old to new “stash apply”.

git checkout -b old-branch 9578c2597e2d88b6f0b304b5a05864fd613ddcc1
# made changed to old-branch
git stash
git checkout -b merge-branch main
git stash apply
git merge old-branch
# resolve conficts

.patch file consist of:

• Header. If a line starts with a space, Git will treat it as a continuation of the previous line, rather than a new line. This is a common convention in email and other text formats, where a line starting with a space indicates that it's a continuation of the previous line.
• Diffs with one or more hunks.
• Trailer or Footer, may have Signed-off-by line.

--
2.45.2

Creation:

commit and "git format-patch -1 HEAD" OR "git diff --stat -p > patch.patch"

Applying patch:

git apply --stat a_file.patch
git apply --check a_file.patch # dry run
git apply a_file.patch

Header.

Steps:

1. Create a new dev branch
2. Do your work on local dev branch
3. Push dev branch from your local to central git repository

4. Once your work is done, pull changes from master

   • There is a race condition here, just as in CVS and Bazaar: if your mirror is not up-to-date

   because another developer has pushed since you last updated, your push will fail.

5. merge dev branch to the master
6. push changes
7. Finally, delete the dev branch from both local and central git repository

Commands:

1. git checkout -b my_branch
2. git commit -m " "
3. git push –set-upstream origin my_branch
4. git checkout development
5. git pull
6. git merge my_branch
7. git push
8. git branch -d dev
9. git branch -d -r origin/dev

If the push fails because someone pushed since your last git pull, rebase on the latest master and push again:

1. git pull –rebase
2. git push

https://www.emacswiki.org/emacs/GitForEmacsDevs

To do this, use the cherry-pick method:

1. First use the git log command to find the commit you are looking for.
2. Then switch to the release branch, update it, and do the cherry-pick:
3. git pull
4. git checkout release-25 # make sure you have the release branch checked-out
5. git cherry-pick -xe COMMIT
6. git show # Finally, review your back-port and push:
7. git push

• 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

• Merge. This is the default setting. git fetch + git merge for pull

  • When You're working on a team and need to preserve the commit history, including merge

  commits. with many merges and conflicts.

  • This creates a new merge commit that combines the histories of both branches.
  • If there are conflicts, you'll need to resolve them manually, then commit the merge.
  • steps:
    • git config pull.rebase false
    • git pull origin main
• git fetch + git rebase. This means that your local changes will be replayed on top of the remote changes, creating a linear history with no merge commits. But requires a force push to update the remote branch.
  • Rewrites the commit history, which can cause problems if you've already shared your changes with others.
  • May lose the context of merge commits, which can make it harder to understand the commit history.
  • steps:
    • git config pull.rebase true
    • git pull –rebase origin main
    • git push origin main –force
• 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.
  • However, this will result in an error if a fast-forward is not possible, as indicated by the message fatal: Not possible to fast-forward, aborting
  • steps: git config pull.ff only

you can always set this configuration per-branch or per-repository, depending on your specific needs.

Git think it's unrelated histories.

---a---b---main
        \      \
          x x x x   diverged, cannot be merged anymore
          \      \
    ---?---?---?---c(origin/main)

And finally, the simple resolution is: git reset –hard origin/main, if you don't care the local changes, otherwise you will lost all your work.

Or try

git pull --depth=2.

"error: src refspec refs/heads/master does not match any" or "from the remote, but no such ref was fetched"

If your repository was cloned with the –shallow option, it only includes a limited number of commits, which can cause issues when pushing to a new remote. Solution:

git fetch --unshallow

View Switching

• m Switch to main view.
• d Switch to diff view.
• l Switch to log view.
• p Switch to pager view.
• t Switch to (directory) tree view.
• f Switch to (file) blob view.
• g Switch to grep view.
• b Switch to blame view.
• r Switch to refs view.
• y Switch to stash view.
• h Switch to help view
• s Switch to status view
• c Switch to stage view

Low

• Requests per minute 15
• Requests per day 150

High

• Requests per minute 10
• Requests per day 50

Tokens per request: 8000 in, 4000 out

export GITHUB_TOKEN="<your-github-token-goes-here>"

import ModelClient from "@azure-rest/ai-inference"; import { AzureKeyCredential } from "@azure/core-auth";

const token= process.env["GITHUB_TOKEN"]; const endpoint = "https://models.inference.ai.azure.com"; const modelName = "Meta-Llama-3-70B-Instruct";

export async function main() {

const client = new ModelClient( endpoint, new AzureKeyCredential(token), );

const response = await client.path("/chat/completions").post({ body: { messages: [ { role: "system", content: "You are a helpful assistant." }, { role: "user", content: "What is the capital of France?" }, { role: "assistant", content: "The capital of France is Paris." }, { role: "user", content: "What about Spain?" }, ], model: modelName, }

• 2,000 intelligent code completions a month. Get context-aware code suggestions that draw context from your GitHub projects and VS Code workspace.
• 50 Copilot Chat messages a month. Ask Copilot for help understanding code, refactoring something, or debugging an issue.
• Choose your AI model. Pick between Claude 3.5 Sonnet or OpenAI GPT-4o.
• Make changes to multiple files with Copilot Edits. Tackle changes across multiple files with Copilot Edits.
• Support for the Copilot Extensions ecosystem. Access third-party agents designed for tasks such as querying Stack Overflow or searching the web with Perplexity.
• Choose where you build. Enjoy support in VS Code and across GitHub.

• “Use AI Features with Copilot for Free…” - unified GitHub Copilot extension (installed by default)
• Sign in to Copilot

https://code.visualstudio.com/docs/copilot/setup

GitHub Copilot: This is the official GitHub Copilot extension for VSCode

• https://plugins.jetbrains.com/plugin/17718-github-copilot

Copilot Extension: This extension provides additional features and settings for GitHub Copilot, such as customizable keyboard shortcuts, code snippet management, and more.

third-party extensions that integrate with GitHub Copilot include:

• TabNine: This extension provides AI-powered code completion and code suggestions, and can be used in conjunction with GitHub Copilot.
• Kite: This extension offers AI-powered code completion, code suggestions, and code review, and can be used with GitHub Copilot.
• Codeium: This extension provides AI-powered code completion, code suggestions, and code review, and can be used with GitHub Copilot.

• https://github.com/features/copilot/extensions#resources
• https://github.com/copilot-extensions/skillset-example

approaches:

• skillsets approach
• traditional agent

SSH version:

#!/usr/bin/env bash

PROJECT="${1}" # your-company/or-repo/whatever
FILEPATH="${2}" # foo/bar.tar.gz
REF="${3:-master}" # branch
SSHID="${4:-$HOME/.ssh/ecdsa_id}" # like $HOME/.ssh/mycompany

OID="$(set -o pipefail; curl -fSL -H "PRIVATE-TOKEN: ${GITLAB_TOKEN}" "https://gitlab.com/api/v4/projects/${PROJECT//\//%2F}/repository/files/${FILEPATH//\//%2F}/raw?ref=${REF}" -o - | grep '^oid' | cut -d: -f2)"
AUTH="$(set -o pipefail; ssh -o IdentitiesOnly=yes -o IdentityFile="${SSHID}" git@gitlab.com git-lfs-authenticate "${PROJECT}.git" download | jq -er '.header.Authorization')"
mkdir -p "${FILEPATH%%/*}"
curl -H "Authorization: $AUTH" "https://gitlab.com/${PROJECT}.git/gitlab-lfs/objects/${OID}" -o "${FILEPATH}"
file "${FILEPATH}"

HTTP version:

#!/usr/bin/env bash

PROJECT="${1}" # your-company/or-repo/whatever
FILEPATH="${2}" # foo/bar.tar.gz
BRANCH="${3:-master}" # branch

# get LFS file info
IFS=$'\n' LFS_OBJECT_INFO=($(curl -fsSL -H "PRIVATE-TOKEN: ${GITLAB_TOKEN}" "https://gitlab.com/api/v4/projects/${PROJECT//\//%2F}/repository/files/${FILEPATH//\//%2F}/raw?ref=${BRANCH}" -o -))
OID="$(echo "${LFS_OBJECT_INFO[@]}" | grep -oP "oid sha256:\K[^\s]+")"
SIZE="$(echo "${LFS_OBJECT_INFO[@]}" | grep -oP "size \K[^\s]+")"
# request actions for given lfs objects
LFS_OBJECT_REQUEST_JSON="$(jq -rnc --arg oid $OID --arg size $SIZE --arg ref "refs/heads/$BRANCH" '{"operation":"download","objects":[{"oid":$oid,"size":$size}],"transfers":["lfs-standalone-file","basic"],"ref":{"name": $ref }}')"
LFS_OBJECT_ACTION_DOWNLOAD="$(set -o pipefail; curl -sSlf -H "Content-Type: application/json" -X POST -d "$JSON" "https://oauth2:${GITLAB_TOKEN}@gitlab.com/${PROJECT}.git/info/lfs/objects/batch" | jq -er '.objects[0].actions.download')"
AUTH="$(echo "$LFS_OBJECT_ACTION_DOWNLOAD" | jq -er '.header.Authorization')"
DOWNLOAD_URL="$(echo "$LFS_OBJECT_ACTION_DOWNLOAD" | jq -er '.href')"
mkdir -p "${FILEPATH%%/*}"
curl -H "Authorization: ${AUTH}" "${DOWNLOAD_URL}" -o "${FILEPATH}"

• git-annex
• git-bigfiles
• git-fat
• git-media
• git-bigstore
• git-sym