Developer Blog

Tipps und Tricks für Entwickler und IT-Interessierte

Git | Arbeiten mit der GitHub Kommandozeile

Installation

Laden Sie das Tool von dieser Seite und installieren Sie es. Das Tool besteht aus einer Datei: gh

Stellen Sich sicher, dass sich der Installationsordner in ihrem PATH Variable befindet.

Danach einfach das Tool mal aufrufen

Authentifizierung

Anmelden

gh auth login --hostname github.com

Default Protokoll einstellen

 gh config set -h github.com git_protocol ssh

Credentials aktualisieren

gh auth status

Aktualisieren der Credentials:

gh auth refresh

Konfiguration

Editor setzen

gh config set editor editorName

Repositories

Erstellen

gh repo create <user>/<reponame>
gh repo create <user>/<reponame> --private --enable-issues=false

Clonen

gh repo clone <user>/<reponame>

Fork

gh repo clone <user>/<reponame>
gh repo clone <user>/<reponame> --clone=true --remote=true

Löschen

gh alias set delete 'api -X DELETE repos/$1'
gh auth refresh -h github.com -s delete_repo
# usage (WARNING: no confirmation!)
gh delete user/myrepo

Informationen

Liste der Repositorynamen

gh repo list --limit 1000 --json name --jq '.[].name'

List der Repository-URLs

gh repo list microsoft --json url --jq '.[].url'

Liste filtern (in PowerShell)

gh repo list microsoft --limit 3000 --json url --jq '.[].url'  |
Select-String PowerBI -NoEmphasis                              |




Suchen nach Repositorynamen

gh repo list --limit 1000 --json name --jq '.[].name | match(".*Angular.*") | .string'

Issues

gh issue list

Alle “issues” mit dem Status “all”

gh issue list --state "all"
gh issue list -s "all"
gh issue list --assignee "n8ebel"
gh issue list -a "n8ebel"

Check Issue Status

gh issue status
gh issue list --state "closed"
gh issue list -s "closed"
gh issue list --label "bug"gh issue list -l "bug"
gh issue list
gh issue list -l "enhancement"

Issues anzeigen

gh issue view "15"
gh issue list -a "n8bel" -l "bug"

Issues erstellen

gh issue create -t "Sample Issue Title" -b "Sample issue description"
gh issue create --web

Hilfreiche CLI Aliases

gh issue list --label "bug"
alias listbugs='gh issue list --label "bug"'
alias listmybugs='gh issue list -a "<username>" -l "bug"'

Pull Requests verwalten

List Pull Requests

gh pr list
gh pr list --state "all"
gh pr list  -s     "all"
gh pr list --assignee "n8ebel"
gh pr list  -a        "n8ebel"

Check Pull Request Status

gh pr list --state "closed"
gh pr list -s "closed"
gh pr list --label "bug"
gh pr list -l "bug"
gh pr list
gh pr list -l "enhancement"

Pull Request anzeigen

gh pr view "14"
gh pr list -a "n8bel" -l "bug"

Pull Request erstellen

gh pr create
gh pr create -t "Sample Issue Title" -b "Sample issue description"
gh pr create --web

Praktische Beispiele

Alle Repositories clonen, deren Namen einem bestimmte Suchmuster entspricht

gh repo list microsoft --limit 3000 --json url --jq '.[].url' |
Select-String PowerBI -NoEmphasis |




Repisitories

github

Git | Secure your sensitive data

References

https://github.com/AGWA/git-crypt

https://blog.francium.tech/secure-your-credentials-using-git-crypt-1ccbacc483c7

https://buddy.works/guides/git-crypt

TL;DR

COMMON COMMANDS

git-crypt init
git-crypt status
git-crypt lock

GPG COMMANDS

git-crypt add-gpg-user GPG_USER_ID
git-crypt unlock

SYMMETRIC KEY COMMANDS

git-crypt export-key OUTPUT_KEY_FILE
git-crypt unlock KEY_FILE

Installation

$ brew install git-crypt

Prepare Repository

$ cd <repository>
$ git crypt init
Generating key…

Create .gitattributes file

