From 0759967cd9048d537005111c972d7c9ef0fd7eb6 Mon Sep 17 00:00:00 2001 From: Tobias Manske Date: Tue, 7 Sep 2021 04:15:58 +0200 Subject: [PATCH] Remove abandoned drafts --- content/posts/2021-02-12-pse.md | 53 ----- content/posts/2021-04-14-git-introduction.md | 214 ------------------- 2 files changed, 267 deletions(-) delete mode 100644 content/posts/2021-02-12-pse.md delete mode 100644 content/posts/2021-04-14-git-introduction.md diff --git a/content/posts/2021-02-12-pse.md b/content/posts/2021-02-12-pse.md deleted file mode 100644 index c9e05bb..0000000 --- a/content/posts/2021-02-12-pse.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: "What I've learned: Software Engineering in Practice" -date: 2021-02-12 -cover: - image: /images/writing-the-new-chip-e1522281795259-750x410.jpg -categories: - - studium - - software -tags: - - english - - studium - - software engineering -summary: some sentence about that yo -draft: true ---- - -Part of my computer science bachelors programme is a module called "Software Engineering in Practice". -Students are assigned to teams of 5 by chance and their ratings on the possible topics. -The goal is to go through planning, implementing and testing a small software engineering project in a timeframe just around 4 months. -In the early planning phase a supervisor makes sure, that the teams don't overburden themselves or overestimate the size of their plans. -The result after those 4 months should be a mostly working software project of around 10 thousand lines of code. -At first this sounds like a lot of time, but the timeframe for implementing the project is three to four weeks, shortly before the exams of the semester are due. - -## The project -We rated a project called "Scalable Git-Client" as a good match. The idea behind that was that it's nothing too crazy, and also shall be written in java, with which everyone should be familiar in this programme. -The flaw with that approach, in hindsight, was that *everyone* should be able to do Java, so we were a rather mixed team regarding our prior experience. - -The project was developed as part of the OSL² project. Meaning that the Git-Client we wrote is intended to be used as a teaching aid in the upper classes of high-school. -Scalable is not meant as efficient, but as can be expanded with features. -With that in mind we grouped common git operations into knowledge levels, so students start with a very limitted set of possible git operations, and have more options later on. - -### The Tech -For this project we decided to stay with an old familiar: swing, instead of its cool and new brother Java FX. Knowing the mixed nature of our team this was the right choice in hindsight. -To be able to save settings and other data git doesnt handle for us, we decided to Persist some objects using Jackson. -Finally for our integration with Git we settled on JGit, which we hid behind an layer of abstraction. Let's hope there is a more intuitive library for that in the future. - -Draft-List: -- GitWorkflows - - CLT2015 Valentin Haenel (: - - Alles auf Master ist selbst wenns nur für 2 Tage ist keine option - - -> CODE REVIEW IST NICHT OPTIONAL -- Jackson als JSON Serialisierer/Deserialisierer - - Custom Serialisierung -- Gitlab runners -- Basics JGIT - - merge being hell. -- Teamwork. Wie delegiert man. - - Was macht man mit schwachen Teammitgliedern mit denen man auskommen muss? -- Zeitmanagement: Sehr enge deadline -- Technisches Schreiben (again) -- Open Source Licenses -- Gitlab stuff -- Presenting work which is only partly finished due to time constraints diff --git a/content/posts/2021-04-14-git-introduction.md b/content/posts/2021-04-14-git-introduction.md deleted file mode 100644 index 6519539..0000000 --- a/content/posts/2021-04-14-git-introduction.md +++ /dev/null @@ -1,214 +0,0 @@ ---- -title: A short introduction to Git -date: 2021-04-17T02:04:00+02:00 -categories: - - misc - - git - - software -tags: - - english - - software engineering - - tools -summary: This post will help you to get started with using and understanding git! -showToc: false -draft: true ---- - -Currently, I'm working on my slides for this semester's tutorials for our Software Engineering course. -I aim to give the students a good introduction to git, as it is an integral part of our toolchain. -So I decided to share a first *rough draft* of what one should know here. This post is by far not exhaustive. -I'm probably going to expand on this post in later posts. Also I'll revise this post a few times, in the next days. - ---- - -![The struggles with git](/images/xkcd/1597.png) -
Source: xkcd.com
- -## What is it? - -So, what is Git? The xkcd already implies that git is a collaborative, distributed source control system. -But that is a rather abstract definition. Let's simplify a bit for now: Git tracks changes to your files. - -Essentially Git keeps different versions of your files around, so you can compare them and refer to old versions. -This is really useful, as it makes it hard for you to lose working code, and easy to compare a broken version to a -working one, to find the culprit. - - -## So how do we use it? - -The comic above is not wrong. A lot of git comes down to remembering different commands (or button locations for that matter). -The first thing one needs to do, is to prepare a Repository. A repository encapsulates everything git tracks. So you move to -your project directory and type: - -```bash -$ git init -Initialized empty Git repository in $project_dir/.git -``` - -Git now told you exactly what it did. It prepared a folder for the data it has to track. We now refer to the $project_dir -as the working directory, and $project_dir/.git as the repository. Let's create some files, track some changes and take a -look at how we can interact with them. - -```bash -$ echo "our first change" > file_one.txt -$ git status -On branch master - -No commits yet - -Untracked files: - (use "git add ..." to include in what will be committed) - file_one.txt - -nothing added to commit but untracked files present (use "git add" to track) -``` - -So, we created a new file with the content "our first change". `git status` is used to get information about the current -state of the working directory and repository. It currently tells us, that we have not committed anything at all, and that -there is a untracked file. Let's stage it. Staging means that we tell git to *prepare* that file for a snapshot in its current -version. - -```bash -$ git add file_one.txt -$ git status -On branch master - -No commits yet - -Changes to be committed: - (use "git rm --cached ..." to unstage) - new file: file_one.txt -``` -Git now tells us that there are no unstaged chanes, as well as no commits. And that we have prepared a new file for commit. -So let's create our first commit. A commit basically is a snapshot of our files, frozen in time. We'll not concern ourselves -with the semantics of a good commit for now. - -A commit consists of a list of files, their contents, author information, and a message describing the commit. - -```diff -$ git commit -m "This is our first commit" -$ git show -commit cf0475067740275c6469836ff743855fcf4e4f85 (HEAD -> master) -Author: Tobias Manske -Date: Wed Apr 14 19:37:00 2021 +0200 - - This is our first commit - -diff --git a/file_one.txt b/file_one.txt -new file mode 100644 -index 0000000..103f365 ---- /dev/null -+++ b/file_one.txt -@@ -0,0 +1 @@ -+our first change -``` - -`git show` shows us what our last commit did. In my case it is filled in with my email and my name for author information. -The commit has the id cf04... and is currently the commit the master branch points to (more on that later). -In the bottom part we see a so called diff of the state before the commit and the new state. We can obtain more information -about the history with the `git log` command. Without further options it just prints the top part of `git show` for every -commit in the history. Before we can explore that further, we need some more changes. I'll not go into detail here. Just -repeat what we did before. Change stuff, add it to git and commit it. - - -```diff -$ git log -commit 1849c7644425684cea7039e825168d92df4e6936 -Author: Tobias Manske -Date: Wed Apr 14 19:57:38 2021 +0200 - - remove a file - -commit 4db54105f028d23339bbd1eb51fb397ab0d45719 -Author: Tobias Manske -Date: Wed Apr 14 19:57:23 2021 +0200 - - Changes some more stuff - -commit cf0475067740275c6469836ff743855fcf4e4f85 -Author: Tobias Manske -Date: Wed Apr 14 19:37:00 2021 +0200 - - This is our first commit -``` - -As we can see, this is our history. It can be rather cumbersome to look at it this way, let's use an argument to make -it easier to digest: - -```bash -$ git log --oneline -1849c76 remove a file -4db5410 Changes some more stuff -cf04750 This is our first commit -``` - -This is a lot more concise, but lacks quite a lot of information. I have a shorthand `git lg` in -[my configuration](https://git.tobiasmanske.de/user/rad4day/public/dotfiles/tree/.gitconfig) -which would show the following: - -```bash -$ git lg -* 1849c76 - (4 minutes ago) remove a file - Tobias Manske (HEAD -> master) -* 4db5410 - (4 minutes ago) Changes some more stuff - Tobias Manske -* cf04750 - (25 minutes ago) This is our first commit - Tobias Manske -``` - -The left most column is a abbreviation of the commit hash (that long number we've seen before) that git uses to identify -and distinguish commits. The length of the abbreviation will adjust if git ever needs more symbols to distinguish two commits. - -## Looks complicated, can you explain this again? - -I will! With a graphic. Below you can see what happened step-by-step, when we committed. - -![How commits changed our graph](/images/git-graph.png) - -You can see 4 columns, which are the 4 states our repository was in; every commit changes the state from left to right. -In the beginning we had no commits, then we created our first commit and git placed the HEAD-Pointer at it (more on that later). - -Each new commit has a parent-pointer to its ancestor and is now the location of our HEAD. This pattern continues till we made -our last commit. - -## So how do I access my data? - -Until now, we just stored data into git. That's nice to know, but how could we recover code we deleted later on? - -For example: How do we get back our initial version of file_one.txt, how do we look at it? How can we replace our current -version with it? - -There are multiple ways to achieve this. If we just wanted to restore the version of file_one.txt of the last commit, we could use - -```bash -$ git checkout HEAD~ -- file_one.txt -# or: (~ is a postfix meaning ancestor of) -$ git checkout 4db5410 -- file_one.txt -``` - -Which would restore the older version, thereby overwriting our local version. If we just needed that one line we accidentally deleted, we could also extract that from a diff. - -```bash -$ git diff HEAD~ # This will print the diff for all changed files -$ git diff HEAD~ -- file_one.txt # This will only print changes to file_one.txt -``` - -## Branches - -The last thing I want to introduce today, are branches. Branches make it possible to have multiple parallel change histories. -For example one branch could contain a feature you're working on, which is still to be completed, while another one could contain an important bugfix you had to write while developing that feature. - -One may wonder at this point, why we'd not just do all that on master, or at least on a single branch. We'll go into more detail about that when we talk about workflows. - -The basic workflow we'll think about right now is the following: - -1. Have idea for a new feature -2. Create a new feature branch -3. Develop feature on feature-branch -4. Merge feature-branch into master - -We'll leave point one and three as an exercise to the reader, and just work with hypothetical commits. -So first we create our branch: -```bash -$ git checkout -b feature-foobar -# if feature-foobar does not exist it will be created. -``` - -If you now type `git status` it will tell you that you're now working on `feature-foobar`