Git basic concepts and howto on the command line

Concepts

Distributed

Git is a distributed source code management system which means that multiple developers can work on the same project on their local machine without a network connection. Changes are then later synchronized to a central point using the push command. In our case the changes go to the gitea server.

Most operations in git need only local files and resources to operate—generally no information is needed from another computer on your network for basic development.

Important note: in git "commit" only means that you created the commit in your local repository, you also need to push the changes to the server explicitly. This synchronizes the local code changes and commit messages to the server. Otherwise no one else can see your changes.

Collaboration with other team members only happens on pull (fetch) / push. This asynchronous workflow can lead to concurrent changes but since this is the key concept in git—it tries to minimize manual interaction and provide good tools.

There are also some best practices that should be applied for a smoother experience:

• Commit early, commit often
• Try to update regularly from the upstream branch (git pull)
• Try to integrate as soon as you got working code (git push)
• Code formatting on every commit helps enormously when merging
  • Eclipse save action!

Overview

• overview.plantuml

Revision

In git "revision numbers" work differently and are realized by the "commit hash". It is a calculated hash sum of the code and meta data like committer and date. From that commit hash no order is recognizable like from svn revision numbers.

In most git commands you can specify "commit references" as arguments which can be git commit hashes like 4739319abf9070ef0b0e2a73224820ae70488aa6 (but usually you only have to specify about 7 characters for it to be unique, like 4739319) or special names like HEAD, which points to the most recent commit in the current branch.

Some commands to deal with the missing sequential order property

At the beginning it might be annoying that you can't use the revision ordering to simply find out if a commit is part of a given "revision". But here are some command that might help to get that information from a git repo.

# search for a commit message
git log --grep="added flux capacitor"

# list all commits by author
git log --author="Max Muster"

# test if the current branch contains the given commit
git branch --contains <commit>

# examine the changes of a commit
git show <commit>

# display a commit graph with branches, hashes and messages
git --no-pager log --oneline --decorate --graph --all

Commit hash meta data example

sha1(
    commit message  => "second commit"
    committer       => Max Muster <M.Muster@gsi.de>
    commit date     => Sun Nov 9 12:23:51 2018 +0100
    author          => Max Muster <M.Muster@gsi.de>
    author date     => Sun Nov 9 12:23:52 2018 +0100
    tree            => 4739319abf9070ef0b0e2a73224820ae70488aa6
    parents         => [cac92f1f843f1b3777a2813fc5c841c96a427f2a]
)

A note on dates

The "author date" notes when this commit was originally made (i.e. when you finished the git commit). According to the docs of git commit, the author date could be overridden using the --date switch.

The "commit date" gets changed every time the commit is being modified, for example when rebasing the branch where the commit is in on another branch.

-- https://stackoverflow.com/a/11857467/405793

History care (commit log)

A lot of git's features allow for a better "history care". Like the change staging, interactively adding changes, amending commits, rebasing, squashing.

It helps to bundle commits of small changes with specific descriptions.

Why?

It allows to:

- easily track down the source of a problem when debugging because only associated changes are in that commit
- (cherry) pick specific features without "Beifang"
- revert faulty commits easily
- understand what has changed when pulling / merging / creating a release
- understand what might be the right choice when merging

Seen in a bigger scope this also means "branch care". Have a branch for each feature, have a branch for each bug fix. With git it can be done easily.

.git directory

Like svn, git uses a special directory called .git to store metadata and file data of currently inactive branches (as "objects")

.gitignore file

In git you can create and commit a simple file called .gitignore to define files that should not be considered. Basically file patterns that work with "ls" can be used. For more information see: https://git-scm.com/docs/gitignore

Further reading

See also https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F

Useful commands

Configuration

# Configure the username and mail address that should appear in commit messages
git config --global user.name "Max Muster"
git config --global user.email "M.Muster@gsi.de"

# configures which tool to use when a merge has to be performed
git config --global merge.tool meld
# configures which tool is used when calling "git difftool <commitA> <commitB>"
git config --global diff.tool meld

Get a git repository

# Clone a another repository, usually from our gitea server
git clone <REPOSITORY URL>
# See screenshot below on where to find the URL for a repo
git clone git@git.acc.gsi.de:schaller/GitMigrationScript.git

# or create an empty git repository and start fresh
git init

Where to find the repository url

Clone visualized

• clone.plantuml

Show differences

# Get information about the current branch and if it is up to date with the remotely tracked branch
git status

