From 1f4186afe9c87344d6bde04d2aa4b2c100e9473f Mon Sep 17 00:00:00 2001 From: m-guberina <gubi.guberina@gmail.com> Date: Thu, 24 Oct 2024 17:46:08 +0200 Subject: [PATCH] added git tutorial --- linux/07_bonus_git.md | 3 -- linux/07_git.md | 111 +++++++++++++++++++++++++++++++++++++++--- 2 files changed, 103 insertions(+), 11 deletions(-) delete mode 100644 linux/07_bonus_git.md diff --git a/linux/07_bonus_git.md b/linux/07_bonus_git.md deleted file mode 100644 index b2653f2..0000000 --- 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 c03381a..8302f87 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 -- GitLab