diff --git a/linux/07_bonus_git.md b/linux/07_bonus_git.md
deleted file mode 100644
index b2653f2f64e4b14f2f1ba6ebcb764f0d21c56b1c..0000000000000000000000000000000000000000
--- a/linux/07_bonus_git.md
+++ /dev/null
@@ -1,3 +0,0 @@
-literally do man git,
-then do man 7 gittutorial and man 7 giteveryday
-and just run that while working with on project
diff --git a/linux/07_git.md b/linux/07_git.md
index c03381a2d149c7aed424edc87328e2a5ea68f6c6..8302f873ac84b2e26fb21d4cf5ad87f0b763731c 100644
--- a/linux/07_git.md
+++ b/linux/07_git.md
@@ -1,10 +1,105 @@
-## git
---------
-- clone
-- pull
-- add
-- commit
-- push
-- stash
+# git
+------
+## Why you want to know git
+----------------------------------
+Git is a distributed version control system.
+It is a tool used to manage the updating of software code.
+The best way to sell the need for a version control system is to imagine
+working on a programming project without any version control.
+Let's say that the project already exists in some state
+and that now every team member wants to make some improvements.
+Every person would write their own code on their machine,
+and send their updated version of the project code to all other team members
+with zip archives or tarballs.
+Now imagine the process of combining everyone's changes 
+completely manually to form a new version of their project.
+Everyone would have to read every file,
+find all the updates and someone fix the mutually incompatible ones.
+It would be a nightmare. 
+Git is here to automate as much of this process as possible,
+and to help in situations where manual intervention is required.
+Keep in mind that it is not a magical tool that will fix
+incompatible updates - distributed software development
+is inherently complex, and regardless of Git we still have
+to do our best to write clear, readable, extensible code.
+
+The best way to help yourself with distributed software development,
+i.e. when writing code with more people than just yourself,
+is to learn git, and to think about git's version control 
+as you're developing your code.
+And the best way to learn git is to play around with it in an empty repository.
+There will be integration headaches and difficult decisions to make,
+and you can help yourself by knowing how to make them in git in advance.
+
+## most basic usage 
+-------------------
+Refer to man gittutorial, gittutorial-2 and giteveryday for better tutorials - this
+here is the most bare-bones version.
+Also, watch some videos for more complex examples and consult
+google on what to do in your particular situation.
+
+### using an existing repository
+---------------------------------
+The most basic usage is to clone (download) a repository and
+to pull from it (update it).
+- git clone [repo_link]
+- git pull
+
+### making changes
+------------------
+Making changes to a repo involves several steps.
+You start by making the actual changes to the (text) files 
+in the repository. Now you want to update the remote 
+repository so that others can pull these changes.
+You tell git to add the changes by adding changed files or directories (recursive by default).
+You then label these changes by making a commit, which contains a message about these changes.
+You then push (synchronize) the remote repository with this commit.
+- add [files]
+- commit -m "[text explaining the changes]"
+- push 
+If you want to try something out, or have a non-trivial change to make,
+make a new branch (project version), go to it and make them there.
+This way other's can make their changes in their branches
+and you don't step on each others toe in the process.
+- git branch [branch_name]
+- git checkout [branch_name]
+
+### discarding changes
+-----------------------
+- stash 
+- revert
+
+### merging changes
+---------------
+Let's say you're satisfied with what you've done and want to merge it to main.
+You go to main (swith/checkout) and the merge or pull from the branch you've made 
+changes in to main. Rebase if necessary. Read the messages with gives you. 
+See the difs, and the logs. Find the >>>> <<< markings to see whether 
+the merge conflicts are. Solve them, run tests to ensure everything
+works as it should, and commit the changes.
+- git merge
+- git diff or git difftool + git log to see and find issues
+- read specific material for more information to see what
+  will work best for your situation
+
+## additional goodies
+-------------
 - .gitignore
+- using difftool in your preferred ide
+- logging in with ssh keys
 - git-lfs
+
+### resources
+-------------
+- man gittutorial
+- man gittutorial-2
+- man giteveryday
+- man gitworkflows
+- [https://git-scm.com/book/en/v2](online book)
+- [https://education.github.com/git-cheat-sheet-education.pdf](cheet sheat)
+- [https://fileadmin.cs.lth.se/cs/Education/EDAA60/lectures/2024/lecture-git-handout.pdf](lecture on git from cs department (in swedish))
+- [https://fileadmin.cs.lth.se/cs/Education/EDAA60/lectures/2023/EDAF45-lab0-git-basics-v1.1.pdf](lab from cs department)
+- other man-7 pages on git as needed
+- man git
+- man git [command] works for [command]
+- google