# On branch master
nothing to commit, working directory clean

# Show the current (unstaged) changes
git diff

# Show changes between the current working dir and the "R99" branch or tag.
git diff R99

# Show the difference between two commits
git diff <commitA>..<commitB>

# Open difftool for the complete directory tree (very useful)
git difftool -d R99

# Show all commits from the remote server origin's branch R99 until the cern server's master branch
git fetch --all # better update it before
git log origin/R99..cern/master

# Show the code differences for the same range (also works alternatively with "difftool -d")
git diff origin/R99..cern/master

Commit

Like in svn

git commit -a -m 'MM: made a change'
git push

The git way, using the "staging area"

git add filea
git add fileb
git commit -m 'MM: my small changes'
git add filec
git commit -m 'MM: more small changes'
git push

Undoing

# Reverting a file to the most recent commit (svn revert)
git checkout -- CONTRIBUTING.md
# The dashes "--" are used on the command line to make use no more "options" are passed to the command and now the file

# path is following. Because you can also specify a branch.
git checkout cern/master -- JustThisFile.java

# Remove changes from staging area (which then are still modified but will not be committed)
git reset HEAD CONTRIBUTING.md

# Changing the most recent commit (please use only if not already pushed)
git commit --amend

# Reverting a commit (WARNING NOT THE SAME AS SVN)
# *git revert* has the same name as a svn command but does something different. Here, it additionally creates
# an undo-commit that undoes all changes of the specified commit. This commit can then be pushed and will also remove
# the code in subsequent merges from other branches too.
#
# The use case for this is when removing established code that seems faulty. For "accidental changes" in the local
# repository "git checkout" or "git reset --hard <myworkingcommithash>" are usually better choices.
git revert <commit>

# Reset all changes to the latest commit (Use with caution!)
git reset --hard

Note: All changes are only locally until you push.

See https://git-scm.com/book/en/v2/Git-Basics-Undoing-Things#_undoing for more information.

Manage files

git rm myfile.txt
git mv myother.txt myfilestxt

View log / history

# Show the latest 5 log messages of the current branch
git log -5

# Display a nice colored commit graph on the command line for all known branches
git log --oneline --decorate --graph --all

# Display the most recent authors for every line of the file
git blame -- MyFile.java

Stage

A set of selected changes that will be committed. Here you can prepare your commit. Only staged changes will be committed unless commit -a is used.

# Add a file to the staging area
git add TheFile.java

# Show the diff between all staged files and the latest (local) commit
# (--cached is a synonym for staged in this case, just in case you might see it)
git diff --staged

# Remove a file from the staging area
git reset TheFile.java

# Keep the file in your working tree but delete it from your staging area.
git rm --cached README

Remote

A remote is a connection to another git repository like our gitea server.

# Fetch the current state from the server and merge the current branch with the upstream changes (tracked branch)
git pull

# Manually
# The main remote repository is usually named "origin" and all "tracked" or "cloned" branches are updated
# We want to merge with branch "master" from "origin" and can directly address it using "origin/master"
git fetch origin
git merge origin/master

# List all remotes and their URL
git remote -v

# Add a new remote URL with the name "cern"
git remote add cern git://someurl.ch

# Fetch all branches of the remote repo
git fetch cern

# Show details about the repo and "tracked" (checked out) branches
git remote show cern

# Check out the current cern master branch as a new local branch with name "cern_master"
git checkout -b cern_master cern/master

Tags

Commits can be tagged and are also referable to by this name. Unlike svn nothing has to be copied.

# List tags
git tag

# Tag the current commit with the name "R99"
git tag -a R99 -m 'This is our final R99 version'

# Push the new tag
git push R99
# or - push the current commit including all associated tags
git push --follow-tags

# Later we can simply come back to this commit using
git checkout R99

Branches

In git you are always on a "branch". The default name of the main branch is master (like trunk in svn) but technically it is just a regular branch.

Unlike svn nothing has to be copied to create a new branch, similar to tags it can almost be seen like a pointer to a commit.

# List all local branches
git branch

# List all remote branches
git branch -r

# List all known branches
git branch -a

# Create a new branch from the local master branch and check it out
git checkout -b master

# Create a new branch, starting from the current commit, but don't use it right away
git branch myname

# Create a new branch, starting from the specified remote branch, but don't use it right away
git branch subfeaturebranch origin/featurebranch