secretfile filter=git-crypt diff=git-crypt
*.key filter=git-crypt diff=git-crypt
secretdir/** filter=git-crypt diff=git-crypt
.gitattributes !filter !diff # prevent file from encrypted
github

Git | Using multiple accounts with Github

Create a New SSH Key

We need to generate a unique SSH key for our second GitHub account.

$ ssh-keygen -t rsa -C <your email address>

Be careful: do not over-write your existing key for your personal account. Instead, when prompted, save the file as id_rsa_<account name>.

I saved the file to ~/.ssh/id_rsa_placeholder

Attach the new Key to your Github Account

Next, login to your second GitHub account, browse to “Account Overview,” and attach the new key, within the “SSH Public Keys” section.

Copy and paste the content of the generated ssh file (with extention .pub):

~/.ssh/id_rsa_placeholder.pub

Note: Be sure to give this key a descriptive title, so that you can remember the source of the key.

Configure you shell environment

Start the ssh-agent, so that we can remember ssh-keys.

$ eval $(ssh-agent)
Agent pid 5099

Note: If you want to automatically start the agent on login, please look at the profile script at the end of this article

Now, add the key to the ssh-agent

$ ssh-add $HOME/.ssh/id_rsa_placeholder
Identity added: /home/ralphg/.ssh/id_rsa_placeholder (/home/placeholder/.ssh/id_rsa_placeholder)

Verify, that the key is loaded

$ ssh-add -l
2048 SHA256:ZOvzhxxxMVxxxOsMxxxm2YxxxHpV4/eAiFWyKJVRl/xxxxx /home/placeholder/.ssh/id_rsa_placeholder (RSA)

Now, configure your github repository

$ git remote -v 
origin https://github.com/placeholder/Awesome-Github.git (fetch)
origin https://github.com/placeholder/Awesome-Github.git (push)

Configure repository to use this ssh-key

$ git remote remove origin
$ git remote add origin git@github.com:placeholder/Awesome-Github.git
$ git remote -v
origin  git@github.com:placeholder/Awesome-Github.git (fetch)
origin  git@github.com:placeholder/Awesome-Github.git (push)
$ git push
fatal: The current branch master has no upstream branch.
To push the current branch and set the remote as upstream, use
$ git push --set-upstream origin master
The authenticity of host 'github.com (140.82.118.4)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'github.com,140.82.118.4' (RSA) to the list of known hosts.
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 10
Writing objects: 10
Total 5 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 10
To github.com:placeholder/Awesome-Github.git<
    1679693..3bbeede  master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.<

Configure your repository to use the created ssh-key

$ git config core.sshCommand "ssh -i ~/.ssh/id_rsa_placeholder"

Appendix

Shell profile script for autostart ssh-agent

SSH_ENV="$HOME/.ssh/environment"

function start_agent {
    echo "Initialising new SSH agent..."
    /usr/bin/ssh-agent | sed 's/^echo/#echo/' > "${SSH_ENV}"
    echo succeeded
    chmod 600 "${SSH_ENV}"
    . "${SSH_ENV}" > /dev/null
    /usr/bin/ssh-add;
}

# Source SSH settings, if applicable

if [ -f "${SSH_ENV}" ]; then
    . "${SSH_ENV}" > /dev/null
    #ps ${SSH_AGENT_PID} doesn't work under cywgin
    ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent$ > /dev/null || {
        start_agent;
    }
else
    start_agent;
fi

Script: create_ssh_keys

#!/bin/bash

GITHUB_ACCOUNT="$1"
echo ssh-keygen -t rsa -C "${GITHUB_ACCOUNT}@via-internet.de" -f id_rsa_${GITHUB_ACCOUNT}

Script: update_ssh_keys_to_HOME

#!/bin/bash
FLDR_DST=$HOME/.ssh

for _FILE in id*
do
    echo "copy $_FILE"
    FILE_DST="${FLDR_DST}/$(basename $_FILE)"

    chmod 600       $FILE_DST
    cp  $_FILE      $FLDR_DST
    chmod 400       $FILE_DST
done

Git | Cookbook

Github hints

Repository — Quick setup

Clone repository

.. or create a new repository on the command line

echo "# Init " >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin <url>
git push -u origin master

…or push an existing repository from the command line

git remote add origin git@github.com:<username>/<repository>.git
git push -u origin master

Merge branch with master

Merging via command line

Step 1: From your project repository, bring in the changes and test.

git fetch origin
git checkout -b develop origin/develop
git merge master

Step 2: Merge the changes and update on GitHub.

git checkout master
git merge --no-ff develop
git push origin master

Useful commands

To show information about a remote, for example if tracked branches are up-to-date:

git remote show origin
git remote -v
git remote add <shortname> <url>
git fetch <remote>
git push <remote> <branch>
git remote show <remote>
git remote rename <old> <new>
git remote remove <name>

To show log messages of the changes between branches:

git log origin/master ^master

Show log graph

git log --pretty=format:



To show differences between branches:

$ git diff master origin/master

Show , what git pull will doing

$ git fetch && git diff HEAD..@{u}

Or add the command to ~/.gitconfig file:

[alias]
        diffpull=!git fetch && git diff HEAD..@{u}

Run this to see how git diff resolution works

git rev-parse origin

Delete remote branch

git clone <repository> master
cd master
git push origin --delete feature-2.01.03

Show log

git log --oneline --graph --all --decorate

Undo commit

git commit --amend

Unstaging a staged file

git reset HEAD <filename>

Unmodifying a Modified File

$ git checkout -- <filename>

Retrieve last modification date

git ls-files -z | xargs -0 -n1 -I{} -- git log -1 --format=



Git Configuration

Show location of configuration files

git config --list --show-origin

This dows not work, if you have set the environment var GIT_CONFIG. In this case, do

unset GIT_CONFIG
git config --global --list

Edit config files

git config --edit --global
git config --edit --system
DESCRIPTIONGIT COMMAND
Configure the author name to be used with your commits.git config --global user.name "XXX"
Configure the author email address to be used with your commitsgit config --global user.email xxx@example.com
Will remove user credential details from the repositorygit config --local credential.helper ""
git config —show-origin
List all currently configured remote repository URLsgit remote -v
If you haven’t connected your local repository to a remote server, To add a remote server to a local repositorygit remote add origin <repo_url>

Git Commit and Push

DESCRIPTIONGIT COMMAND
Create a file name README.md with Readme content contentecho "Readme content" >> README.md
List the files you’ve changed and those you still need to add or commitgit status
Add all or one file to staginggit add . OR git add file_name
Commit changes to head with messagegit commit -m 'message'
Commit any files you’ve added with git add, and also commit any files you’ve changed since thengit commit -a
Send all commits from local repository to remote repositorygit push
Do a git push and sets the default remote branch for the current local branch. So any future git pull command will attempt to bring in commits from the <remote-branch>into the current local branchgit push -u <remote-branch>
Send changes to the master branch of your remote repositorygit push origin master
Push a specific branch to your remote repositorygit push origin <branch_name>
Push all branches to your remote repositorygit push --all origin

Working with the Git Workflow

The following steps are based on a branching model, described here.

Name Beschreibung
master
hotfixes
release
develop
feature

Working with branches

Create branch ‘develop’

$ git clone git@github.com:<USER>/<REPO>.git develop
$ cd develop
$ git checkout -b develop
$ git push --set-upstream origin develop

Create branch ‘feature-xxx’

We dont’t want do clone the whole repository, but only the files needed for the feature

$ git clone -b develop -n --depth 1 git@github.com:<USER>/<REPO>.git feature-2.2.0
$ cd feature-2.2.0

Branch löschen

$ git push origin -delete hotfix-1.2.1-compress-data

Workflow – Cheatsheet

Working with branches

How to rename git local and remote branches

Check out branch with old name

git checkout feature-2.1.2

Rename branch

git branch -m feature-2.01.02

Checkin branch with new name

git push origin :feature-2.1.2 feature-2.01.02

1. Rename your local branch.

If you have named a branch incorrectly AND pushed this to the remote repository follow these steps before any other developers get a chance to jump on you and give you shit for not correctly following naming conventions.

If you are on the branch you want to rename:

git branch -m new-name

If you are on a different branch:

git branch -m old-name new-name

2. Delete the old-name remote branch and push the new-name local branch.

git push origin :old-name new-name

3. Reset the upstream branch for the new-name local branch.Switch to the branch and then:

git push origin -u new-name

Or you as a fast way to do that, you can use these 3 steps: command in your terminal

git branch -m old_branch new_branch         # Rename branch locally    
git push origin :old_branch                 # Delete old branch    
git push --set-upstream origin new_branch   # Push new branch, set local branch to track new remote
Neues Feature erstellen
Repository clonen$ git checkout -b feature-1.2.2 develop
Änderungen durchführen
Änderungen einchecken$ git checkout develop $ git merge –no-ff feature-1.2.2 $ git branch -d feature-1.2.2 $ git push origin develop
Neuen Hotfix erstelllen
Repository auschecken$ git checkout -b hotfix-1.2.1 master
Änderungen durchführen
Änderungen einchecken$ git commit -a -m “hotfix: hotfix-1.2.1| compress mart”
Hotfix beenden$ git checkout master $ git merge –no-ff hotfix-1.2.1 $ git tag -a 1.2.1
Hotfix in Master einchecken$ git checkout develop $ git merge –no-ff hotfix-1.2.1  
Hotfix Branch entfernen$ git branch -d hotfix-1.2.1
Neues Release erstellen:
Repository clonen$ git checkout -b release-1.2 develop
Änderungen durchführen
Änderungen einchecken$ git commit -a -m “release: changes for release 1.2”
Release beenden$ git checkout master $ git merge –no-ff release-1.2 $ git tag -a 1.2

Git Flow

Initialize

Start using git-flow by initializing it inside an existing git repository:

$ git flow init

Start a new feature

Development of new features starting from the ‘develop’ branch.

git flow feature start MYFEATURE

Finish up a feature

Finish the development of a feature. This action performs the following

git flow feature finish MYFEATURE

Publish a feature

Publish a feature to the remote server so it can be used by other users.

git flow feature publish MYFEATURE

Getting a published feature

Get a feature published by another user.

git flow feature pull origin MYFEATURE

You can track a feature on origin by using

git flow feature track MYFEATURE

Start a release

git flow release start RELEASE [BASE]

It’s wise to publish the release branch after creating it to allow release commits by other developers. Do it similar to feature publishing with the command:

git flow release publish RELEASE

(You can track a remote release with the  git flow release track RELEASEcommand)

Finish up a release

git flow release finish RELEASE

Don’t forget to push your tags with git push origin --tags

Hotfixes

git flow hotfix start VERSION [BASENAME]

Finish a hotfix

git flow hotfix finish VERSION

Usefull commands

basic commandsdescription
git init
git status  [ -s ]status of files and local repo
git ls-filesshow files which are tracked by git
git log [ –oneline ] git log [–oneline –graph –decorate –all]shows commit history
git add <changed file> git add .git add -uadd single file to indexadd all files from the workspace to indexstage current workspace into index to cleanup inconsistencies
git commit [ -m ‘message’ ]commit into local repo only
git push -u origin masterpush the repo from local to remote repo
git help [option]get help page for specific options
git config –global alias.bla “command” git bla [– <filename>]set alias bla to a specific commandexec alias (for specific file)
git mv fileA fileB git commit -m “…..”rename fileA to fileBand commit
git rm fileC git commit -m “…..”delete fileCand commit
advanced commandsdescription
git reset HEAD <filename>undo changes from index back to workspace
git checkout <filename> git checkout master git checkout <branchname>checkout single file from local repo to workspacecheckout/switch to the master branchcheckout/switch to another branch
git checkout -b <new branchname> git branch <new branchname>create new branch and switch to it immediatelycreate new branch in the background, doesn’t switch to it
git branchshows all available branches
git diff git difftoolshow differences of local and committed file shows diff in vimdiff
git merge <other branch> git mergetoolmerge other branch into master (current branch)manage the different files in vimdiff
git branch -d <branchname>delete branch (does NOT include merge)
git branch -m <new name>rename a
$ git diff master..developmentcompare two branches
git tag <mytag> git tag -a v1.0 -m “description” git show v1.0add an additional label/tag to a branchannotation tag with release informationshows details of tag v1.0
git stash
git reset <ID> [–soft | –mixed | –hard] git reflog ….
git fetch ….update local repo with changes from remote repo. (non destructive)
git pull …update local repo with changes from remote repo. it does effectively a fetch and merge in one command
git clone https://<username>:<token>@github.com/<organisation-space>/<repository>download the remote repo into local workspace
git remote -v git remote show originshows url of remote reposhows detail infos of a remote repo
.gitignorecontains filename to exclude from git

Git Workflow

Release

Creating a release branch

Release branches are created from the develop branch. For example, say version 1.1.5 is the current production release and we have a big release coming up. The state of developis ready for the “next release” and we have decided that this will become version 1.2 (rather than 1.1.6 or 2.0). So we branch off and give the release branch a name reflecting the new version number:

$ git checkout -b release-1.2 develop

After creating a new branch and switching to it, we bump the version number. Here, bump-version.sh is a fictional shell script that changes some files in the working copy to reflect the new version. (This can of course be a manual change—the point being that some files change.) Then, the bumped version number is committed.

This new branch may exist there for a while, until the release may be rolled out definitely. During that time, bug fixes may be applied in this branch (rather than on the developbranch). Adding large new features here is strictly prohibited. They must be merged into develop, and therefore, wait for the next big release.

$ ./bump-version.sh 1.2<br>
$ git commit -a -m "Version 1.2"

Finishing a release branch 

$ git checkout master
$ git merge --no-ff release-1.2
$ git tag -a 1.2
$ git checkout develop
$ git merge --no-ff release-1.2
$ git branch -d release-1.2

When the state of the release branch is ready to become a real release, some actions need to be carried out.

First, the release branch is merged into master (since every commit on master is a new release by definition, remember).

Next, that commit on master must be tagged for easy future reference to this historical version.

Finally, the changes made on the release branch need to be merged back into develop, so that future releases also contain these bug fixes.

$ git checkout master
$ git merge --no-ff release-1.2
$ git tag -a 1.2

The release is now done, and tagged for future reference.

To keep the changes made in the release branch, we need to merge those back into develop, though. In Git:

$ git checkout develop
$ git merge --no-ff release-1.2

This step may well lead to a merge conflict (probably even, since we have changed the version number). If so, fix it and commit.

Now we are really done and the release branch may be removed, since we don’t need it anymore:

$ git branch -d release-1.2

Feature

$ git checkout -b myfeature develop
$ .. do changes...

$ git checkout develop
$ git merge --no-ff myfeature
$ git branch -d myfeature
$ git push origin develop

Creating a feature branch 

When starting work on a new feature, branch off from the develop branch.

$ git checkout -b myfeature develop
Switched to a new branch "myfeature"

Incorporating a finished feature on develop 

Finished features may be merged into the develop branch to definitely add them to the upcoming release:

$ git checkout develop<
$ git merge --no-ff myfeature
$ git branch -d myfeature
$ git push origin develop 

The --no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature.

In the latter case, it is impossible to see from the Git history which of the commit objects together have implemented a feature—you would have to manually read all the log messages. Reverting a whole feature (i.e. a group of commits), is a true headache in the latter situation, whereas it is easily done if the --no-ff flag was used.

Hotfix

$ git checkout -b hotfix-1.2.1 master
$ ... do changes ... 
$ git commit -a -m "Hotfix Version 1.2.1"
$ .. fix bug
$ git commit -m "Fixed severe production problem"

$ git checkout master
$ git merge --no-ff hotfix-1.2.1
$ git tag -a 1.2.1

# incude hotfix into develop
$ git checkout develop
$ git merge --no-ff hotfix-1.2.1

# finally, remove hotfix branch
$ git branch -d hotfix-1.2.1

Troubleshooting

Debugging Github Errors

export GIT_TRACE_PACKET=1
export GIT_TRACE=1
export GIT_CURL_VERBOSE=1

Error Message: Your local changes to the following files would be overwritten by merge:

error: Your local changes to the following files would be overwritten by merge:<br>
        README.md<br>
Please commit your changes or stash them before you merge.

Solution:

$ git fetch origin master
$ git diff origin/master -- [local-path]
$ git add [local-path]
$ gt commit -m "change: in file [local-path]"

fatal: sha1 file ‘<stdout>’ write error: Broken Pipe

When using ssh to connect to the repositoriy, sometime, you got a timeout if you push to many files or if the files are to big

One possible Solution

Configure ssh to use the following value

~/.ssh/config
Host *
     ServerAliveInterval 30
     ServerAliveCountMax 4

git clone: file name to long on windows

git config --system core.longpaths true

git config –global user.email “some@email.com” throws “error: only one config file at a time.

Try to unset GIT_CONFIG and then list your global config with

unset GIT_CONFIG
git config --global --list

Other Links

Useful Git commands for everyday use

10 useful Git commands you always need

Most useful Git commands

Git Cheat Sheet

Useful Git commands

Using local Filesystem as Respository-Master

Preparation

Set environment variables for easy typing

$ REPOS=$HOME/repos

Create Repository

$ mkdir $REPOS
$ cd    $REPOS
$ git init --bare src

Create src folder

$ mkdir $HOME/entw
$ cd    $HOME/entw
$ mkdir src
$ cd    src
$ git init

Create some content

$ touch README.md
$ git add -A
$ git commit -m "initial commit"
$ git remote add origin $REPOS/src
$ git remote -v
$ git push --set-upstream origin master
$ git push origin master

Create clone

$ mkdir $HOME/test
$ cd    $HOME/test
$ git clone $HOME/repos/src
$ cd src
$ ls -al
total 0
drwxr-xr-x   4 user  wheel  128 19 Mär 18:48 .
drwxr-xr-x   3 user  wheel   96 19 Mär 18:48 ..
drwxr-xr-x  12 user  wheel  384 19 Mär 18:48 .git
-rw-r--r--   1 user  wheel    0 19 Mär 18:48 README.md

You will notice, that the file README.md is empty. Because it was ony created with touch.

Add some content to source repository

$ cd $HOME/entw/src
$ echo "# This is the README.md from ENTW" >README.md
$ touch git_update
$ touch git_push
$ ls -al
total 16
drwxr-xr-x   6 user  wheel  192 19 Mär 18:53 .
drwxr-xr-x   3 user  wheel   96 19 Mär 18:43 ..
drwxr-xr-x  12 user  wheel  384 19 Mär 18:47 .git
-rw-r--r--   1 user  wheel   34 19 Mär 18:52 README.md
-rw-r--r--   1 user  wheel    0 19 Mär 18:53 git_push
-rw-r--r--   1 user  wheel    0 19 Mär 18:53 git_update

Add changes to repository

$ git add -A
$ git commit -m "-"
[master 106b27a] -
 3 files changed, 1 insertion(+)
 create mode 100644 git_push
 create mode 100644 git_update
$ git push --set-upstream origin master
Objekte aufzählen: 5, Fertig.
Zähle Objekte: 10
Delta-Kompression verwendet bis zu 8 Threads.
Komprimiere Objekte: 10
Schreibe Objekte: 10
Gesamt 3 (Delta 0), Wiederverwendet 0 (Delta 0)
To ..../repos/src
   7ed6d3b..106b27a  master -> master
Branch 'master' folgt nun Remote-Branch 'master' von 'origin'.

Update clone

$ cd $OME/test/src
$ git pull
# git fetch   # This updates 'remote' portion of local repo. 
# git reset --hard origin/<your-working-branch>
remote: Objekte aufzählen: 5, Fertig.
remote: Zähle Objekte: 10
remote: Komprimiere Objekte: 10
remote: Gesamt 3 (Delta 0), Wiederverwendet 0 (Delta 0)
Entpacke Objekte: 10
Von .../repos/src
   7ed6d3b..106b27a  master     -> origin/master
$ git merge origin/master
Aktualisiere 7ed6d3b..106b27a
Fast-forward
 README.md  | 1 +
 git_push   | 0
 git_update | 0
 3 files changed, 1 insertion(+)
 create mode 100644 git_push
 create mode 100644 git_update
$ ls -al
total 16
drwxr-xr-x   6 user  wheel  192 19 Mär 19:02 .
drwxr-xr-x   3 user  wheel   96 19 Mär 18:48 ..
drwxr-xr-x  14 user  wheel  448 19 Mär 19:02 .git
-rw-r--r--   1 user  wheel   34 19 Mär 19:02 README.md
-rw-r--r--   1 user  wheel    0 19 Mär 19:02 git_push
-rw-r--r--   1 user  wheel    0 19 Mär 19:02 git_update

TODO

See changes before pulling from remote git repositoryf

# fetch the changes from the remote
git fetch origin
# show commit logs of changes
git log master..origin/master
# show diffs of changes
git diff master..origin/master
# apply the changes by merge..
git merge origin/master
# .. or just pull the changes
git pull

You want to push your local files to remote files

git push -f <remote> <branch>
git push -f origin master

Configure Hooks

git config --global core.hooksPath .githooks
mkdir .githooks
cp .git/hooks/* .githooks

commit-msg

#!/bin/sh
#

NAME=$(git rev-parse --abbrev-ref HEAD) 
DESCRIPTION=$(git config branch."$NAME".description)

echo "$NAME"': '$(cat "$1") > "$1"
if [ -n "$DESCRIPTION" ] 
then
   echo "" >> "$1"
   echo $DESCRIPTION >> "$1"
fi

prepare-commit

#!/bin/sh
#

COMMIT_MSG_FILE=$1
COMMIT_SOURCE=$2
SHA1=$3

branchPath=$(git symbolic-ref -q HEAD)
branchName=${branchPath##*/}


