Wprowadzenie do GIT – Piotr Szpetkowski

Ta prezentacja jest częścią cotygodniowych tech talków w Sunscrapers. Prezentacja stanowi ogólny przegląd GITa i jego podstawowych funkcjonalności. Jeżeli chcesz zacząć pracować z tym systemem kontroli wersji, obejrzyj nasz filmik!

Czy prezentacja była dla was przydatna? Dajcie znać!

Nature of Computer Program – Paweł Święcki tech talk

This presentation is a part of our weekly talks. This talk is about relation of computer program to physical world and to human mind. Are programs purely physical? Or maybe they are only in our heads?
Watch the video to find out and let us know what you think!

Slides are available here: Nature of Computer Program

Weekly Tech Talks: Fundamental Introduction to Git

This presentation is a brief introduction to Git distributed version control system (DVCS). We will start from configuring the Git CLI and then we discuss how Git works and what are its frequently used features.

Git is called Distributed Version Control System, which means that in contrast to the Centralized Version Control Systems (CVCS), each user receives a complete copy of the repository. Every customer can also, if necessary, act as a server, and if the server has a breakdown, it is possible to restore it without any problems, using the client’s copy. The good side effect of such architecture is that the majority of operations in Git is based on local resources. This way, operations are made faster and are not dependent on the server, from which we obtained a repository. This also allows us to work without an active connection to network – offline.

Configuration of GIT CLI

GUI tools to handle Git, despite their friendly interface and ease of use, are useful only in simple cases and they are not always helping us to solve a problem – sometimes they may even hinder solving it. For this reason, you should be familiar with the CLI.

There is a very useful command if you don’t have an internet connection and you’ve forgotten something important: git help. It accepts Git’s command as a parameter, for example: git help init. When used without a parameter, it displays a list of the most frequently used Git commands.

The basic configuration of Git’s CLI consists of setting a few variables. The easiest way to do this is through git config command, which allows to both read and modify variables. Essentially git has three config ‘levels’ you can use – system, user and repository, but most of us stick to the user (global) configuration level.

It’s good to give at last your username (usually your name and surname) and e-mail address, to use Git properly:

$ git config --global user.name "John Doe"

$ git config --global user.email "john@example.net"

--global flag means that we use a global (user) configuration file.

Three files’ spaces

In Git there are three areas where files can be found at a given moment:

  1. Working directory – a place of work where we make changes to files
  2. Staging area – files which changes have been accepted and which are ready to add to be committed into repository
  3. Git directory – the place where Git stores the metadata of the project and files that have been accepted to the repository (committed)

Usually the workflow in the Git’s ecosystem looks like this:

  • adding / modifying / removing files,
  • confirming desired changes to the staging area,
  • (optional) performing more operations on files,
  • after making sure that all desired changes are in staging, committing them to the repository with an adequate description of modifications.

Files management in Git

We can create a new, empty repository (which is often the first step when starting a new project) using git init command.

$ git init

We can also get a copy of an existing repository via git clone command.

$ git clone https://example.net/user/repo.git (using https protocol)

$ git clone git@example.net:user/repo.git (using ssh protocol)

One of the basic commands is git status, which is used to check the files’ status.


$ git status

On branch master nothing to commit, working tree clean

With git add command, we can add a file or files to staging.

$ git add README.md – adds README.md file to staging

$ git add. – adds all files in the current directory to staging

$ git add ’* .py’– adds all files with the extension .py to staging

$ git add -A – adds all files from the working directory to staging

To delete a particular file or files from staging, we can use the command

git rm --cached .

$ git add README.md

$ git rm --cached README.md

rm README.md '

If we skip --cached flag, then file is also deleted from the working directory.

We can delete all files from the staging using:

$ git rm -r --cached .

Four states of file

At any given time, each file may be in one of four states:

  • Untracked – file exists only in the working directory
  • Unmodified – file is in the repository and is the same as one in the repository version
  • Modified – file is in the repository and has been modified in the working directory
  • Staged – file has been added to the staging area and is awaiting approval to the repository

Ignoring files

Sometimes we don’t want Git to add some files to the repository (e.g. for security reasons). We can create a file .gitignore that contains a list of filenames’ patterns and directories we wish to ignore.

$ cat .gitignore

# python

__pycache __ /

* .py [Cod]

Preview of file changes

You can use the git diff if you need to check what changes have occurred in files in the workspace. It takes an optional parameter --cached to compare with staging. Keep in mind that git diff doesn’t compare untracked files.

$ echo "test"> README.md

$ git add README.md

$ git diff --cached

+++ B / README.md

@@ @@ -0,0 +1

+ test123

Approving changes

Changes set out in staging may be committed to the repository by git commit, which requires determining a description of changes – commit message. We can select a text editor, which Git will use through the environment variable $EDITOR. You can also override the default value before executing the command:

$ EDITOR=vim git commit

git commit also allows to enter the commit message as a parameter to the command:

$ git commit -m "Add README.md"

It is also possible to completely omit the staging step by using a shortcut:

$ git commit -a -m "Add README.md"

Note that the parameter -a takes into account only those files that are already tracked.