# Switch to a different branch
# (If myfeature exists on our main remote repo (origin) it will automatically track that branch and create a local copy)
git checkout myfeature

# Push our new branch to the remote repository origin (gitea)
git push origin subfeaturebranch

# Delete a branch locally
git branch -d mynewbranch

# Delete the branch remotely (Attention!)
git push origin --delete mynewbranch

Merging

# The following command merges the latest master code to the current branch
git fetch origin master
git merge origin/master

# Merge a myfeature branch into master
    # Make sure we are in master
    git checkout master
    # Make sure the repo is clean (maybe use git stash to clean the repo temporarily)
    git status
    # Merge myfeature into the current branch
    git merge myfeature
    # To send it to the server: git push

Stash

A local "shelves" where you can store changes temporarily (even across branches).

# "Stash" all changes to tracked files and make the repository clean
git stash -m 'just storing some current experimental things'

# List all stashed changes
git stash list

# Show a diff of the most recently stashed entry
git stash show -p

# Apply and remove the latest stashed entry
git stash pop

# Apply but don't remove the stashed entry
git stash apply

git lfs

Large File Support - a way to store large files more efficiently. Otherwise each change is stored locally.

# Activate lfs support for this repo
git lfs install

# Declare "*psd" files as large
git lfs track "*.psd"

# Commit the automatically created lfs configuration
git add .gitattributes

# Note: old files will not be migrated, activate early or "rewrite history"

See https://www.atlassian.com/git/tutorials/git-lfs for more information.

Workflows

Oneflow

A lightweight workflow allowing release branches and hotfixes.

https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow#starting-a-hotfix-branch

Gitflow

An elaborate workflow when using git and releases:

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

See the picture below the headline "Hotfix Branches" for a complete graphical representation.

Advanced

# *Merge only one* commit into the current branch
git cherry-pick 2342ab3

# *Add code parts interactively*, deciding for separate smaller chunks of each file (almost like synchronize in an IDE)
git add -p

# *"Squash"* all *commits* into one and give it a new description, could be used for small feature branches
# (The original history of the branch is not taken over)
git merge --squash

# *Merge and explicitly create a (merge) commit* even if a simple pointer forward would be possible, add all merged
# commits as description for the commit.
# (Usually used when creating releases into the master branch.)
git merge --no-ff --log

# Only merge the branch if is *possible without manual merging*
# (It will only move the "branch pointer" to the newer commit. Useful for "testing" if it can be done easily without
# having to merge anything manually.)
git merge --ff-only

# Apply the commits you made on this branch to the given REF as the new "base". And *interactively allow to decide
# the fate of each commit*.
# Available actions per commit: Reorder, Squash, Leave out, Rename, Change files
git rebase -i REF
# But changes will also change every following commit and therefor it's git hash. *You will have to force push* the
# changes if any of the commits are
# *already on the remote system* and other users will have to "force pull". Therefore *ONLY USE THIS ON LOCAL BRANCHES*.

# If hell freezes over you could even host your own repo as git server (of course permissions and such is not so easy)
git daemon --reuseaddr --base-path=/srv/git/ /srv/git/

A normal flow when cloning a repository and making a bugfix

Without making pull requests. Working on "master" and creating a "bugfix" branch to work with.

#
# Example preparation:
#
# Clone (checkout) a repository and add two files with some content:
#

$ git clone git@git.acc.gsi.de:bpeter/git-demo.git 
    Cloning into 'git-demo'...
    remote: Counting objects: 3, done.
    remote: Total 3 (delta 0), reused 0 (delta 0)
    Receiving objects: 100% (3/3), done.

#
# Usually the repository is checked out into a folder, named like the
# directory. We have to enter it.
#

$ cd git-demo 

#
# No changes yet and  everything up to date with the remote
#

(master)$ git status
    # On branch master
    nothing to commit, working directory clean

#
# Locally and remote only the branch "master" exists
#

(master)$ git branch
    * master

(master)$ git branch -a
    * master
      remotes/origin/HEAD -> origin/master
      remotes/origin/master

#
# Until now only the initial commit, from the repo creation exists
#

(master)$ git --no-pager log
    commit ebf2ea43a21de98026405957a4ee0aec9182ed7e
    Author: Benjamin Peter <b.peter@gsi.de>
    Date:   Wed Jul 31 16:57:50 2019 +0200
    
        Initial commit

#
# Create the files simplefile.txt and anotherfile.txt with some content
#

