| ... | ... | @@ -13,9 +13,11 @@ To prepare a [commit](#commit) : each added file will be in your next [commit](# |
|
|
|
```bash
|
|
|
|
git add <file/folder>
|
|
|
|
```
|
|
|
|
To remove an added file use the (`git restore --staged `)\[#args\] command.
|
|
|
|
|
|
|
|
### -i
|
|
|
|
To remove an added file use the (`git restore --staged` )\[#args\] command.
|
|
|
|
|
|
|
|
### \-i
|
|
|
|
|
|
|
|
Interactive mode
|
|
|
|
|
|
|
|
## bisect
|
| ... | ... | @@ -72,7 +74,9 @@ git clone <repository> [<dest_dir>] |
|
|
|
```
|
|
|
|
|
|
|
|
repository is either ssh or https address of the repo.
|
|
|
|
|
|
|
|
## Commit
|
|
|
|
|
|
|
|
A commit is like a checkpoint : you have modified multiple files, and you [push](#push) them to the [origin](#origin) with a commit message like "hey I've done this and that".
|
|
|
|
|
|
|
|
A commit can but doesn't have to contain all your modified files, it will only include [added](#add) files. Any commit will be accompanied by a **commit message** that NEEDS to contain the important things that has been modified in the added files.
|
| ... | ... | @@ -82,9 +86,12 @@ git commit |
|
|
|
```
|
|
|
|
|
|
|
|
Each git commit can then bee seen in your history using git log.
|
|
|
|
|
|
|
|
#### How to make a proper commit ?
|
|
|
|
|
|
|
|
##### How to write a commit message ?
|
|
|
|
⚠To help with the readability of the commit history, every git message MUST [follow the convention](https://www.conventionalcommits.org/en/v1.0.0/)
|
|
|
|
|
|
|
|
:warning:To help with the readability of the commit history, every git message MUST [follow the convention](https://www.conventionalcommits.org/en/v1.0.0/)
|
|
|
|
|
|
|
|
```text
|
|
|
|
Chore : This is a commit message example. This line will serve as commit title.
|
| ... | ... | @@ -92,17 +99,21 @@ Chore : This is a commit message example. This line will serve as commit title. |
|
|
|
The following Lines will be used to provide more context to someone that wants to inspect this given commit.
|
|
|
|
Users are urged to provide as much context as possible in their commits.
|
|
|
|
```
|
|
|
|
|
|
|
|
##### What should a commit contain ?
|
|
|
|
|
|
|
|
A commit should be atomic, meaning that 1 commit must contains changes that :
|
|
|
|
|
|
|
|
1. Work.
|
|
|
|
2. Can be grouped under 1 common designations (the commit message).
|
|
|
|
3. This designation is the shortest common denominator.
|
|
|
|
> **🧠 Example :**
|
|
|
|
> You created a branch to add the opeator `Foo` in aidge_core. While working, you discovered an issue in another file that is not related to the `Foo` operator, and completed the README with a new .
|
|
|
|
> This will result in 2 commits that will be written following the commits conventions explained above :
|
|
|
|
> 1. `feat : adding support of operator Foo` that will contain all modifications related to foo, it can (and should) cover multiple files.
|
|
|
|
|
|
|
|
> **🧠 Example :** You created a branch to add the opeator `Foo` in aidge_core. While working, you discovered an issue in another file that is not related to the `Foo` operator, and completed the README with a new . This will result in 2 commits that will be written following the commits conventions explained above :
|
|
|
|
>
|
|
|
|
> 1. `feat : adding support of operator Foo` that will contain all modifications related to foo, it can (and should) cover multiple files.
|
|
|
|
> 2. `chore: completed README.MD with missing informations about ....`
|
|
|
|
> 3. Note That this is multi line commit as shown just above
|
|
|
|
>
|
|
|
|
> ```
|
|
|
|
> fix: Added assertion to avoid buffer Overflow in Bar::baz(n)
|
|
|
|
>
|
| ... | ... | @@ -287,30 +298,121 @@ git push <remote> <current_branch> |
|
|
|
|
|
|
|
Sets the branch given as arg as the reference branch to follow.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## rebase
|
|
|
|
|
|
|
|
Reapply commits on top of another base tip.
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git rebase <branch/commit_name>
|
|
|
|
```
|
|
|
|
|
|
|
|
This means that is will start from given commit will reapply all your commits on top of it.
|
|
|
|
|
|
|
|
This operation can be seen as a merge with the difference that there will be no merge commit.
|
|
|
|
|
|
|
|
### `-i`
|
|
|
|
|
|
|
|
allows you to edit your git history to make it clearer before merging
|
|
|
|
`i` stands for interactive. This will allow you to apply rebase and to edit your commit history at the same time. This can act as a time machine and help you clean up you commit history or even re order it.
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git rebase -i <hash>
|
|
|
|
```
|
|
|
|
|
|
|
|
:warning: since you edit your history you will need to force push afterward.
|
|
|
|
|
|
|
|
### tutorial
|
|
|
|
|
|
|
|
https://www.youtube.com/watch?v=rt9ZOVciJm8
|
|
|
|
Here is my current history.
|
|
|
|
|
|
|
|
{width=734 height=116}
|
|
|
|
|
|
|
|
We can see issues here :
|
|
|
|
|
|
|
|
1. There are 3 commits about resize : They ould be aggregated in 1. I created 1 "new feature" & 2 "refactors" commits which served as "checkpoints" during my development. But actually a commit informing of a refactor would only be valuable to inform users/devs of a breaking change. In this case, I am the only one who have worked on it as of now. So no need for 3 commits
|
|
|
|
2. The commit order is not what I would like it to be.
|
|
|
|
3. `18630dc` message is not the right one.
|
|
|
|
|
|
|
|
All of that can be done with `git rebase --interactive`. I just need to select the hash of the parent commit of the oldest one I want to modify. Here I want to modify up to `d49aa08`, hence I will select `f9d74d9`:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git rebase -i f9d74d9
|
|
|
|
```
|
|
|
|
|
|
|
|
This will open your default text editor (configured with `$EDITOR`) with this inside :
|
|
|
|
|
|
|
|
{width=600 height=490}
|
|
|
|
|
|
|
|
We can see 2 parts :
|
|
|
|
|
|
|
|
1. the upper one where all the commits are listed in "tabs" with 3 columns
|
|
|
|
1. The action to perform on the commit (default is `pick`).
|
|
|
|
2. The commit hash.
|
|
|
|
3. The commit message.
|
|
|
|
2. the lower one where all the actions you can do are listed. If you wan to learn more I recommend to read it.
|
|
|
|
|
|
|
|
Here we want to :
|
|
|
|
|
|
|
|
1. Squash (/merge) all commits about resize in 1 commit.
|
|
|
|
2. Reorder commits.
|
|
|
|
3. Reword `18630dc`
|
|
|
|
|
|
|
|
I can do that here by modifying the text file like follows (only showing the part that actually changes) :
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
What I have done :
|
|
|
|
|
|
|
|
1. Re-ordered the commits
|
|
|
|
2. Put replaced `squash` by `pick` in front of the commits I wanted to merge with the previous one.
|
|
|
|
3. Put `reword` instead of `pick` in front of the repo I wanted to rename.
|
|
|
|
|
|
|
|
Now I will save and quit my editor and this will open new editors to choose the new names of the commits that will be created.
|
|
|
|
|
|
|
|
1. For reword :
|
|
|
|
|
|
|
|
{width=614 height=269}
|
|
|
|
2. For the squashed commits (here I will remove the last 2 commits messages as they are useless)
|
|
|
|
|
|
|
|
{width=575 height=521}
|
|
|
|
|
|
|
|
Once every thing is done, here is my new git history all cleaned up :
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#### :warning: Warnings about rebase
|
|
|
|
|
|
|
|
**:warning: This operation might require to force push** :warning:
|
|
|
|
|
|
|
|
Since you edit the history of the repository, if you modify commits that were previously pushed, you will need to FORCE PUSH afterward. If you screwed up anything and force push, you will ERASE commits history : THIS CAN HAVE HORRENDOUS CONSEQUENCES. If you are not sure of what you are doing , please call someone more competent than you.
|
|
|
|
|
|
|
|
:warning: **rebase after merge = conflicts**
|
|
|
|
|
|
|
|
> Lets say you want to merge branch A & B, from branch A, you will call `git merge B`. You history will then look smthg like
|
|
|
|
>
|
|
|
|
> ```
|
|
|
|
> commit_A 1bd18dc : Merged branch B into A
|
|
|
|
> commit_A 12y1xvG: oui
|
|
|
|
> commit_B 0192ndc : Lorem ipsum
|
|
|
|
> commit_B 18cvhbp : blabla
|
|
|
|
> commit_A 1gcta7iy : beep boop
|
|
|
|
> ```
|
|
|
|
>
|
|
|
|
> All your commits will be re-applied in chronological order. Hence, if you call
|
|
|
|
>
|
|
|
|
> If you call `git rebase 1gcta7iy` after having merged, all the commits from branch A will still be put on top of the commits from branch B. This will rewrite the history like follows:
|
|
|
|
>
|
|
|
|
> ```
|
|
|
|
> commit_A 1bd18dc : Merged branch B into A
|
|
|
|
> commit_A 12y1xvG: oui
|
|
|
|
> commit_A 1gcta7iy : beep boop
|
|
|
|
> commit_B 0192ndc : Lorem ipsum
|
|
|
|
> commit_B 18cvhbp : blabla
|
|
|
|
> ```
|
|
|
|
>
|
|
|
|
> This will generate a lot of pollution in the rebase process as you will have a lot of conflicts.
|
|
|
|
|
|
|
|
### `--autosquash`
|
|
|
|
|
|
|
|
automatically squashes commits that you previously marked with `--squash` while comitting
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## remote
|
|
|
|
|
|
|
|
Allows you to handle the remote repository. This is mostly useful when you are working on a fork and need to retrieve modifications from multiple remotes.
|
| ... | ... | |
