This version (2024/10/24 10:28) is a draft.
Approvals: 0/1

What is it?

  • Distributed VCS
  • Manages workflows of over 10 commits per hour
  • Works best with textual content or source code
  • Ability to create/edit locally with tools you know
  • Self contained history and configuration in .git folder
  • Only up-/download need network
  • Similar to diff and patch utilities
  • Stores history in a compressed hash-based store
  • Current checkout is the regular directory structure
  • Saves meta information with every commit for traceability

Create a new one

cd <REPO>
git init
ls -alh

Clone an existing one

git clone https://github.com/<USER>/<REPO>
cd <REPO>
ls -alh
git status
git diff
git diff --cached
git log

Note: this may use the pager (less/more)

Get changes from a specific remote, optionally integrating them into the current branch

git fetch <REMOTE> 
git pull <REMOTE>

You can always fetch the changes but pulling requires the local and remote branches to be somewhat aligned.

  • Pulling should be a fast-forward operation.
    • The current branch is a direct ancestor of the remote branch.
  • Ensures that pushing to the remote won’t introduce unrelated changes.
git push <REMOTE> <BRANCH>
Github/Gitlab Regular Git
Changes are pushed to your account changes are pushed to a throw-away branch
Merged by using a PR/MR on the websiteMerged manually if no conflicts arise
Inspection by collaborators during MR No inspection until deployed
Do NOT push directly to master!

From safe to loosing all local changes since last commit:

git stash
git reset
git reset --hard
git checkout <CLEAN> && git checkout -B <BRANCH>

Read the manual before loosing more of your changes than you wanted to reset!

Highly dependent on project/organization! But:

  • use branches, don’t work directly on master
  • try to work on one topic at a time
    • switch between branches when working on different parts of the project
    • create merge requests for every branch, that’s done or ready for review
  • write consice commit messages

Combined like this is a good way to start working:

  • Start by syncing the progress of upstream
git checkout master
git pull origin
git checkout -b addGitTalk
  • Work on your changes to the project
  • Add new code followed by
git diff
git status
git add [PATH]
git diff --cached
  • Repeat the two previous step or publish
git commit
git push

</blockquote></HTML>

  1. Create a new branch, which starts out identical to the current
  2. Work on the project
  3. Mark your changes as ready
  4. Check if all the changes look good and are marked for inclusion in the next commit
  5. Add your changes to the branch inside the repository
git checkout -b <NAME>
...
git add [PATH]
git diff; git diff --cached
git commit
  • pandoc/git/01_general/git.txt
  • Last modified: 2024/10/24 10:28
  • by 127.0.0.1