DEV Community: Can Cellek

Dev Cheats - Interactive Cheatsheets For Developers

Can Cellek — Sun, 19 Feb 2023 18:23:41 +0000

Greetings, fellow developers!

I just started working on a community-driven project called Dev Cheats. It is aimed at providing developers of all skill levels with a convenient reference for various command line tools and their usage examples.

Currently only a few cheats are on the database, but if you think you can provide any documentation I would love to receive pull requests!

Please feel free to check out the demo at dev-cheats.vercel.app where you can search for git and see the current implementation for Git commands and usage examples. Additionally, the API directs to the documentation page, making it easy to bookmark pages through an URL like dev-cheats.vercel.app/git

You can find the repository at github.com/excalith/dev-cheats and have a look at contributing guideline.

Cheers!

Terminal Inspired, Clean and Customizable Browser Start Page

Can Cellek — Tue, 14 Feb 2023 08:32:54 +0000

For a long time I wanted to create my own start page looking like my terminal, so here it is! It includes my common bookmarks where I can search through them with my terminal-inspired prompt.

There are multiple ways to customize it, so be sure to check out the repository and wiki page page for customization options.

Demo

You can check the working version from here
You can pull the Docker image from here

Features

Quickly filter links by typing in the prompt. Hitting Enter will open all filtered links at once
If nothing filtered, the text in prompt will use the default search engine for searching your input
Launch websites directly from the prompt. Just type the URL (ie. github.com)
Search websites with custom commands. For example, type s some weird bug to search StackOverflow for some weird bug
Multiple ways to customize the start page to your liking

Built-In Commands

Show usage with help command (shows basic usage and your configured search shortcuts)
Show info with fetch command (time, date, system and browser data)
Update your configuration with config command
- config import <url> - Import configuration from a URL to your local storage
- config edit - Edit local configuration within editor
- config reset - Reset your configuration to default

Key Bindings

Clear the prompt quickly with CTRL + C
Close window with ESC

Customization

There are multiple ways of customizing the start page to making it yours!

Use config edit to edit your configuration within the start page code editor
Use config import <url> to import configuration from a URL
Change the default configuration in startpage.config.js file and deploy your own version

Please refer to wiki page for more information.

My .dotfiles for MacOS and Ubuntu

Can Cellek — Tue, 14 Feb 2023 08:14:00 +0000

I finally revamped my .dotfiles! It includes my MacOS and Ubuntu configurations. I am planning to add Alpine configuration for my iPad, and Arch configuration for my geeky needs.

Features

Fully customizable installation depending on OS
The installer script is seperated from configs and install scripts
A dotfiles manager for post-install maintenance
Has post-install scripts for configuring git, ssh and gpg
Requires git commands for syncing without fancy dotfile managers

Uses

Supports bash, zsh and fish with starship shell prompt and has tmux support
Replaces default terminal with Alacritty and kitty
Does not use any WM (on MacOS, only yabai and skhd used on top of the default DE)

Repository

You can find my dotfiles here:
https://github.com/excalith/.dotfiles/

The dotfiles setup scripts are heavily ~~knocked-off~~ inspired version of beautiful Cătălin’s dotfiles. You should probably check it out!

Git Cheat Sheet

Can Cellek — Mon, 06 Feb 2023 18:09:51 +0000

Hello there!
Here I would like to share my most commonly used git commands and a few aliases to keep your console simple and beautiful by formatting.

EDIT:
I have started a new project for common cli tool cheatsheets. You can find git cheatsheets there!
App: https://dev-cheats.vercel.app
Article: https://dev.to/excalith/dev-cheats-5b3o

Create

# Create a new local repository
git init

# Clone an existing repository
git clone ssh://user@domain.com/repo.git

Check Changes

# Check all changes
git fetch

# Check status
git status

# Changes to tracked files
git diff

# Log
git log --oneline

# Diff
git log --stat

# Shortlog
git shortlog

# Graphs
git log --graph --oneline --decorate

# Show Log By Author
git log --author="John"
git log --author="John\|Mary"

Stash

# Add To Stash
git stash

# Show Stash List
git stash show

# Pop Stash
git stash pop

# Apply Spesific Stash
git stash apply stash@{index}

# Drop Spesific Stash
git stash drop stash@{index}

Stage & Commit

# Add all changes to next commit
git add .

# Add file changes to next commit
git add

# Commit staged changes
git commit -m "Commit Message"

# Change the last commit
git commit --ammend

# Change the last commit name
git commit --amend -m "New commit message"

Branches & Tags

# List all existing branches
git branch -av

