Tohuwabohu excorcism

This is an old revision of the document!

GIT

Usual commands

# Setting your branch to exactly match the remote branch can be done in two steps:
git fetch origin
git fetch origin
git reset --hard origin/master

# list all commits, 1 per line with comment and date
git log --pretty=format:"%ad:%an:%d:%B" --date=short --reverse --all --since=2.months.ago --author=Mendoza

# throw every local change away, go to the remote state of master
git reset --hard origin/master

# remove untracked files, dirs
git clean -f
git clean -fd

# If you want to revert changes made to the index (i.e., that you have added), do this. Warning this will reset all of your unpushed commits to master!
git reset

Gitflow Workflow

Gitflow Workflow - this is the workflow, which describes when to branch during the development

Own Main Branch (Tags with Versions)
Branch for Development
Branch for each Feature
Branch for each Release

https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow

FallPits

Use the http / https repository for cloning.
Add Git at the URL End
Use TortoiseGit or MSYGit - <fc #FF0000>NOT the Eclipse plugin Egit</fc> it makes problems with some repos

git clone http://git.eclipse.org/gitroot/e4/eclipse.platform.runtime.e4.git

Tortoise GIT

Storing the SSH private key to be used by TortoiseGit. The key must be in Putty format.

rename the key in “id_rsa” copy the key to

"C:\Users\USERNAME\.ssh\id_rsa"

Also store it in the global upstream:

git config --global remote.gitlab.puttykeyfile C:\\Users\\USERNAME\\id_rsa

Git Bash

This is the console for Git with own Syntax. It is started with

...\Programme\MsyGit\bin\sh.exe --login -i

GLOSSARY

Master	Main, default branch. Like the trunk in SVN
Origin	If you check out some branch locally - you can decide where your code go's, when you do push code. Push what you have committed to the remote repository. The “–set-upstream” option makes Git aware that your local “developBranch” branch should always be pushed to the remote “developBranch” branch on “origin” - this means in future you can just do “git push” whilst on the developBranch branch. git push --set-upstream origin developBranch Instead if you want to push repository to master branch, you can run: git push --set-upstream origin master
Index	THe list of pending changes, which you are about to commit
Stage	Before committing all of your changes - you can add some of 'em to the stage. (Like selecting of changes in the total list of workspace modifications)
Head	points to the last commit
Push	Like commit in SVN, sends changes to the remote repository.
three-way merge	Merge of the Last two parallel revisions C3, C4 with their base C2. After the merge C5 contains all changes from C2,C3,C4:
Rebase	Rebase is a merge alternative. Commits are made on old base, which you checked out when you started your work. In between people could have extended the old base, and moved the master 3 commits further to the right. So you would have had to do a three-way merge to bring you changes back to the project: . Or instead you can change you base (rebase to new master) and do an easier merge, based on the new master and your feature Achtung: Rebase changes the commit history. So if you already pushed some commits - do not rebase them, to be based on other commits. This would confuse the people, which are working on the commits, you already pushed. Again: the best is to rebase local changes you’ve made but haven’t shared yet before you push them in order to clean up your story, Details: https://git-scm.com/book/en/v2/Git-Branching-Rebasing
Stash	Stashing is what allows you to save your current changes to a local “stash-stack” and to revert the repository to the initial clean state. You can reapply (Stash Pop) the changes from stack at any time.
Ammend	Ability to extend your last commit. Your changes will be added to the last commit. Useful, if you forgot to check in a file. git add . git commit --amend See https://www.kernel.org/pub/software/scm/git/docs/git-commit.html

Initial Setup

Store the data in “C:\Users\<USERNAME>\.gitconfig”

git config --global user.name "John Doe"
git config --global user.email johndoe@example.com

USAGE

Store credentials

The credentials may be stored globally or project-locally.
THe local config is located in .git/config
THe global config is located in /home/YOURUSER/.gitconfig

locally

