Alperen Doc

basic_git_conf

Mon, 01 Jan 0001 00:00:00 +0000

Git username & git email conf

git config --add --global user.name "github_username_here"
git config --add --global user.email "email@example.com"

Git github default branc

git config --global init.defaultBranch main

CLI ile login ol

gh auth login

basic_git_knowledge

Mon, 01 Jan 0001 00:00:00 +0000

Simplified Git Commands Guide#

Initialize a Git Repository#

Navigate to the directory you want to track.
Run the following command:

git init

Adding Files or Directories#

To add files or directories to the staging area, use:

git add <file_or_directory_name>

git add

Checking the Current State#

To see the current state of your repository:

git status

git status

Committing Changes#

To save changes to the repository:

git commit -m "Your commit message"

git commit

Branch Management#

Creating and Switching to a New Branch#

Use the following command to create and switch to a new branch:

git switch -c my_new_branch

This is easier than using git branch followed by git switch. git branch

github_workflow

Mon, 01 Jan 0001 00:00:00 +0000

001 - continuous_integration 002 - continuous_deployment

Hugo-Book Teması ve GitHub Actions(workflow) ile VPS’e CD#

Hugo,Markdown dosyalarını statik bir siteye dönüştüren bir araç. Bu yazıda, suan bulundugunuz siteyi nasil hugo-book temasını kullanırken aynı zamanda GitHub Workflow kullanarak her değişikliği debian tabanli uzak sunucuma nasıl otomatik olarak deploy edeceğimi anlatmak istedim.

1. VPS ve Kullanıcı Yapılandırması#

İlk başta sistemi --system parametresiyle kurmayı düşünmüştüm. Sistem kullanıcısı oluşturmak mantıklı çünkü bu kullanıcının varsayılan olarak bir şifresi ve interaktif bir shell oturumu olmaz (tabi belirli komutlarla yapilabilir). Bu da sunucunun guvenligini arttirir.

continuous_integration

Mon, 01 Jan 0001 00:00:00 +0000

Continuous Integration#

Continuous Integration (CI) is where developers regularly push code changes into a central repository, and by doing so, automated builds and tests are automatically run.

Those tests can include unit tests, integration tests, styling checks, linting checks, security checks or any other type of automated test. If any of the tests fail, the build is considered “broken” and the developer is notified so they can fix it.

I was forked boot.dev cli for testing CI at Boot.dev Cli#

Here at Boot.dev CI tests that run each time a new pull request is opened. The reviewer doesn’t need to manually check for formatting issues or run tests locally before approving the changes. It automates part of the code review process.

continuous_deployment

Mon, 01 Jan 0001 00:00:00 +0000

Continuous Deployment (CD) is the process of automatically deploying code changes to a production environment after the code has been built and tested. Let’s set up CD for Notely!

We’ll be using GitHub Actions again, but we’ll create a new workflow for CD: cd.yml

How to create cd#

Create a new workflow .github/workflows/cd.yml
It should trigger on push into the main branch.

on:
 push:
 branches: [main]

It should have a single job called Deploy
It should checkout the code
It should set up the Go toolchain
It should build the app using the scripts/buildprod.sh script

To be clear, the ci workflow runs when a pull request is opened, but the cd workflow runs when a pull request is merged (or when code is pushed directly to the main branch).

git status

Mon, 01 Jan 0001 00:00:00 +0000

Status#

A file can be in one of several states in a Git repository. Here are a few important ones:

untracked: Not being tracked by Git
staged: Marked for inclusion in the next commit
committed: Saved to the repository’s history

The git status command shows you the current state of your repo. It will tell you which files are untracked, staged, and committed.

for more git branch

git add

Mon, 01 Jan 0001 00:00:00 +0000

git add#

Here’s the command:

git add <path-to-file | pattern>

For example:

git add i-use-arch.btw

git commit

Mon, 01 Jan 0001 00:00:00 +0000

Commit#

After staging a file, we can commit it.

A commit is a snapshot of the repository at a given point in time. It’s a way to save the state of the repository, and it’s how Git keeps track of changes to the project. A commit comes with a message that describes the changes made in the commit.

Here’s how to commit all of your staged files:

git commit -m "your message here"

Change the last commit message#

git commit --amend -m "A: add contents.md"

git push

Mon, 01 Jan 0001 00:00:00 +0000

Git Push#

The git push command pushes (sends) local changes to any “remote” - in our case, GitHub. For example, to push our local main branch’s commits to the remote origin’s main branch we would run:

git push origin main

You need to be authenticated with the remote to push changes, which you should have done in the last lesson.

Alternative Options#

You can also push a local branch to a remote with a different name:

git branch

Mon, 01 Jan 0001 00:00:00 +0000

What Is a Branch?#

A Git branch allows you to keep track of different changes separately.

For example, let’s say you have a big web project and you want to experiment with changing the color scheme. Instead of changing the entire project directly (as of right now, our master branch), you can create a new branch called color_scheme and work on that branch. When you’re done, if you like the changes, you can merge the color_scheme branch back into the master branch to keep the changes. If you don’t like the changes, you can simply delete the color_scheme branch and go back to the master branch.