We can also overwrite the last commit to correct it or add more changes by using --amend flag:

$ git commit -m "Add README.md"

$ git add README.md --amend

$ git commit -m "Add README.md"

Undoing changes

You can also undo the staged changes by using the git checkout command if you have modified a file, which is already being tracked by Git in the working directory.

$ git checkout -- README.md

If in doubt, git status reminds the syntax if it detects changes.

(Use "git checkout -- ..." to discard changes in working directory)

History check

With at least one commit, we can see the history of the repository through git log.

$ git log

commit 900d87e0d958ad186d9266e1e469d7e23ab8bbf9

author: John Doe <john@example.net>

date: Thu Dec 8 2016 0100 4:39:31 p.m.

    Add README.md

Shortly about branches

Branch in Git repository is a separated part with its own commits history.

To see a list of branches in the repository, we can use the git branch command.

$ git branch

* master

An asterisk next to the branch name means that it is currently active.

To create a new branch we use the same command with the name of the branch as a parameter.

$ git branch example-branch

We can switch between different branches using git checkout.

$ git checkout example-branch

Switched to a new branch 'example-branch'

It is also possible to use a shortcut to create a new branch and immediately activate it.

$ git checkout -b unicorn-branch

Switched to a new branch 'unicorn-branch'

To copy changes from one branch to the other, we can use merge or rebase command. The most obvious difference between them is that merge creates merge commit every time except when fast forward is being used. It may add some unwanted noise into the branch. That’s why in case of a need to copy changes from master to other branch it’s a good idea to use git rebase.

$ git merge example-branch

$ git rebase unicorn-branch

To remove unnecessary branches use a git branch command again.

$ git branch -d example-branch

Deleted branch example-branch (you 900d87e).

If the branch has not passed through merge or rebase we can still remove it.

$ git branch -D some-branch

>Deleted branch example-branch (you e873b87).

Remote work

Using git remote command we can see currently configured servers. Additional -v parameter displays URL assigned to the shortcut.

$ git remote -v

origin git@example.net: user/repo.git (fetch)

origin git@example.net: user/repo.git (push)

If we want to send our commits to the world and we have created a repository using git init command, we have to add remote repositories.

$ git remote add origin git@example.net:user/repo.git (ssh)

We can also give remote repositories different shortcuts (not only origin)

$ git remote add backup git@example.net:user / repo.git (ssh)

Finally, to send your changes to the remote repository use git push command.

$ git push origin master

To download other people’s changes or changes on other device we use git pull.

$ git pull

To be continued… 🙂

* Piotrek Szpetkowski, our Junior Backend Engineer, prepared this presentation. Thanks Piotr!

Our work culture: supporting the Python community

What do we love Python for?

Python is the most rapidly growing programming language – it has a huge impact on web development, scientific computing and education. Why so many companies and developers choose Python?

There are three main reasons. First of all, Python is developed under an open source license. Secondly, Python community is open and mature – there are numerous initiatives like conferences, meetups and coding sprints. Finally, Python foundations are easy to learn for beginners.

Why do we support the Python community?

Our commercial activity is based on Python and we benefit from contributions of the whole Python community e.g. we use open source libraries in the projects we do for our clients. Python, in a sense, enables our company to exist and realize its business goals. That’s why we look for opportunities of supporting and giving back to its community.

What do we do and how?

First of all, we encourage people to start using Python by organizing events that popularize that language. We’ve started by organizing PyWaw – monthly developers’ meetup in Warsaw. There was already more than 50 meetups and over 130 talks. We then took it to the next level by co-organising and volunteering at some of the splendid conferences like PyWaw Summit, DjangoCon, Makerland. We’ve also sponsored or mentored at Django Girls and Django Carrots workshops – a series of events that help beginners make their first steps in Python.

Secondly, we share insights and knowledge that have helped us become successful developers. One way of doing that is through weekly tech talks. Once a week our team gathers in a conference room to participate in a presentation prepared by one of us. The topic of the speech concerns either technology or soft skills. We record those talks and publish them on our YouTube channel so that other people interested in IT can access them. We’ve explained the whole idea in a separate post: Our work culture: weekly tech talks. Another way of sharing knowledge is speaking at industry events – you can find some of those talks on our YouTube channel as well.

Last by not least, we contribute to open source ourselves with djoser and djet being our most popular libraries.

The effects of our activities

We’re glad that over the years we’ve managed to inspire a lot of people to start programming and choose Python as their first language. Our activities seem to have helped a lot of people in making major career choices and we have also noticed how PyWaw, over the years, has contributed to building a solid tech scene in Warsaw. It is very rewarding for us to see such effects and it definitely fuels our future plans.

Let’s talk about our plans

We now plan to organize a second edition of PyWaw Summit in 2017 (read more about the last one!). We’re also considering evolving our weekly presentation routine into a new initiative called #ToTheSun. In addition to a tech presentation we would watch other lectures and have group discussions. We’re planning on inviting all other Python enthusiasts from Warsaw, not only our Sunscrapers teammates. After an educational part there would be time for informal conversations with beer and a foosball!


Scroll through the photo gallery below to see where we took part as organizers, mentors, speakers and participants.