if [ -n "$branchName" ]; then
    echo "$branchName | $(cat $1)" > $1
fi
file=$(git config hooks.versionfilename)
if [[ -z $file ]]
then
  file=".version"
fi

# Version number
echo "$(git rev-parse --abbrev-ref HEAD): $(git describe --tags --long)" >$file

exec git add $file

pre-commit

#!/bin/sh

_BRANCHPATH=$(git symbolic-ref -q HEAD)
_BRANCHNAME=${_BRANCHPATH##*/}

_TIMESTAMP="$(date '

echo "HOOK      : $0"
echo "PARAMETER : '$*''"
echo "BRANCHPATH: $_BRANCHPATH"
echo "BRANCHNAME: $_BRANCHNAME"

LOG() {
    [[ "$GIT_COMMIT_DETAILED_LOGGING" == "YES" ]] && echo "LOG: $*"
}

REPLACE()
{
   local _TYP;   _TYP="$1"; shift
   local _TAG;   _TAG="$1"; shift
   local _WITH; _WITH="$1"; shift
   local _FILE; _FILE="$1"; shift

   case "$_TYP" in
      PYTHON)   perl -pi -e 's/(\s*)(__DEPLOY_'${_TAG}'\s*=\s*)(".+")/${1}${2}"'"${_WITH}"'"/' "${_FILE}"
                ;;
      *)        LOG "Undefined typ '$TYP' for file $_FILE"
                ;;
   esac

   rm -f "${_FILE}.bak"
}

