mirror of
https://github.com/theoludwig/theoludwig.git
synced 2024-11-09 14:51:30 +01:00
fix(posts): update git-ultimate-guide
This commit is contained in:
parent
4d085cb148
commit
28d9211583
@ -2,20 +2,22 @@
|
|||||||
title: '🗓️ Git version control: Ultimate Guide'
|
title: '🗓️ Git version control: Ultimate Guide'
|
||||||
description: 'What is `git`, what are the most used commands, best practices, and tips and tricks. The Ultimate guide to master `git` in your daily workflow.'
|
description: 'What is `git`, what are the most used commands, best practices, and tips and tricks. The Ultimate guide to master `git` in your daily workflow.'
|
||||||
isPublished: true
|
isPublished: true
|
||||||
publishedOn: '2022-09-04T14:33:07.465Z'
|
publishedOn: '2022-10-27T14:33:07.465Z'
|
||||||
---
|
---
|
||||||
|
|
||||||
Hello! 👋
|
Hello! 👋
|
||||||
|
|
||||||
Welcome to the Ultimate Guide to master `git` in your daily workflow, we will see what are the most used commands, what are the best practices, and tips and tricks.
|
Welcome to the Ultimate Guide to master `git` in your daily workflow, we will see what are the most used commands, what are the best practices, and tips and tricks.
|
||||||
|
|
||||||
|
This guide is a summary of the most important things to know when working with `git`, and in general, will link to the official documentation of `git` or other resources for more details (you can use it as a `git` cheatsheet).
|
||||||
|
|
||||||
**Note:** Sources used to write this blog post are available at the [end of this post](#sources).
|
**Note:** Sources used to write this blog post are available at the [end of this post](#sources).
|
||||||
|
|
||||||
## Introduction
|
## Introduction
|
||||||
|
|
||||||
**Git** is a free and open source distributed **version control system** for keeping track of changes across a set of files.
|
**Git** is a free and open-source distributed **version control system** for keeping track of changes across a set of files.
|
||||||
|
|
||||||
Git was originally authored by [Linus Torvalds](https://en.wikipedia.org/wiki/Linus_Torvalds) in 2005 for development of the [Linux kernel](https://kernel.org/).
|
Git was originally authored by [Linus Torvalds](https://en.wikipedia.org/wiki/Linus_Torvalds) in 2005 for the development of the [Linux kernel](https://kernel.org/).
|
||||||
|
|
||||||
Git allows:
|
Git allows:
|
||||||
|
|
||||||
@ -42,7 +44,7 @@ These configurations are stored in the `.gitconfig` file in your home directory
|
|||||||
email = email@example.com
|
email = email@example.com
|
||||||
```
|
```
|
||||||
|
|
||||||
You can find more information and useful `git` configurations in the official documentation: [git-scm.com/docs/git-config](https://git-scm.com/docs/git-config).
|
You can find more information and useful `git` configurations in the [official documentation](https://git-scm.com/docs/git-config).
|
||||||
|
|
||||||
## How `git` works?
|
## How `git` works?
|
||||||
|
|
||||||
@ -55,8 +57,19 @@ Each node is called commit and contains:
|
|||||||
- an instantaneous view (snapshot) of the state of the repository at a specific moment
|
- an instantaneous view (snapshot) of the state of the repository at a specific moment
|
||||||
- metadata: message, author, creation date, etc.
|
- metadata: message, author, creation date, etc.
|
||||||
|
|
||||||
|
Commits are **snapshots** (not diffs on each file) of the project at specific moments in time.
|
||||||
|
|
||||||
|
There are several areas where the files in your project will live in Git:
|
||||||
|
|
||||||
|
- **Working directory**: the files that you see in your computer's file system.
|
||||||
|
- **Staging area**: the files that will go into your next commit (files added with `git add <filename>` command).
|
||||||
|
- **Local repository**: the `.git` directory, which contains all of your project's commits, branches, etc. (files added with `git commit -m "message"` command).
|
||||||
|
- **Remote repository**: the `.git` directory in a remote server (files added with `git push` command).
|
||||||
|
|
||||||
## Commands cheatsheet
|
## Commands cheatsheet
|
||||||
|
|
||||||
|
You can find the official documentation of `git` commands at [git-scm.com/docs](https://git-scm.com/docs).
|
||||||
|
|
||||||
```sh
|
```sh
|
||||||
# Initialize a new git repository
|
# Initialize a new git repository
|
||||||
git init
|
git init
|
||||||
@ -74,20 +87,25 @@ git add <file>
|
|||||||
git commit -m "chore: initial commit"
|
git commit -m "chore: initial commit"
|
||||||
|
|
||||||
# Add remote repository
|
# Add remote repository
|
||||||
git remote add origin <url>
|
git remote add <remote> <url>
|
||||||
|
# The main <remote> is often called `origin`
|
||||||
|
|
||||||
# Add forked repository
|
# Add forked repository
|
||||||
git remote add upstream <url>
|
git remote add <remote> <url>
|
||||||
|
# The forked <remote> is often called `upstream`
|
||||||
|
|
||||||
|
# List all the remotes
|
||||||
|
git remote
|
||||||
|
|
||||||
# Sync forked repository
|
# Sync forked repository
|
||||||
git fetch upstream
|
git fetch <remote>
|
||||||
git merge upstream/<branch>
|
git merge <remote>/<branch>
|
||||||
|
|
||||||
# Push changes to remote repository
|
# Push changes to remote repository
|
||||||
git push
|
git push <remote>
|
||||||
|
|
||||||
# Pull changes from remote repository
|
# Pull changes from remote repository
|
||||||
git pull
|
git pull <remote>
|
||||||
|
|
||||||
# Show the status of the working tree
|
# Show the status of the working tree
|
||||||
git status
|
git status
|
||||||
@ -105,8 +123,8 @@ git checkout <branch>
|
|||||||
git merge <branch>
|
git merge <branch>
|
||||||
|
|
||||||
# Delete a branch
|
# Delete a branch
|
||||||
git branch -d <branch>
|
git branch --delete <branch>
|
||||||
git push origin --delete <branch>
|
git push <remote> --delete <branch>
|
||||||
|
|
||||||
# Fetch branches from remote repository and prune
|
# Fetch branches from remote repository and prune
|
||||||
git fetch --prune
|
git fetch --prune
|
||||||
@ -116,7 +134,7 @@ git revert <commit>
|
|||||||
|
|
||||||
# Change several past commits (interactive rebase)
|
# Change several past commits (interactive rebase)
|
||||||
# HEAD points to the current consulted commit.
|
# HEAD points to the current consulted commit.
|
||||||
git rebase -i HEAD~<number-of-commits>
|
git rebase --interactive HEAD~<number-of-commits>
|
||||||
|
|
||||||
# Reset the current branch, delete all commits since <branch> (without removing the changes)
|
# Reset the current branch, delete all commits since <branch> (without removing the changes)
|
||||||
git reset --soft <branch>
|
git reset --soft <branch>
|
||||||
@ -149,39 +167,68 @@ This is useful when you want to keep an empty directory in your repository but y
|
|||||||
|
|
||||||
## Git remote repositories (GitHub/GitLab)
|
## Git remote repositories (GitHub/GitLab)
|
||||||
|
|
||||||
Explain what are the differences, how it works, + basic vocabulary...
|
Once you are ready to share your code over the internet, you will need to create a remote repository on a service like [GitHub](https://github.com) or [GitLab](https://gitlab.com).
|
||||||
|
|
||||||
|
There are many other services, you can also self-host your own Git server.
|
||||||
|
|
||||||
### SSH vs HTTPS authentication
|
### SSH vs HTTPS authentication
|
||||||
|
|
||||||
Explain the differences + quickly setup a SSH key...
|
Once you have created a remote repository, you will need to authenticate to push and pull changes.
|
||||||
|
|
||||||
|
There are two main ways to authenticate:
|
||||||
|
|
||||||
|
- **SSH**: you will need to generate an SSH key pair and add the public key to your remote repository.
|
||||||
|
- **HTTPS**: you will need to provide your username and password each time you push or pull changes.
|
||||||
|
|
||||||
|
SSH authentication is the recommended way to authenticate to a remote repository.
|
||||||
|
|
||||||
|
You can find more information about SSH authentication in the [official documentation](https://git-scm.com/book/en/v2/Git-on-the-Server-Generating-Your-SSH-Public-Key).
|
||||||
|
|
||||||
### Sign `git` commits with `gpg`
|
### Sign `git` commits with `gpg`
|
||||||
|
|
||||||
Explain, how and why to sign `git` commits...
|
As we have seen in the [Get started with `git` and `.gitconfig` config file](#get-started-with-git-and-gitconfig-config-file) section, we can configure `git` with a name and email address with a value of our choice.
|
||||||
|
|
||||||
### Continous Integration/Continuous Delivery
|
That means that **anyone can create a commit with any name and email address and claim to be whoever they want** when they create a commit.
|
||||||
|
|
||||||
GitHub Actions, Vercel, why is it so important...
|
To avoid this, you can sign your commits with a <abbr title="GNU Privacy Guard">[GPG](https://gnupg.org/)</abbr> key.
|
||||||
|
|
||||||
|
You can find more information about signing commits in the [official documentation](https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work).
|
||||||
|
|
||||||
|
### Continous Integration/Continuous Delivery (CI/CD)
|
||||||
|
|
||||||
|
Once you have your code in a remote repository, everyone (with access) can potentially start contributing to the project. This is great, but it also means that you need to have a way to ensure that your code is working as expected for each change in the project.
|
||||||
|
|
||||||
|
You could do it manually, depending on the size and the complexity of the project, but it could be a tedious task.
|
||||||
|
|
||||||
|
Instead, you can use a **Continuous Integration** (CI) service to automate the process of testing your code, running linting, unit tests, e2e tests, etc.
|
||||||
|
|
||||||
|
There are many CI services, but the most popular ones are [GitHub Actions](https://github.com/features/actions), [GitLab CI](https://docs.gitlab.com/ee/ci/), [CircleCI](https://circleci.com/), [Travis CI](https://travis-ci.org/), and many others...
|
||||||
|
|
||||||
|
Then, once your code is ready, tested and working as expected, you can use a **Continuous Delivery** (CD) service to automate the process of **deploying your code**.
|
||||||
|
|
||||||
|
CI/CD services are usually integrated with remote repositories, so you can configure them to run automatically when you push changes to the remote repository.
|
||||||
|
|
||||||
## Best practices and `git` workflows
|
## Best practices and `git` workflows
|
||||||
|
|
||||||
### Commit messages and semver
|
Commit messages are very important, they are a way to easily know what has changed in the project.
|
||||||
|
|
||||||
### GitFlow
|
There are many conventions for commit messages, but the most popular one is the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification.
|
||||||
|
|
||||||
...
|
Then, we can use the commit messages to automatically determine a [semantic version](https://semver.org/) for the next release of the project.
|
||||||
|
|
||||||
### GitHub Flow
|
When multiple developers are working on the same project, it is important to organize the work in a way that everyone can work on different features without conflicts (changes in the same files).
|
||||||
|
|
||||||
...
|
There are many ways to organize the work, but the most popular ones are:
|
||||||
|
|
||||||
### Trunk-based
|
- [GitFlow](https://nvie.com/posts/a-successful-git-branching-model/)
|
||||||
|
- [GitHub Flow](https://guides.github.com/introduction/flow/)
|
||||||
|
- [Trunk-based development](https://trunkbaseddevelopment.com/)
|
||||||
|
|
||||||
...
|
They are called **Git workflows**, or **Git branching strategies**.
|
||||||
|
|
||||||
## Conclusion
|
## Conclusion
|
||||||
|
|
||||||
`git` is the tool that every programmer should know to do collaborative work and keeping track of changes across a set of files.
|
`git` is the tool that every programmer should know to do collaborative work (not only, `git` is also very powerful even when working alone) and keep track of changes across a set of files.
|
||||||
|
|
||||||
## Sources
|
## Sources
|
||||||
|
|
||||||
@ -189,5 +236,4 @@ GitHub Actions, Vercel, why is it so important...
|
|||||||
- [Git Explained in 100 Seconds](https://www.youtube.com/watch?v=hwP7WQkmECE)
|
- [Git Explained in 100 Seconds](https://www.youtube.com/watch?v=hwP7WQkmECE)
|
||||||
- [Understand Git in 7 minutes](https://www.jesuisundev.com/en/understand-git-in-7-minutes/)
|
- [Understand Git in 7 minutes](https://www.jesuisundev.com/en/understand-git-in-7-minutes/)
|
||||||
- [How (and why) to sign Git commits | With Blue Ink](https://withblue.ink/2020/05/17/how-and-why-to-sign-git-commits.html?utm_source=tiktok&utm_campaign=codetok-sign)
|
- [How (and why) to sign Git commits | With Blue Ink](https://withblue.ink/2020/05/17/how-and-why-to-sign-git-commits.html?utm_source=tiktok&utm_campaign=codetok-sign)
|
||||||
- [Creator of Gitflow blog post](https://nvie.com/posts/a-successful-git-branching-model/)
|
|
||||||
- [What Are the Best Git Branching Strategies](https://www.flagship.io/git-branching-strategies/)
|
- [What Are the Best Git Branching Strategies](https://www.flagship.io/git-branching-strategies/)
|
||||||
|
Loading…
Reference in New Issue
Block a user