git pull

Mon, 01 Jan 0001 00:00:00 +0000

Pull#

Fetching is nice, but most of the time we want the actual file changes from a remote repo, not just the metadata.

Command Syntax#

git pull [<remote>/<branch>]

The [...] syntax means that the bracketed remote and branch are optional. If you execute git pull without anything specified it will pull your current branch from the remote repo.

git log

Mon, 01 Jan 0001 00:00:00 +0000

Git Log#

A Git repo is a (potentially very long) list of commits, where each commit represents the full state of the repository at a given point in time.

The git log command shows a history of the commits in a repository. This is what makes Git a version control system. You can see:

Who made a commit
When the commit was made
What was changed

A Commit Hash#

Each commit has a unique identifier called a “commit hash”. This is a long string of characters that uniquely identifies the commit. Here’s an example of mine:

git merge

Mon, 01 Jan 0001 00:00:00 +0000

Merge#

“What’s the point of having multiple branches?” you might ask. They’re most often used to safely make changes without affecting your (or your team’s) primary branch. However, once you’re happy with your changes, you’ll want to merge them back into the main branch so that they make their way into the final product.

Visual#

Let’s say you’re in a state where you have two branches, each with their own unique commits:

git rebase

Mon, 01 Jan 0001 00:00:00 +0000

Rebase#

“Rebase vs Merge” is one of the most hotly debated topics in the Git world. A lot of the discussions you’ll see online come down to the fact that many developers (yes, even professionals) don’t understand the purpose of rebase and use it incorrectly, causing a bunch of Git havoc, and then blame the rebase command.

It’s not Git’s fault, it’s a skill issue.

Visualizing Rebase#

Say we have this commit history:

git reset

Mon, 01 Jan 0001 00:00:00 +0000

Git Reset Soft#

The git reset command can be used to undo the last commit(s) or any changes in the index (staged but not committed changes) and the worktree (unstaged and not committed changes).

git reset --soft COMMITHASH

The --soft option is useful if you just want to go back to a previous commit, but keep all of your changes. Committed changes will be uncommitted and staged, while uncommitted changes will remain staged or unstaged as before.

git remote

Mon, 01 Jan 0001 00:00:00 +0000

Git Remote#

Often our frenemies (read: coworkers) make code changes that we need to begrudgingly accept into our pristine bug-free repos. /s

This is where the “distributed” in “distributed version control system” comes from. We can have “remotes”, which are just external repos with mostly the same Git history as our local repo.

When it comes to Git (the CLI tool), there really isn’t a “central” repo. GitHub is just someone else’s repo. Only by convention and convenience have we, as developers, started to use GitHub as a “source of truth” for our code.

git fetch

Mon, 01 Jan 0001 00:00:00 +0000

Fetch#

Adding a remote to our Git repo does not mean that we automagically have all the contents of the remote. First, we need to fetch the contents (but not yet!).

Command#

git fetch

This downloads copies of all the contents of the .git/objects directory (and other book-keeping information) from the remote repository into your current one.

git switch

Mon, 01 Jan 0001 00:00:00 +0000

New Branch#

You should already be on the main branch: your “default” branch. You can always check with git branch.

Two Ways to Create a Branch#

git branch my_new_branch

This creates a new branch called my_new_branch. The thing is, I rarely use this command because usually I want to create a branch and switch to it immediately. So I use this command instead:

git switch -c my_new_branch

The switch command allows you to switch branches, and the -c flag tells Git to create a new branch if it doesn’t already exist.

git config

Mon, 01 Jan 0001 00:00:00 +0000

We need to configure Git to contain your information. Whenever code changes, Git tracks who made the change. To ensure you get proper credit (or more likely, blame) for all the code you write, you need to set your name and email.

Git comes with a configuration both at the global and the repo (project) level. Most of the time, you’ll just use the global config.

Assignment#

Let’s set your identity. Check if your user.name and user.email are already set:

gitignore

Mon, 01 Jan 0001 00:00:00 +0000

Gitignore#

As you’ve seen, it’s pretty normal to use the following workflow from the top level of your repo:

git add .
git commit -m "some message here"
git push origin main

A problem arises when we want to put files in our project’s directory, but we don’t want to track them with Git. gitignore file solves this. For example, if you work with Python, you probably want to ignore automatically generated files like .pyc and __pycache__. If you are building a server, you probably want to ignore .env files that might hold private keys. If you (I’m sorry) work with JavaScript, you might want to ignore the node_modules directory.

plumping

Mon, 01 Jan 0001 00:00:00 +0000

The Plumbing#

So far we’ve been using Git in a “porcelain” manner. But to sate our insatiable curiosity, let’s take a look at some of the “plumbing”.

It’s Just Files All the Way Down#

All the data in a Git repository is stored directly in the (hidden) .git directory. That includes all the commits, branches, tags, and other objects we’ll learn about later.

Git is made up of objects that are stored in the .git/objects directory. A commit is just a type of object.