LOG "working on branch $_BRANCH"

for _FILE in $(git diff-index --name-status --cached HEAD | grep -v ^D | cut -c3-)
do
    LOG "checking: $_FILE"

    # Only examine known text files
    if [[ "$_FILE" =~ [.](py)$ ]]; then
        LOG "patching: $_FILE"

        REPLACE PYTHON TAG       "$_BRANCHNAME" "$_FILE"
        REPLACE PYTHON TIMESTAMP "$_TIMESTAMP"  "$_FILE"
    fi
done

Get Information

git rev-parse –abbrev-ref HEADget branch namefeature/add-new-content
git symbolic-ref -q HEADrefs/heads/feature/add-new-content
git rev-parse –show-toplevelshow current path of git repository

Config

Change Github repository for local clone

cd <original repository>
git remote set-url origin https://github.com/<new git user>/<new project name>
git push -u origin master

CR/LF Mapping

git config core.autocrlf true
git config --global core.safecrlf false

Create Release

#!/bin/bash

if [ $# -ne 1 ]; then
  echo "Syntax: release [VERSION]"
  exit 1
fi

VERSION=$1

# Create release
git flow release start $VERSION || exit 1
GIT_MERGE_AUTOEDIT=no git flow release finish -m $VERSION $VERSION

# Publish release
git push origin HEAD --tags

# Merge release into develop
git checkout develop
git merge master

SAS | Using Git and multi-repository environments

Using Git Hooks

$ git config --global core.hooksPath .githooks

Anhang: .githooks

prepare-commit-msg

#!/bin/bash
#

COMMIT_MSG_FILE=$1
COMMIT_SOURCE=$2
SHA1=$3

branchPath=$(git symbolic-ref -q HEAD)
branchName=${branchPath##*/}


if [ -n "$branchName" ]; then
    echo "$branchName | $(cat $1)" > $1
fi

pre-commit

#!/bin/bash
#

_BRANCHPATH=$(git symbolic-ref -q HEAD)
_BRANCH=${_BRANCHPATH##*/}

_TIMESTAMP="$(date '

LOG() {
        if [[ "$GIT_COMMIT_DETAILED_LOGGING" == "YES" ]]; then
                echo "LOG: $*"
        fi
}

REPLACE()
{
   local _TYP;   _TYP="$1"; shift
   local _TAG;   _TAG="$1"; shift
   local _WITH; _WITH="$1"; shift
   local _FILE; _FILE="$1"; shift

   case "$_TYP" in
      SAS)       # 
                 perl -pi -e 's/(.*)
                ;;
      CUSTOMER) # /* __DEPLOY_TAG =
                perl -pi -e 's/(\/\*\s*)('"__DEPLOY_$_TAG"'\s*=\s*)(.*$)/${1}${2
                ;;
      *)        LOG "Undefined typ '$TYP' for file $_FILE"
                ;;
   esac

   rm -f "${_FILE}.bak"
}