# Switch HEAD branch
git checkout

# Checkout to a remote branch
git checkout --track origin/branch-name

# Create branch
git branch

# Delete local branch
git branch -D

# Delete origin branch
git branch -dr origin/branch

# Tag current commit
git tag

Update & Publish

# Download all changes
git pull

# Upload all changes
git push

# Publish tags
git push --tags

Merge & Rebase

# Merge into current HEAD
git merge

# Rebase your current HEAD (Don't rebase on public branches!)
git rebase

# Abort rebase
git rebase --abort

# Continue rebase
git rebase --continue

# Use your configured merge tool for conflicts
git mergetool

# After solving conflicts mark as resolved
git add
git rm

UNDO

#Discard all tracked changes
git checkout .

#Discard all local changes on working directory
git reset --hard HEAD

#Discard all local changes in file
git checkout HEAD

#Reset HEAD pointer into a previous commit
git reset --hard

Advanced Stuff

# Local Garbage Collection

# finds and removes all references of unused commits in reflog
git reflog expire --expire="1 hour" --all

# finds remove all references of unreachable commits in reflog
git reflog expire --expire-unreachable="1 hour" --all

# prune all unreachable objects from database
git prune --expire="1 hour" -v

# clean-up all unnecessary files and optimize the local repo
git gc --aggressive --prune="1 hour"

# count latest objects
count-objects -vH

# Delete Old History (link: https://stackoverflow.com/a/41953383)
# checkout to the status of the git repo at commit f; creating a branch named "temp"
git checkout --orphan temp

# create a new commit that is to be the new root commit
git commit -m "new root commit"

# now rebase the part of history from  to master on the temp branch
git rebase --onto temp  master

# we don't need the temp branch anymore
git branch -D temp

# this is a destructive operation
git push -f

# Check LFS
git lfs ls-files # It will show all tracked files.
git lfs push origin master --all # Push any missing files
git count-objects -vH # Check the real size of the repository.

# Editing Global Config File
git config --global -e

# Setting An Editor For Config File
[core]
    editor = 'Path/To/Your/Editor.exe'

Git Alias

# Shortcut Git Status: Use 'git st' to show git status -sb
git config --global alias.st "status -sb"

# Formatting Git Log: Use 'git ls' to show log with colored format
git config --global alias.ls "log -n 15 --pretty=format:'%C(Yellow) %h %Cred%ad %Cblue%an %Creset%s%Cgreen%d' --date=short --all"

# Formatting Git Graph: Use 'git graph' to show log with colored format
git config --global alias.graph "log -n 25 --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all"

# Show only modified and deleted files including your extension

# instead of ls-cs and *.cs, write your own extension
git config --global alias.ls-cs "ls-files -zmd *.cs"

# Ignoring Files Locally
# use 'git ignore filePath' to ignore a file locally
git config --global alias.ignore "update-index --assume-unchanged"

# use 'git unignore filePath' to unignore a file locally
git config --global alias.unignore "update-index --no-assume-unchanged"

# use 'git ignored' to see your ignored files
git config --global alias.ignored "!git ls-files -v | grep "^[[:lower:]]""

Git 103 - How To Collaborate

Can Cellek — Mon, 06 Feb 2023 18:09:10 +0000

This git fundamentals post will help you to understand how to collaborate using git with your colleagues. Considering you already know Kickstart Your Repo and Working On A Repo, now we can dig further using git effectively with other collaborators. Note that this won't include an open-source project approach. Even the principle is the same, some of the projects have different requirements for pull requests. You can further investigate how to create pull requests for this. First of all, I would like to stress what a development process would be like without source control. A friendly piece of advice: if you think it is hard to work with git, think twice. It might take a while to understand and get used to working on git, but it is worths your time.

Without source control, the major problems are those:

To work together, you should set up a NAS, cloud, or use something like a USB to share your work with your colleagues.
It would be impossible to work on the same code at the same time. If not careful, you can override your friend's work with your save. If you are careful, you should check the conflicts by hand.
You can't check the progress of your colleagues and create test builds using only the features you want to test out

The list above is the common problems, and imagine you can hit much more roadblocks in the development process.

The Theory

Before diving further, we should talk about some theories first. To work effectively you and your collaborators should know the theory behind Git. To keep it simple, we will focus on 2 developers: Back-End and Front-End. Consider your repository as a station at the beginning of a road and each developer is at the same station. Since they are working on different stuff, they should take different paths from that station. When Front-End finishes his work, he puts his work into the road, as a new station. The same applies to Back-End developers as well. This time, when the Back-End developer puts her work into the road, it is automatically put after the Front-End station. Now that the road contains 2 developers' work, when they start a new path they will both have those stations combined. To illustrate this in a graph

                   *  Road 3 (All Back-End Merged)
                 / | 