Advice git to store the credentials in a file. The config saying where to find the pass is stored locally (.git/config)

git config credential.helper store 'store --file ~/.git-credentials'

The credentials-configurations, saying where to look for the password are located in .git/config
store means, that the password is stored plain text in a file, default location ~/.git-credentials

Hpw the entry in .git/config look like

[credential]
        helper = store

Used credentials are in file ~/.git-credentials

http://developer:KC2SK0VRWT6FBoAyy2bAlNo3ytQ3-ad_HUZ4gBJDbvQ@git-aic.173.31.18.48.nip.io

globally

Using the key –global will advice git to store the configs globally for all projects The config saying where to find the pass is then stored in, ~/gitconfig not in (.git/config)

git config --global credential.helper store 'store --file ~/.git-credentials'

checkout from Gerrit

In Gerrit there are Links of the form:

git fetch git://git.eclipse.org/gitroot/tycho/org.eclipse.tycho refs/changes/63/8163/2 && git checkout FETCH_HEAD
git fetch https://git.eclipse.org/r/tycho/org.eclipse.tycho refs/changes/63/8163/2 && git format-patch -1 --stdout FETCH_HEAD

git fetch git://git.eclipse.org/gitroot/tycho/org.eclipse.tycho refs/changes/63/8163/1 && git checkout FETCH_HEAD
git fetch https://git.eclipse.org/r/tycho/org.eclipse.tycho refs/changes/63/8163/1 && git checkout FETCH_HEAD

Use the https links, to checkoout. The repository URL is here: https://git.eclipse.org/r/tycho/org.eclipse.tycho.git

The right Syntax to check out with MsyGit the given repository from above is:

 git clone https://git.eclipse.org/r/tycho/org.eclipse.tycho.git

Assembla

Summary:

Assembla has SSH Key authtication. It can be generated with Putty - the public key is uploaded here: https://www.assembla.com/user/edit/edit_git_settings
Then you should create a remote entry with yout Assembla email and private key under
```
TortoiseGit> Setting> Git> Remote  
```
Do the “Git Clone” somehwere

The details are here: http://blog.assembla.com/assemblablog/tabid/12618/bid/77264/Setting-Up-Git-on-Windows-in-Four-Easy-Steps.aspx

SSH key

To authenticate via SSH key - create a central configuration file and associate the URL with the private-key there.

%userprofile%/.ssh/config

Host code.mydomain.com
  IdentityFile C:\\1REPOS\\1code.mydomain\\ssh\\gitlab.ppk

Alternatively you can use TortoiseGit with a putty key.

Windows crlf convesion

Git may convert the Windows line breaks (CRLF) to Linux (LF)

Which will break shell scripts.

To disable it - open C:\ProgramData\Git\config

and modify

[core]
	autocrlf = false

overwriting the remote history in GIT repo

git reset --hard 9718422f4b79189c708d95f3302ce95f0bd10631

git push --force-with-lease

Rebase


# AT THE BEGINNING make sure you pushed all your local changes before you start

# executing commands below is basically equivalent to fresh "git clone"

# resets the current branch tip, and also deletes any changes in the working directory and staging area.
git reset --hard

# make sure you’re in the correct branch
git checkout "feat/adr-db-eco-0238-onboarding-service-device-enriched-api"

# This will remove all local untracked files, so only git tracked files remain
git clean -fdx



# make sure, that the "local repository" is up to date
git fetch origin main --verbose




# see https://docs.gitlab.com/ee/topics/git/git_rebase.html
# now rebase it against main
# prefer "origin/main" changes during conflicts
git rebase -Xtheirs origin/main


# Here I found conflict :( between Ola's changes on the swagger integration and changes made by Remy
# so I switched to the UI "TortoiseGit" to resolve em..

# continued rebasing after the resolution
# reapedly till no conflicts
git rebase --continue


# finally overwrite the remote history with the new rebased one
git push --force-with-lease

Table of Contents

GIT