LOG "working on branch $_BRANCH"

for _FILE in $(git diff-index --name-status --cached HEAD | grep -v ^D | cut -c3-)
do
        LOG "checking file $_FILE"

        # Only examine known text files
        if [[ "$_FILE" =~ [.](sas)$ ]]; then
                LOG "working on file $_FILE"
                REPLACE SAS TAG       "$_BRANCH"    "$_FILE"
                REPLACE SAS TIMESTAMP "$_TIMESTAMP" "$_FILE"
        fi

        if [[ "$_FILE" =~ ^MA03 ]]; then
                LOG "working on bihis-customer script  $_FILE"
                REPLACE CUSTOMER TAG       "$_BRANCH"    "$_FILE"
                REPLACE CUSTOMER TIMESTAMP "$_TIMESTAMP" "$_FILE"
        fi
done

Github | Einstieg

Github ist eine Webseite, die es ermöglicht, gemeinsam an einem Softwareprojekt zu arbeiten.

Zusätzlich gibt es eine Versionsverwaltung: es wird also jede Änderung mit protokolliert, so das diese überprüft und rückgängig gemacht werden kann.

Einstieg

Der Arbeitsalltag eines Entwicklers, der Github nutzt sieht meistens wie folgt aus

  • er erstellt einmalig ein Github Konto
  • er richtet ein Repository ein, in dem er seine Programme speichert und verwaltet
  • das Repository wird “ausgecheckt“. Dadurch wird eine lokale Kopie auf der Festplatte angelegt
  • er arbeitet und programmiert in dieser lokalen Kopie
  • wenn er mit den Änderungen fertig ist, dann wird das Repository “eingecheckt“. Alle Änderungen sind dann wieder im Repository auf dem GibHub server gespeichert.

