===== GIT ======

==== Usual commands =====
<code>

# 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
</code>

==== 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


{{https://www.atlassian.com/git/images/tutorials/collaborating/comparing-workflows/gitflow-workflow/05.svg?20}}
==== FallPits ====
  * Use the http / https repository for cloning.
  * Add Git at the URL End
  * Use [[http://code.google.com/p/tortoisegit/|TortoiseGit]] or [[http://code.google.com/p/msysgit/|MSYGit]] - <fc #FF0000>NOT the Eclipse plugin Egit</fc> it makes problems with some repos

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


==== 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
<code>
"C:\Users\USERNAME\.ssh\id_rsa"
</code>


Also store it in the global upstream:
<code>
git config --global remote.gitlab.puttykeyfile C:\\Users\\USERNAME\\id_rsa
</code>

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

<code>
...\Programme\MsyGit\bin\sh.exe --login -i
</code>

{{https://s3.eu-central-1.amazonaws.com/alf-digital-wiki-pics/sharex/nkP1CdUbXS.png}}


==== GLOSSARY =====

|Master| Main, default branch. Like the **trunk** in SVN |
|Origin|<WRAP> 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.
<code>
git push --set-upstream origin developBranch
</code>
Instead if you want to push repository to master branch, you can run: 
<code>
git push --set-upstream origin master
</code></WRAP>|
|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. \\ {{http://i520.photobucket.com/albums/w327/schajtan/2016-04-11_08-16-48_zpswaed2qyx.png?400}} \\ After the merge C5 contains all changes from C2,C3,C4: \\ {{http://i520.photobucket.com/albums/w327/schajtan/2016-04-11_08-19-55_zpscx081ycy.png}}|
|Rebase|<WRAP> 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: {{http://i520.photobucket.com/albums/w327/schajtan/2016-04-11_08-55-33_zpsvjqffd1j.png}}.\\ \\ Or instead you can change you base (**rebase to new master**) and do an easier merge, based on the new master and your feature \\ {{http://rypress.com/tutorials/git/media/5-1.png}} 
\\ \\
**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
</WRAP>|
|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|<WRAP> 
Ability to extend your last commit. \\
Your changes will be added to the last commit. \\
Useful, if you forgot to check in a file. \\

<code>
git add .
git commit --amend
</code>

See https://www.kernel.org/pub/software/scm/git/docs/git-commit.html
</WRAP>|


==== Initial Setup on Windows =====

== .gitconfig ==

File: 
''C:\Users\<USERNAME>\.gitconfig''

You can use the cmd to config git.
Tell it the default user name / mail

<code>
git config --global user.name "John Doe"
git config --global user.email johndoe@example.com
</code>

== .ssh\config ==

File: 
''C:\Users\<USERNAME>\.ssh\config''

Configure ssh to use e.g. the github-key for github url.

  * Use the ''/'' notation to point git to the place where you keep the keys. I keep them in my back-up folder.
  * Use quotes ''"'' especially if you have empty spaces.


<sxh shell>
Host github.com
    Hostname github.com
    User git
    IdentityFile "/C/YOUR PATH TO KEY FOLDER/_KEYS/Github/github-privateKey"
</sxh>



==== 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)
<code>
git config credential.helper store 'store --file ~/.git-credentials'
</code>

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
<code>
[credential]
        helper = store
</code>

Used credentials are in file ~/.git-credentials
<code>
http://developer:KC2SK0VRWT6FBoAyy2bAlNo3ytQ3-ad_HUZ4gBJDbvQ@git-aic.173.31.18.48.nip.io
</code>


== 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)
<code>
git config --global credential.helper store 'store --file ~/.git-credentials'
</code>





=== checkout from Gerrit ===

In Gerrit there are Links of the form:
<code>
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
</code>

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 [[http://code.google.com/p/msysgit/|MsyGit]] the given repository from above is:
<code>
 git clone https://git.eclipse.org/r/tycho/org.eclipse.tycho.git
</code>



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

%userprofile%/.ssh/config
<code>
Host code.mydomain.com
  IdentityFile C:\\1REPOS\\1code.mydomain\\ssh\\gitlab.ppk
</code>

Alternatively you can use TortoiseGit with a putty key.
{{https://lh3.googleusercontent.com/-nV9g5rHK-5I/W02Tdhl5h-I/AAAAAAAABk8/K4yAqtiNYmwxgh6JUGqUuKxgL3cNUT1XACHMYCw/s0/TortoiseGitProc_2018-07-17_08-57-37.png}}



=== 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 
<code>
[core]
	autocrlf = false
</code>



==== overwriting the remote history in GIT repo ====

overwriting the remote history in GIT repo with commitId 9718422f4b79189c708d95f3302ce95f0bd10631

<code>
# find your commit id 9718422f4b79189c708d95f3302ce95f0bd10631
git log

git reset --hard 9718422f4b79189c708d95f3302ce95f0bd10631

git push --force-with-lease

</code>


==== Rebase =====

<sxh shell>


# 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

</sxh>


==== Getting rid of Git History =====

https://stackoverflow.com/questions/13716658/how-to-delete-all-commit-history-in-github

<sxh shell>


#  first backup your history by copying the branch.
#  can remove it later
git switch master
git branch master_history_2023_11_31
git push origin -u master_history_2023_11_31




# Checkout as orphan, without history
git checkout --orphan latest_branch

# Add all the files
git add -A

# Commit the changes
git commit -am "commit message"

# Delete the branch
git branch -D master

# Rename the current branch to master
git branch -m master

# Finally, force update your repository
git push -f origin master


</sxh>




==== Deleting branch  =====

Delete branch ''latest_branch''

<sxh shell>

git branch -D latest_branch

git push origin --delete latest_branch

</sxh>



==== Remove unreachable blobs, reduce size of repo  =====

''objects/pack'': This folder contains packed object files. Git occasionally compresses objects into packfiles to save space and improve performance.


Sometimes in ''objects/pack'' there are blobs collected.
Even if you removed the history on the current branch, they might persist blowing up the repo.

To clean them up - use the garbage collector.

<sxh shell>

# This command is used to expire all entries in the reflog that are not reachable from the current commit (i.e., entries that are not part of any branch or tag). The --expire-unreachable=all flag specifies that even unreachable entries (such as commits that were "lost" due to being orphaned or removed by a rebase or reset) should be expired. 
# The --all flag ensures that it applies to all branches and tags, not just the current branch.
git reflog expire --expire-unreachable=all --all



# This command triggers Git's garbage collection process (gc stands for "garbage collect"). The --prune=all flag tells Git to aggressively prune all unreachable objects, including unreferenced commits, blobs, trees, and other data that are not reachable from any branch, tag, or reflog entry. This helps to reclaim disk space by removing unnecessary or dangling objects from the repository.

git gc --prune=all
</sxh>