git An Introduction Prevent this: What is git?? A version control - - PowerPoint PPT Presentation

git – An Introduction

Prevent this:

What is git??

• A version control system for tracking changes in

(text) files in git repositories.

• Note, that the files do not necessarily have to

be any "source code" files, but text files.

• This does not include *.doc and *.docx files!

Getting started

• A repository is any directory on your or any
• ther machine, of which we told git about.

Some terms

• In git, changes on a file can reside in three

areas:

– Local working directory with the files in it on which

we work. Just as usual as it gets.

– The index. A staging area where the state of the file

is tracked, but not saved persistently.

– The HEAD. A pointer to the last commit.

Some terms

• A commit is basically a persistently saved state

(snapshot) of the repository.

• Basically, what we do when using git, is moving

files around in the three mentioned areas.

• However GitHub Desktop (kind of) skips the

add command.

The Workflow

• Create or edit a file.
• Add+commit it to the repository.
• As long as a new file has not been added to the

repository, git does not care about it.

• As soon as it's in the repo, we can see changes

made.

• Only committed changes are saved persistently

and can be undone!

Logs and Reverts

• Create or edit a file.
• Add+commit it to the repository.
• As long as a new file has not been added to the

repository, git does not care about it.

• As soon as it's in the repo, we can see changes

made.

• Only committed changes are saved persistently

and can be undone!

Remote repositories

• git natively supports synchronization between

repositories.

• Non-local repositories are simply called

remotes or remote repositories.

• Most common way of setting up a remote, is by

cloning a remote repository:

– This automatically registers the remote repository

as such.

Remote repositories

• Synchronization does not happen

automatically!

• Instead we push & pull our changes!

Remote repositories

GitLab-Server User 2 User 1 User 3 push pull

• We stay in sync by keeping one central

repository up-to-date and fetching changes from there!

Merge conflicts

• Can we get out of sync?
• Obviously and unfortunately yes!
• git is quite powerful merging changes in the

same file!

– Changing different lines in the same file, does

normally not yield any problems.

• Changing the same line, does. What change is

to be preferred?

– Needs manual resolution!

Merge conflicts

• Also, binary files do not follow the concept of

lines

• Hence, binary files cannot be merged!
• *.doc, *docx, *.xls, etc. are binary formats, not

text files! They are a bad choice for usage with git.

–

(Instead try using LaTex, which is text-file based)

Merge conflicts

• Also, binary files do not follow the concept of

lines

• Hence, binary files cannot be merged!
• *.doc, *docx, *.xls, *.pdf, *.png, *.jpg, compiled

executables (*.exe), etc. are binary formats, not text files! They are a bad choice for usage with git.

–

(Instead you may try using LaTex, which is text-file based)

Let's create a merge conflict!

Extended Workflow

• Edit files and regulary add+commit your

changes, best logically separated.

• Before e.g. leaving work/doing something else,

push your changes!

• If it fails, you might have to pull changes first

and possibly resolve some merge conflicts.

– Hence, don't push in a hurry! Better push early and

have time for resolving conflicts.

• When done, push the resolved merge!

.gitignore

• As said before, some files are unsuitable for

being handled with git. We can tell git to ignore files by adding them to the .gitignore

• We can ignore single files, file patterns and

directories

• If some files are anyhow needed in the

repository, try to create them automatically!

– E.g. LaTex compilation scripts (and exclude the

compiled PDF), gnuplot or matplotlib scripts

Branches

• Assume you want to perform major changes,

add a new feature, which may temporarily compromise functionality.

– Adding such changes to the master (or production)

branch, will cause all other users to be confronted with defect software.

• Branches allow for isolated development

regions, where you can basically do, whatever you want!

• Later, you can merge your changes into the

master branch.

Best Practices

• (Try to) Never push non-working code!

– Ideally, a git repository's master branch is always

ready to work out of the box!

– If you know beforehand, that stuff won't work, use

your own branch!

– Document your work, label non-working features!

Best Practices

• Don't develop in your production environment!

– Regarding e.g. large data simulations: You perform

simulations/calculations on powerful servers. You should however not develop on those servers.

– Instead develop your programs on your local

• machine. Use small test examples to check
• functionality. Even better, use unit testing!

Best Practices

• Don't develop in your production environment!

– Why not? – Having your code working on two different

machines assures at least some portability and reproducibility of your code!

– This will most probably also force you to add setup

and installation scripts (like creating python venvs, installing modules, etc.)

– This will also hinder you from hard-coding paths in

your code!

Best Practices

• Try not to hard-code!

– Hard-coding means writing e.g. authentication

parameters, data paths, etc. directly into the code.

– Instead, use config-files, which hold information and

are read on program start.

Best Practices

• Documentation

– Information on how to install/setup your software

should be delivered with the repository.

– The README.md file is the perfect place for such

information!

Best Practices

• Don't hack!

– Mostly, there exist good, durable, elegant, but

somewhat tedious solutions and on the other hand quick, but dirty solutions.

– Always (try to) go for the good and durable one! – Even for small projects, you never know, when you

come to the point, where you need to extend functionality.

– Undoing the hack + implementing a robust

solution does cost more time, than having it done correct from the beginning!

Best Practices

• Don't hack!

– Following standard procedures also enhances the

chances of getting help from colleagues or the web!

– However, it might be quite hard, to know what is the

„best“ solution to a (possibly very individual) problem...