Mehr über das Arbeiten mit GibHub kann man hier und hier nachlesen.

Einrichten eines Github-Konto

Schritt 1: notwendige Informationen eingeben

Öffne deinen Browser und geh auf die Seite https://github.com/join

Gibt dann die notwendigen Informationen ein

  • Benutzername
  • Email
  • Passwort

Schritt 2: Verifizieren, das ein Mensch das Konto einrichtet

Klick auf die Pfeile, bis das Bild in der Mitte an der richtigen Stellung steht.

Klick dann auf Done

Schritt 4: Konto einrichten

Klick auf die Schaltfläche Create an account

Schritt 4: Kontotyp einrichten – ein kostenloses Konto

Behalte die Voreinstellung Free bei und klick auf Continue

Schritt 5: Überspringen der letzten Eingaben

Wähle hier aus, was Du selbst angeben möchtest und klick auf Submit.

Oder überspringe diese Schritt und klick auch skip this step

Schritt 6: Bestätigungslink öffnen

Schau in dein Postfach, du solltest eine Email erhalten haben. Klick auf den Bestätigungslink, so das dein Konto eingerichtet wird.

Erstes Repository einrichten

Melde dich bei deinem Github-Konto an, falls Du es noch nicht bist

Schritt 1: Repository erstellen