(master)$ echo "change1" > simplefile.txt

(master)$ echo "change2" > anotherfile.txt

#
# We can now see the two new files, marked as "untracked" we need to "add"
# them first before they will be committed
#

(master)$ git status
    # On branch master
    # Untracked files:
    #   (use "git add <file>..." to include in what will be committed)
    #
    #    anotherfile.txt
    #    simplefile.txt
    nothing added to commit but untracked files present (use "git add" to track)

(master)$ git add anotherfile.txt simplefile.txt 

#
# The files are now listed as "new files" under "changes to be commited"
#

(master)$ git status
    # On branch master
    # Changes to be committed:
    #   (use "git reset HEAD <file>..." to unstage)
    #
    #    new file:   anotherfile.txt
    #    new file:   simplefile.txt
    #

#
# Let's commit those changes. The new commit hash is printed in it's short version:
# 
# 4b0b758
#

(master)$ git commit -m 'Added simple changes'
    [master 4b0b758] Added simple changes
     2 files changed, 2 insertions(+)
     create mode 100644 anotherfile.txt
     create mode 100644 simplefile.txt

#
# All changes are committed to the local repository. But they have not yet
# been pushed. "your branch is ahead of 'origin/master"
#

(master)$ git status
    # On branch master
    # Your branch is ahead of 'origin/master' by 1 commit.
    #   (use "git push" to publish your local commits)
    #
    nothing to commit, working directory clean

#
# We could also examine the commit using show
#
(master)$ git --no-pager show 4b0b758
    commit 4b0b75897b72ffe4759a609b111a87cfa55168f4
    Author: Benjamin Peter <B.Peter@gsi.de>
    Date:   Thu Aug 1 08:51:57 2019 +0200
    
        Added simple changes
    
    diff --git a/anotherfile.txt b/anotherfile.txt
    new file mode 100644
    index 0000000..39c5733
    --- /dev/null
    +++ b/anotherfile.txt
    @@ -0,0 +1 @@
    +change2
    diff --git a/simplefile.txt b/simplefile.txt
    new file mode 100644
    index 0000000..5be4a41
    --- /dev/null
    +++ b/simplefile.txt
    @@ -0,0 +1 @@
    +change1


#
# Push the changes from the local repository to origin (gitea server)
#

(master)$ git push
    Counting objects: 5, done.
    Delta compression using up to 20 threads.
    Compressing objects: 100% (2/2), done.
    Writing objects: 100% (4/4), 345 bytes | 0 bytes/s, done.
    Total 4 (delta 0), reused 0 (delta 0)
    To git@git.acc.gsi.de:bpeter/git-demo.git
       ebf2ea4..4b0b758  master -> master

#
# If unsure we could examine the remote configuration using "git remote"
#
(master)$ git remote show origin
    * remote origin
      Fetch URL: git@git.acc.gsi.de:bpeter/git-demo.git
      Push  URL: git@git.acc.gsi.de:bpeter/git-demo.git
      HEAD branch: master
      Remote branch:
        master tracked
      Local branch configured for 'git pull':
        master rebases onto remote master
      Local ref configured for 'git push':
        master pushes to master (up to date)

#
# We have committed and uploaded all our changes:
#

(master)$ git status
    # On branch master
    nothing to commit, working directory clean

#
# The log does not look like this
#

(master)$ git --no-pager log                  
    commit 4b0b75897b72ffe4759a609b111a87cfa55168f4
    Author: Benjamin Peter <B.Peter@gsi.de>
    Date:   Thu Aug 1 08:51:57 2019 +0200
    
        Added simple changes
    
    commit ebf2ea43a21de98026405957a4ee0aec9182ed7e
    Author: Benjamin Peter <b.peter@gsi.de>
    Date:   Wed Jul 31 16:57:50 2019 +0200
    
        Initial commit

Performing the bugfix

#
# Scenario:
#
# We do now want to fix a bug, "anotherfile.txt" is missing
# "change3". Therefore we use a bugfix branch and later merge
# it back to master when everything is fixed and tested.
#

#
# Check if the working directory is clean and we are up to date
# with remote
#

(master)$ git status
   # On branch master
   nothing to commit, working directory clean

#
# Create a new branch "bugfix/add-missing-change" for our changes
# and directly check it out. It usually is common practice to prefix
# bugfix branches with "bugfix/" or feature branches with "feature/"
# or hotfixes with "hotfix/"
#

