$ 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: 100% (5/5), done.
Writing objects: 100% (5/5), 5.55 KiB | 567.00 KiB/s, done.
Total 5 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), done.
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
Starting Jenkins this way, you will see all log messages on the console.
At this step, the importen messages are the initial admin password:
2020-02-28 16:50:00.749+0000 [id=32] INFO jenkins.install.SetupWizard#init:
*************************************************************
*************************************************************
*************************************************************
Jenkins initial setup is required. An admin user has been created and a password generated.
Please use the following password to proceed to installation:
6c408145cc964f72ab45cd80e247fa2d
This may also be found at: /home/jenkins/home(secrets/initialAdminPassword
*************************************************************
*************************************************************
*************************************************************
2020-02-28 16:50:05.848+0000 [id=57] INFO h.m.DownloadService$Downloadable#load: Obtained the updated data file for hudson.tasks.Maven.MavenInstaller
Depending on the way, you install zsh, the installation process clones git-repositories to your home folder $HOME.
Starting zsh does at one point check files git ‘git ls-files’. So, if you have a lot of files and folders in your home directory, this will take some time.
If you want to speedup the start, create a .gitignore file in your home an include all files with not relations to zsh, e.g. .npm, .ssh or .Trash.
Customize Zsh Prompt
Powerlevel9k
Installation on mac OS
Install
$ brew tap sambadevi/powerlevel9k
$ brew install powerlevel9k
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
DESCRIPTION
GIT 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 commits
git config --global user.email xxx@example.com
Will remove user credential details from the repository
git config --local credential.helper ""
git config —show-origin
List all currently configured remote repository URLs
git remote -v
If you haven’t connected your local repository to a remote server, To add a remote server to a local repository
git remote add origin <repo_url>
Git Commit and Push
DESCRIPTION
GIT COMMAND
Create a file name README.md with Readme content content
echo "Readme content" >> README.md
List the files you’ve changed and those you still need to add or commit
git status
Add all or one file to staging
git add . OR git add file_name
Commit changes to head with message
git commit -m 'message'
Commit any files you’ve added with git add, and also commit any files you’ve changed since then
git commit -a
Send all commits from local repository to remote repository
git 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 branch
git push -u <remote-branch>
Send changes to the master branch of your remote repository
git push origin master
Push a specific branch to your remote repository
git push origin <branch_name>
Push all branches to your remote repository
git push --all origin
Working with the Git Workflow
The following steps are based on a branching model, described here.
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
$ 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
shows url of remote reposhows detail infos of a remote repo
.gitignore
contains 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"
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
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.
#!/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 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.
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.
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept All”, you consent to the use of ALL the cookies. However, you may visit "Cookie Settings" to provide a controlled consent.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Duration
Description
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.