Auf der Startseite klick auf die Schaltfläche Start a project

Schritt 2. Neues Repository

Schritt 3: Informationen über das Repository

Gib den Namen ein

home

Gib eine Beschreibung ein:

Webseite meines Repositories

Wähle den Typ

Public

Selektiere die Option

Initialize this repository with a README

Klick auf die Schaltfläche

Create repository

Fertig. Das erste Repository ist erstellt!

Arbeiten mit den Repository

Vorbereitung

Als erstes ermitteln wir die URL, um das Repository auszuchecken

Die URL hat immer den gleiche Aufbau und lautet hier:

<a href="https://github.com/ionic-testaccount/home.git">https://github.com/ionic-testaccount/home.git</a>

Der allgemeien Aufbau ist:

<a href="https://github.com/<USERNAME>/<REPONAME>home.git">https://github.com/<USERNAME>/<REPONAME>.git</a>
Auschecken des Repositories

Ausgecheckt wird das Repository mit dem Kommando git clone. Man erstellt einen “Clone” der Repositories auf dem lokalen Rechner. Das Repository wird in einem Ordner erstellt, der den Namen des Repositories erhält:

Änderungen durchführen

Im nächsten Schritt erfolgt das Arbeiten mit dem Repository. Hier werden die gewünschten Änderungen an den Dateien durchgeführt.