(master)$ git checkout -b bugfix/add-missing-change
   Switched to a new branch 'bugfix/add-missing-change'

#
# If we list all branch information we can see there is a local branch
# add-missing-change which is not yet known remote. This is fine for now.
#

(bugfix/add-missing-change)$ git branch -a
   * bugfix/add-missing-change
     master
     remotes/origin/HEAD -> origin/master
     remotes/origin/master

#
# Have a look at the currently present files
#

(bugfix/add-missing-change)$ ls -l
   total 12
   -rw------- 1 bpeter bel  8 Aug  1 08:51 anotherfile.txt
   -rw------- 1 bpeter bel 12 Aug  1 08:49 README.md
   -rw------- 1 bpeter bel  8 Aug  1 08:51 simplefile.txt

#
# Add the missing "change3" to our file
#

(bugfix/add-missing-change)$ echo "change3" >> simplefile.txt 

#
# Use "git status" to have a look at our repository state
#

(bugfix/add-missing-change)$ git status
   # On branch bugfix/add-missing-change
   # Changes not staged for commit:
   #   (use "git add <file>..." to update what will be committed)
   #   (use "git checkout -- <file>..." to discard changes in working directory)
   #
   #   modified:   simplefile.txt
   #
   no changes added to commit (use "git add" and/or "git commit -a")

#
# Oh noooo! We changed the wrong file, we should have changed "anotherfile.txt".
# Okay, since nothing has been committed yet, we can simple use "git checkout" to
# get back the latest committed version.
#

(bugfix/add-missing-change)$ git checkout simplefile.txt 

#
# The files is clean again
#

(bugfix/add-missing-change)$ git status
   # On branch bugfix/add-missing-change
   nothing to commit, working directory clean

#
# Do the correct change to "anotherfile.txt"
#

(bugfix/add-missing-change)$ echo "change3" >> anotherfile.txt 

#
# Check the repository status
#
# It now says the changes are not yet staged and we should use "git add"
# for that.
#

(bugfix/add-missing-change)$ git status
   # On branch bugfix/add-missing-change
   # Changes not staged for commit:
   #   (use "git add <file>..." to update what will be committed)
   #   (use "git checkout -- <file>..." to discard changes in working directory)
   #
   #   modified:   anotherfile.txt
   #
   no changes added to commit (use "git add" and/or "git commit -a")

#
# Since it is a simple change we can simple use "git commit -a" which automatically
# does the "git add" command.
#

(bugfix/add-missing-change)$ git commit -am "BP: added missing change3"
   [bugfix/add-missing-change 3903e96] BP: added missing change3
    1 file changed, 1 insertion(+)

#
# Great, new commit, hash 3903e96
#

(bugfix/add-missing-change)$ git status
   # On branch bugfix/add-missing-change
   nothing to commit, working directory clean

#
# But, the changes are now only locally! No body else can see them and if our
# computer goes down, the changes are lost. So better push our bugfix branch
# also to the server.
#

(bugfix/add-missing-change)$ git push
   fatal: The current branch bugfix/add-missing-change has no upstream branch.
   To push the current branch and set the remote as upstream, use
   
       git push --set-upstream origin bugfix/add-missing-change

#
# It did not work, we have to tell git where to put it and to set up a permanent reference
# between the local and remote repository. But no prob it will give use the required
# command. Thanks.
#

(bugfix/add-missing-change)$ git push --set-upstream origin bugfix/add-missing-change
   Counting objects: 5, done.
   Delta compression using up to 20 threads.
   Compressing objects: 100% (2/2), done.
   Writing objects: 100% (3/3), 277 bytes | 0 bytes/s, done.
   Total 3 (delta 1), reused 0 (delta 0)
   remote: 
   remote: Create a new pull request for 'bugfix/add-missing-change':
   remote:   https://git.acc.gsi.de/bpeter/git-demo/compare/master...bugfix/add-missing-change
   remote: 
   To git@git.acc.gsi.de:bpeter/git-demo.git
    * [new branch]      bugfix/add-missing-change -> bugfix/add-missing-change
   Branch bugfix/add-missing-change set up to track remote branch bugfix/add-missing-change from origin by rebasing.

#
# Great, tracking is set up now and the branch uploaded.
#
# We can also see this now using "git branch -a".
#