Back-End Work 3 *  *  Road 2 (All Front-End Merged)
                |  | \
Back-End Work 2 *  |  * Front-End Work 2
                |  |  |
Back-End Work 1 *  |  * Front-End Work 1
                 \ | /
                   * Road 1 (Base)

As you can see above, Road now includes all work done! Whenever someone creates a new path from Road 3, they will all have the work done so far, allowing everyone to keep up. All those roads and paths are called branches. Branching is one of the most important things you should learn while collaborating. There are different branching approaches around, you should find or create one that best suits your workflow. You can check GitFlow, an extension for making branching easily. But we will focus on our simple branching model, close to GitFlow rules.

Branches

Here, we have our basic branching rules every colleague should use:

Main Branch: Master branch will be your release branch. Everything merged to here should have passed QA tests.
Develop Branch: Everything worked on should be merged into develop. When the time comes, QA should test from the latest commit's build. When everything is in order, develop merges into master for release.
Feature Branches: Feature branches are the branches you will spend time on mostly. Since branches can be nested, if you create a branch feature/MyBranch it will be created under feature, just like a folder. Those features can be merged into develop branch.

When you create a repository, there will be a master branch by default. When you clone the repo for the first time (considering you didn't directly checked-out to a different branch) you will also be checked out to the master branch. You can use that branch to push your initial commit including your .gitignore and readme files. Then, time to create your first branch:

git branch develop
git checkout develop

This will create develop branch and check out to it. This branch includes everything committed to the master branch at the time you checked out. You can also create and check-out to a branch with a single command: 'git branch -b develop'. Now everything seems to be set up. but you need to push your branch to the server to let your colleagues access it.

git commit -m "Initial Develop Branch"
git push

You will realize there is an error telling you that develop branch does not exist on the server, and it shows a code instead to set upstream. You can copy-paste that code to push it to remote. Once you have pushed develop into remote, you can only use push command instead. Now it is time for your colleagues to checkout to remote develop to create their branches.

git checkout --track origin/develop

This code pulls the develop branch and tracks it. Basically tracking is saying "this branch on my local is that branch on remote" in a short way.

Working on a feature branch

This section is a general approach for all your collaborators. It is time to create your branch to move on

git branch -b feature/MyFeatureBranch

Now you have your feature branch to work on. When you have created files, you are ready to commit. Don't forget, committing is also useful when you want to revert your changes until you push to remote. Here is the code to do so:

git add * # Adds all files. You can add files one by one by giving file path
git commit -m "Lovely Message" # Write something simple yet self-explanatory

You can continue committing your changes whenever you feel right. You can also push your code to remote. First, check if you have anything left to be committed and be sure you are on the correct branch.

git status

With that command, you can see untracked files as well. If you need to commit files, you can do so. Otherwise, no necessary files have changed, you can set them to their first state.

# Reset all tracked files to their latest state
git checkout .

# Remove all untracked files
git clean -n # Shows all untracked files
git clean -f # Remove all untracked  files if not necessary

You can also stash files to get back to them, but to keep it simple I am not going to explain it. You can further investigate how to use stash commands from Git SCM. Now that your branch is clean, you can either push it to remote or merge directly into develop. If you are working on a branch that should take time, you can push it to remote a prototype version, so that other colleagues can merge it to their branches to keep adding their code. If you want to keep going on that branch, you can use

git push

If you haven't pushed remote before, you will see that upstream error meaning there is no such branch on the remote. Simply use the given code and push it to remote. Now that you can continue committing changes into your local as long as it takes. If you want to finish this feature for good, then without pushing you can directly merge it into develop branch. To do so, you should checkout to develop branch.

git checkout develop # Checks out the develop branch
git fetch # Looks for any changes for develop branch on remote
git status # Check if you are behind the remote develop
git pull # If you are behind, pull the latest changes

Now that you have the latest develop branch, you can merge your branch into develop and push it. Be sure that you are still on develop branch!

git merge feature/MyFeatureBranch
git push

If there is no conflict between your changes and develop's changes, it should directly merge. Otherwise, the console will give you a conflict error where you should edit conflicts. There are lots of different GUI merge tools to help you out there! I am using VSCode's internal merge layout but you can use other apps such as Meld on Windows, Kaleidoscope on macOS. You can also use GUI Git Clients such as Fork, SourceTree, and GitKraken, where they have conflict resolving GUI as well. Decide on an app, and learn their approach how they resolve conflicts. They have your code and the code on branch side-by-side. You can see who deleted what and added where, so you can add yours into the final one. This final one will be the resolved file.

Summary

You are asking where is the collaboration part, right? Well, above is the general workflow working on branches. But consider this, if everyone minds the rules above, they should do the very same thing on different branches, just like you did above! So, to sum it up:

Create a branching rule. One of the most common approaches is master, develop, and feature branches. Be sure to know what merges into where.
Don't commit unnecessary changes. Commit often, when necessary.
Check your status before committing and pushing.
Use clear commit messages, your colleagues need to understand what you did from those messages.
Don't leave your HEAD with uncommitted changes, if you try to checkout you may conflict with existing ones. You can stash them, or revert them if unnecessary.
Whenever you checkout to a branch used by multiple collaborators, always fetch and see if you are behind the remote branch.
Solve conflicts and test them. If you are using Pull-Requests for merging into master, ask the pull-request sender to fix conflicts.

Git 102 - Working On A Repo

Can Cellek — Mon, 06 Feb 2023 18:07:37 +0000

Since you have already have a basic knowledge of what is Git and a few tools and providers to start with, it is time to get on with working on your repository.

Creating A Repository

To work on git, you have to create a repository first. Depending on your choice, GitHub, Bitbucket, GitLab, etc. creating a repository may differ, but the main principles are the same. For instance, for GitHub and Bitbucket interface you can click the plus icon and select "New Repository". When the page loads;

Choose a repository name (will be called MyRepo from now on)
Set the repo visibility either private or public (depending on your provider, private repositories may not be free)
Click Create Repository

Now you have a repository to work with!

I Got The Repo!

Now it is time to clone your repository MyRepo from remote to your local. To do that, you have to find the "link" to that repository. Beware: if you have SSH keys already set up, you can use the SSH version. Otherwise, if you have no idea how to do it, you can use HTTPS. It is pretty unsecure compared to SSH, but for this tutorial series, we are only getting into basics.

SSH Example: git@github.com:YourUserName/MyRepo.git
HTTPS Example: https://github.com/YourUserName/MyRepo.git

Now time to get those links:

GitHub: Click the green button "Clone or Download" and copy the link below
Bitbucket: Copy the link on the overview page
GitLab: On the Project page, copy the link

A Clone Of My Own...

Time to clone your repository! Since GUI clients have their tutorials, I will explain the CLI version using terminals instead. Don't worry, even if they are commands they are the common terminology and I will explain them step by step. So, I recommend you to read them to have a better understanding of what GUI clients do in the background. Here we go! First, find a place for your git projects. Find somewhere cozy, easy to reach, and without funky characters in the path. Change your directory to your Git folder

cd Git

Clone your repo into your Git folder. Don't worry, it will create the repo's folder inside. It will ask for your password since it already knows that you are trying to clone your repo.

git clone https://github.com/YourUserName/MyRepo.git

Now you should see a folder called MyRepo inside your Git folder. If you have enabled to view hidden folders by default, you should see a .git folder. This folder encapsulates lots of information related to your repository. Simply put, this is the bridge between your local repo and remote repo.

First Of All...

You have a repository where you can share everything with collaborators. I mean, literally everything within your repository folder. Consider yourself struggling to find files to share within temp files, test codes, etc... Git has a solution for that! With an ignore file, you can simply filter out anything you do not want to share. Depending on your project, ignoring files can differ. You can already find a collection of .gitignore file examples for different projects on GitHub which you should download and use on your repository root (within MyRepo folder). You can also add your filters to it by opening the .gitignore file with your favorite code editor.

A Real Commitment

Since you have changed something, we can talk about git in depth. Git "stalks" all your files. Even if you change a string, git knows it. To see what your git stalked, use

> git status
On branch master

Initial commit
Untracked files:
    (use "git add <file>..." to include in what will be committed)

    .gitignore

nothing added to commit but untracked files present (use "git add" to track)

git add .gitignore

Now you have added your first file, it is also tracked by git, and ready to be committed. If you check your status by 'git status' again, you will see something different now:

> git status
On branch master

Initial commit

Changes to be committed:
    (use "git rm --cached <file>..." to unstage)

    new file:   .gitignore

This means you have tracked the .gitignore file and git recognizes it as staged. If you hear "stage your files", it means to add your files. You can add as many files as you can into a staging area. With this, you can share all your project or only a modified file with a single commit. We will get into this now. Now that you have added a file to the staging area, it is time to commit. Commit is simply put your staged files are done and ready to be published. To do so;

git commit -m ".gitignore added"

The command above saves all changes into a commit, so you can share it. The -m is short for --message and the string in between quotation marks are your messages, to be read by other collaborators to see what you are up to without checking your code. Be brief about your messages! You can see your commits by

git log --pretty=oneline --graph --decorate --all

This is a modified version of the 'git log' command, better for the eyes. Right now, since only you contributed a file, it only shows your commit. There are lots of aliases you can use to prevent injuries on your fingers, typing all these commands.

We haven't uploaded our commit yet, so nobody can see what you did so far. The before-mentioned upload is called 'push' in git terminology. To push;

git push

Now, your local repository should push the commits to your remote repository. Any collaborator already cloned should now have access to your push. Now you can add your project files and commit them as mentioned above easily:

If you have a project already, simply put all your project files into your repository root.
If you are starting a brand new project, put your base project files to your repository root.

Now, your .gitignore file should take care of unnecessary files by not tracking them by default. When it comes to working with multiple collaborators, things get a little nasty. I will cover up that with new commands branching, fetching, pulling, and merging in my next post!

Git 101 - Kickstart Your Repo

Can Cellek — Mon, 06 Feb 2023 17:59:02 +0000

The "Git Fundamentals" idea has been around my mind for a long time. For developers, git may be easy to understand but for many artists, it is mostly overwhelming.
In this series I will try to explain what is Git and how you can use it for your projects, specially tailored for non-developers and indie game developers.

What Is Git Anyway

As KISS (Keep It Simple Stupid) dictates, we can shortly tell that Git is one of the widely used version control systems around. But what is version control?
How can you take benefit from it? Imagine you are working on a project, adding new features and fixes regularly. What if another colleague is working on the same project and modified the same code? What if you have changed something and realized it is not working as it should anymore? Well, in such situations git
will be your best friend!

Git allows you to work with multiple colleagues simultaneously, even on the same code. These are called conflicts and can be solved easily since git can show differences between modifications done by each colleague and you can choose with file or which line of code to choose.
Git stores the history of each change. With this approach, you can even get back to the code you wrote a year ago! It is like you have a space-time bending Delorian, only working backward to current.
You can create branches and continue working on different features at the same time. Git will change each code to the corresponding branch state.
When you are done you can merge your branches into a master branch that holds finalized features together, most likely a release candidate.
If you are using git with service providers' issue systems, you can close issues with your commits so it will not be a pain to create changelogs and beta testers to check the situation.
Working with a team requires good project management. You can keep track of each colleagues commits and keep track of the progress.

There are lots of benefits I haven't mentioned yet but these are just the most important ones.

How To Get Started

First of all, you need a service to use. There are different services around and they all come with their pros and cons. I will not compare each service in depth, considering these article series are specially tailored for indie devs, I will talk about licenses.

GitHub: Home of open source projects, GitHub is a widely used git service around the world.
Bitbucket: Bitbucket is another widely used git service where you can create private projects with a free account. With a free account, it restricts you to having limited contributors working on a private project. If your team is larger, you can subscribe.
GitLab: GitLab is one of the git services as well. You can create unlimited projects both private and public with unlimited users.

Keep in mind that these can change in the meantime, I strongly recommend you to check out their websites and ask google for in-depth comparisons. In Stygian: Reign of the Old Ones we chose Bitbucket since they have their other services you can use without any hassle. When you are done with the decision part and create your account, it comes to setting up the environment you should work on. Just in case if you are not familiar with some terms, the before-mentioned projects are called a repository. Repositories (shortly repo) are where your project codes are stored. You should create one first to continue.

Let's Go Already!

Now it is time to make another decision before it gets more technical. First of all, you need your computer to understand "Git". Git will not work like regular uploading or FTP. To do that, you can either

Use GUI software to do the commands for you
Use terminal with git commands

Both options are viable, but if you are new to this git magic, I strongly recommend you to use GUI software to visualize how git works first if you plan to use the terminal later. Depending on a few researches provided by different resources (sorry, couldn't find a link) majority of git users use both GUI and CLI (terminal) at the same time. Git GUI Software: Here are a few software for you

GitHub Desktop: If you plan to use GitHub, it has a flawless integration (free)
SourceTree: If you plan to use Bitbucket, it has a flawless integration (free)
GitKraken: One of the best-looking git clients around, might be easier for you to get used to git. (free for non-commercial projects)
Tower: One of the most advanced git clients around

Git Terminal If you plan to use the terminal as well, you first have to download Git from Git SCM to start. Next article, I will write down how to start working on your repository.