Beispielhaft erstellen wir eine neue Datei TODO.md:

Status anzeigen

Mit dem Kommando git status können wir die Änderungen anzeigen lassen. Damit sehen wir, was sich im Vergleich zum Repository auf Github geändert hat.

In unserem Beispiel wird die neue Datei angezeigt als Untracked file:

Änderungen übernehmen

Mit Hilfe der Kommandos git add wird die durchgeführten Änderungen “vorgemerkt” für die Aufnahme in das Repository.

Das eigentliche hinzufügen erfolgt durch das Bestätigen der Änderungen: mit dem Kommando git commit. Durch den Parameter -m wird eine Beschreibung der Änderung hinzugefügt.

Einchecken des Repositories

Zum Abschluss wollen wir die bestätigten Änderungen in das Repository hochladen.

Hier benötigen wir natürlich die erforderlichen Rechte.

Wir erhalten diese, in dem wir unseren Benutzernamen mit angeben. Wir passen dazu die URL des Repositories an:

Jetzt erfolgt das Hochladen mit git push. Es muss nur noch das Passwort angegeben werden:

Der abschliessende Status zeigt, das alle Änderungen übernommen sind und das lokale Repository auf dem gleiche Stand ist, also “clean”

Repository auf Github prüfen

Ein Blick auf die Webseite unseres Repositories zeigt, das die Änderungen übernommen wurde. Wir sehen die neue Datei mit den von uns verwendeten Kommentar.

by Ralph Git und Github