(bugfix/add-missing-change)$ git branch -a
   * bugfix/add-missing-change
     master
     remotes/origin/HEAD -> origin/master
     remotes/origin/bugfix/add-missing-change
     remotes/origin/master

#
# Let's have a look at the "commit graph" showing the commits and where the latest
# branch pointer, points to.
#
# The special pointer "HEAD" and our local branch "bugfix/add-missing-change" as well as
# the remote "origin/bugfix/add-missing-change" point to our recent commit 3903e96.
#
# The local master "master" and remote master "origin/master" points to the previous commit 4b0b758.
#

(bugfix/add-missing-change)$ git --no-pager log --oneline --decorate --graph --all
   * 3903e96 (HEAD, origin/bugfix/add-missing-change, bugfix/add-missing-change) BP: added missing change3
   * 4b0b758 (origin/master, origin/HEAD, master) Added simple changes
   * ebf2ea4 Initial commit

#
# We are satisfied with our fix and want to merge the bugfix branch into master.
#
# Let us switch to master, as we usually have to be in the branch we want to "operate on". After
# that we should check if there have been changes in the meantime (use "git pull"), otherwise we
# would have to update with the remote again and potentially merge a second time.
#

(bugfix/add-missing-change)$ git checkout master
   Switched to branch 'master'

(master)$ git pull
   Current branch master is up to date.

#
# Now merge our bugfix branch into master
#
# It says this will be done using "Fast-forward" which means there are no conflicts expected
# and the branch pointer will simply be moved forward to our commit.
#
# (In case of a conflict the "mergetool" would now be started and after some changes we have
# to run "git commit" to create a merge commit which should only contain the changes required to
# merge the branches)
#

(master)$ git merge bugfix/add-missing-change 
   Updating 4b0b758..3903e96
   Fast-forward
    anotherfile.txt | 1 +
    1 file changed, 1 insertion(+)

#
# Looking at the history tree, we can now see that the local master "master" does now point to
# our bugfix commit 3903e96. The remote master "origin/master" is not yet updated.
#

(master)$ git --no-pager log --oneline --decorate --graph --all
   * 3903e96 (HEAD, origin/bugfix/add-missing-change, master, bugfix/add-missing-change) BP: added missing change3
   * 4b0b758 (origin/master, origin/HEAD) Added simple changes
   * ebf2ea4 Initial commit

#
# So let's push the local master. We do not have to specify any more arguments since it is
# configured to track the expected remote "master -> origin/master"
#

(master)$ git push 
   Total 0 (delta 0), reused 0 (delta 0)
   To git@git.acc.gsi.de:bpeter/git-demo.git
      4b0b758..3903e96  master -> master

#
# Check the history tree again. All branches do now point to the most recent commit.
#

(master)$ git --no-pager log --oneline --decorate --graph --all
   * 3903e96 (HEAD, origin/master, origin/bugfix/add-missing-change, origin/HEAD, master, bugfix/add-missing-change) BP: added missing change3
   * 4b0b758 Added simple changes
   * ebf2ea4 Initial commit

#
# Once we are done, we can delete our bugfix branch. This is quite safe, since "branch -d"
# checks if the branch has already been merged into another branch. (-D overrides this check!)
#

(master)$ git branch -d bugfix/add-missing-change
   Deleted branch bugfix/add-missing-change (was 3903e96).

#
# Again, we have to deal with remote separately. Use the following command to delete it aswell.
#

(master)$ git push origin --delete bugfix/add-missing-change 
   To git@git.acc.gsi.de:bpeter/git-demo.git
    - [deleted]         bugfix/add-missing-change

# Bug fixed, everyone happy ;-)

In a project where pull-request via gitea are used, the feature branch is not manually merged to develop but after the push to the feature branch the process continue on the gitea website and merging works from the ui.

Cheatsheet

Git Cheatsheet https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet

Try not to use rebase or force if you need a cheat sheet for it ;-)

Troubleshoot

$ git status
fatal: Not a git repository (or any parent up to mount point /common/home)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).Sources

You are not in the correct directory, you have to be in or below the directory containing the .git directory. Check with ls -la

• Book https://git-scm.com/book/en/
• What is git? Main Concepts. https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F
• Undoing: https://git-scm.com/book/en/v2/Git-Basics-Undoing-Things#_undoing
• Git LFS https://www.atlassian.com/git/tutorials/git-lfs
• Git Hashes https://blog.thoughtram.io/git/2014/11/18/the-anatomy-of-a-git-commit.html