Remote

We upload the .git repository on github. The repository hosted by github becomes the de facto single source of truth. From the point of view of clients, it is a remote.

The remote is identified by its URL. But we give it an alias for convenience. We name this alias origin.

setup an alias

We alias the remote URL as origin.

git remote add origin https://github.com/s3/a33.git

list the aliases

there should be only one, origin

git remote show

read a specific remote details

read the URL and other details

git remote show origin

change an alias' URL

change the URL that origin refers to

git remote set-url origin git@github.com:s3/a33.git

delete a branch on remote

push is because it's an update to the remote repo.

git push origin --delete 2024

fast forward.

Our local commit is an ancestor of the tentative remote commit. That is, the remote repo added commits to our local one and reached a final commit. This means our local commit didn't branch/fork away from the remote commit, and as such, no merge is applicable or need. We add the remote commits to our local commit.

If our working tree is "dirty", that is, has uncommited changes, we must compare it to the tentative new working tree.

clean and dirty files

Let's called the working tree files we changed "dirty" and the files we didn't change "clean".

If the fast forward only affect "clean" files, those receive the commits' changes and are changed to their latest version.

If the fast forward affects "dirty" files, we must decide if we keep our local dirty files or if we instead pick the new commited version.

conflit avec la version de travail

Si la version de travail d'Antoine comporte des modifications qui risquent d'être perdues, car par exemple il a modifié chen.txt, git va le prévenir et lui proposer soit de commit, soit de stash.

> error: Your local changes to the following files would be overwritten by merge:

chen.txt

> Please commit your changes or stash them before you merge.

> Aborting

utiliser stash pour gérer le conflit

stash notre version de travail, accepter le commit

git stash
git pull

la version de travail est mise dans la version du commit, celui de chen.

tenter de pop le stash

git stash pop

git détecte le conflit entre la version stashed et la version de travail, celle de chen. Git décide alors d'exposer ce conflit directement dans le fichier concerné.

Auto-merging chen.txt
CONFLICT (content): Merge conflict in chen.txt
On branch main
Your branch is up to date with 'origin/main'.

Unmerged paths:
  (use "git restore --staged <file>..." to unstage)
  (use "git add <file>..." to mark resolution)
	both modified:   chen.txt
______

<<<<<<< Updated upstream
4, signed chen
=======
4, signed antoine
>>>>>>> Stashed changes

Il suffit alors de modifier le fichier concerné, en décidant quelle version garder. On fait ensuite git add pour confirmer la résolution. Enfin, on purge le stash.

open chen.txt
..
git add chen.txt
..
git stash pop

fetch

update the remote-tracking local branches, such as origin/main and origin/dev

They are listed at: .git/refs/remotes/origin

merge

merge one branch (ex:dev) to current (ex:main)

We first compare the two branches: the receiving branch (current), and the giving branch.

If the receiving branch is a parent of the giving branch, that is, it has not drifted away because it didn't do any commit on its own, then we can simply fast forward the receiving branch to the state of the giving branch, making them point to the same commit.

If the receiving branch has done at least one distinct commit, it means there was an actual fork, and a merge commit is required, to integrate the branch that has forked, and to preserve the fact that there was a fork. The merge commit only occurs on the receiving branch.

For example, we merge dev into main. dev is unaffected. main has a merge commit.

merge the changes coming from remote

this is what happens when we do git pull (fetch + merge): the fetch updates origin/main, then the merge applies a fast forward so that main and origin/main point to the same commit.

git merge origin/main

merge a branch into main

git merge <branch-name>
git merge dev

clone: download and expand the .git directory

download

a clone download the .git directory.

https://github.com/mantinedev/mantine.git

we may clone a stripped-out version of the .git directory, one who contains less files.

For example, we ask the files needed by the last commit, and not the others. This is called a shallow clone.

We specify the depth, to target only the n-last commits.

git clone --depth 1 https://github.com/mantinedev/mantine.git
git clone --depth 1 [--branch master] https://github.com/mantinedev/mantine.git

expand

the clone automatically expands the latest commit files into the working directory.

branches and remote

push a new branch to a remote

we must specify

the remote repo we want to push to (here origin)

the branch to push

that this branch will now push by default on that remote

git push --set-upstream origin en
git push --set-upstream origin dev

indicate the remote branch where to push

this does not indicate the local branch, so it probably push the currently selected branch.

git push -u origin beta

indicate match between current local branch and remote branch

git branch --set-upstream-to origin/my_branch
git branch -u origin/my_branch

remove the branch from the remote

git push origin --delete beta