TOOLS TO INSTALL USING VISUAL CODE
GIT CONFIGURATION
Minimal configuration:
$ git config --global user.name="Óscar Gómez Fuente"
$ git config --global user.email="ogomez@tst-sistemas.es"
Show global file configuration [Windows path: C:\Users\<YourUsername>\.gitconfig and Linux path: ~/.gitconfig]:
$ git config --global -e
[filter "lfs"]
clean = git-lfs clean -- %f
smudge = git-lfs smudge -- %f
process = git-lfs filter-process
required = true
[user]
name = Oscar Gomez Fuente
email = oscargomezf@gmail.com
[init]
defaultBranch = main
[alias]
lg = log --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
s = status --short --branch
[core]
autocrlf = true
editor = "nano"
[pull]
rebase = true
LIST USEFUL COMMANDS
$ git config --global -l: Show global GIT configuration [linux: ~/.gticonfig and Windwos: c:\Users\$USER\.gitconfig].
$ git init: Init repository.
$ git clone https://github.com/<username>/<awesome-project>.git: Create a copy of an entire repository from a remote source.
$ git fetch <origin>: Update your local repository with changes from a remote repository without modifying your working directory (Not merging).
$ git pull <origin> <remote>: Keep your local repository up-to-date with the latest changes from the remote repository. The most current version of the code.
$ git status: Summary of the current state of your repository.
$ git branch: List all local branches in the repository.
$ git branch <name-branch>: Create a new branch called <name-branch>.
$ git branch -d <name-branch>: Delete the branch <name-branch>.
$ git branch -m <old-name-branch> <new-name-branch>: It is used to rename a branch in Git.
$ git checkout <name-branch>: Switch to the branch <name-branch>.
$ git checkout -b <name-branch>: Create and switch to the new branch <name-branch>.
$ git checkout -b <name-branch>: Create and switch to the new branch <name-branch>.
$ git remote prune origin: Clean up remote-tracking branches that no longer exist on the remote repository.
$ git add <filename>: Add files to the staging area, preparing them for the next commit.
$ git add .: Add all files in the current directory.
$ git reset <filename> or git restore --staged <filename>: Delete a file from the stage.
$ git commit -m <comment-description>: Commit with a comment.
$ git log: Displays the commit history of your repository.
$ git reflog: Shows a history of all the changes (updates) made to the references, including branch tips, HEAD, or other references.
$ git checkout -- <filename>: It allows you to restore files to their state at the last commit.
$ git reset --soft <HEAD^N> or <commit-hash>: Move the HEAD to the specified commit <hash_number>, but it keeps your changes in the staging area.
$ git reset --mixed <HEAD^N> or <commit-hash>: Move the HEAD to the specified commit <hash_number> and remove changes from the staging area but keep them in the working directory.
$ git reset --mixed <HEAD^N> or <commit-hash>: Move the HEAD to the specified commit <hash_number> and discard all changes in both the staging area and working directory.
$ git commit -am <comment-description>: Add all the changes to the stage area and commit the changes with a comment.
$ git commit --amend -m <comment-description>: It is used to modify the most recent commit.
$ git diff: Compare the working directory vs the last commit.
$ git diff --stage: Compare the staging area vs the last commit.
$ git tag: List all tags in the repository.
$ git tag <name-release>: Create a tag called <name-release>.
$ git tag -d <name-release>: Delete the tag called <name-release>.
$ git tag -a <name-tag> -m <description-tag>: Create an annotated tag with <name-tag> and the description <description-tag>.
$ git tag -a <name-tag> <commit-hash> -m <description-tag>: Create an annotated tag with <name-tag> and the description <description-tag> to the specific commit <commit-hash>.
$ git show <name-tag>: Show the description of the tag <name-tag>.
LIST OF TIPS
TIP I: The first time you do an "add", you add the files in question to the stage. If you made a mistake, you can revert to the previous state by running the following command:
$ git add index.html
$ git rm --cache index.html
TIP II: The .gitkeep file is a convention used in Git to indicate to this version control system that a folder, despite being empty, should be included in the repository.
TIP III: If you get the following problem warning: "warning: in the working copy of 'index.html', LF will be replaced by CRLF the next time Git touches it". This warning indicates that line endings will be changed from LF (Line Feed) to CRLF (Carriage Return Line Feed) when Git processes the file. This can happen due to differences in how various operating systems handle line endings. Solution:
git config --global core.autocrlf true
[On Windows systems, this setting converts LF to CRLF when checking out code, and converts CRLF back to LF when committing code. ] If you prefer to use Linux Systems mode, Solution:
git config --global core.eol lf; git config --global core.autocrlf false
TIP IV: If you want to recover a version that has been deleted with the hard option, you can do so by following these steps:
Check the history: $ git reflog
Run a git reset --hard <hash-number>, with the hash_number of the desired version.
TIP V: Alias for log. $ git lg @ git config --global alias.lg "log --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"
TIP VI: Alias for status. $ git s @ git config --global alias.s "status --short"
TIP VII: Alias for status. $ git s @ git config --global alias.s "status -sb"
BRANCH MERGE OPTIONS
FAST-FORWARD: When Git detects no changes in the main branch, the changes can be reintegrated transparently. Each of the commits will become part of the main branch as if they were never separated.
AUTOMATIC MERGES: Git detects that there have been changes in the main branch that the secondary branches or the other branch are unaware of. However, when we attempt to merge, Git proceeds without issues if there are no modifications or conflicts (e.g., identical lines). At this point, both branches are marked as merged.
Delete a branch locally and push the changes to the remote repository:
$ git branch -d <name_branch>
$ git push origin :<name_branch>
How to merge one branch into another [Fast-Forward]?
Be in the branch that is waiting for the new changes:
$ git checkout master
Verify you are in the desired branch:
$ git branch
Perform the merge:
$ git merge <branch_name>
Once the branch is merged, it is common practice to delete it:
$ git branch -d <branch_name> [-f]
STASH
The stash is like a temporary pocket where you can store the changes you have made to your files, but you are not yet ready to commit them (i.e., save them permanently in your project's history).
$ git stash: Create a stash of the current modifications.
$ git stash list: List the current stashes.
$ git stash pop: Reapply the most recent stash and remove it from the stash list.
$ git stash clear: Delete all stashes.
$ git stash apply 'stash@{2}': Recover the stash previously shown with git stash list.
$ git stash drop 'stash@{1}': Delete the specified stash.
$ git stash show 'stash@{1}': Show the files affected by the specified stash.
$ git stash save "Added Lokki to Villains": Add a stash with a specific name.
$ git stash list --stat: Display information about all stashes.
$ git stash drop: Delete the most recent stash."
REBASE
A rebase is an operation that allows you to rewrite the commit history of a branch. In simpler terms, it is like taking a series of commits and reapplying them on another starting point.
Why use Rebase?
Cleaner History: By rebasing, you can combine several commits into one, remove unnecessary commits, or reorder them, resulting in a more linear and easier-to-follow commit history.
Branch Integration: When you want to integrate changes from one branch into another, rebase can provide a cleaner history than a merge.
Prepare for a Pull Request: Before submitting a pull request, rebasing your branch onto the main branch can help avoid conflicts and make the code review process smoother.
How does it work?
Select the Branches: Identify the branch you want to modify (branch to rebase) and the branch onto which you want to rebase (base branch).
Create New Commits: Git takes the commits from the branch to rebase and recreates them one by one on the base branch.
Resolve Conflicts: If there are conflicting changes, you will need to resolve them manually.
Update the Branch: The branch to rebase now points to the newly created commits.
COMMANDS
$ git checkout branch_with_changes_to_move
$ git rebase base_branch_name
INTERACTIVE REBASE
$ git rebase -i HEAD~
Reorder commits.
Correct commit messages (reword).
Combine commits (squash).
Split commits (edit).
To finish a rebase:
$ git rebase --continue
OTHERS RELATED TO GITHUB
Hosted Services: BitBucket, GitHub
Local Services: Gitosis.
ADD A NEW REPOSITORY TO GITHUB
$ echo "# liga-justicia" >> README.md
$ git init
$ git add README.md
$ git commit -m "first commit"
$ git branch -M main #Rename the branch master to main
$ git remote add origin https://github.com/username/liga-jisticia.git #http
or
$ git remote add origin git@github.com:username/liga-jisticia.git #ssh
$ git push -u origin main
ADD AN EXISTING REPOSITORY TO GITHUB
$ git remote add origin https://github.com/username/liga-justicia.git #http
or
$ git remote add origin git@github.com:username/liga-jisticia.git #ssh
$ git push -u origin main (Only the first time, after that it's only necessary: git push)
RENAME REPOSITORY NAME
$ git remote -v
origin https://github.com/oscargomezf/liga-justicia.git (fetch)
origin https://github.com/oscargomezf/liga-justicia.git (push)
$ git remote rename origin origin_new
$ git remote set-url origin_new https://github.com/oscargomezf/liga-justicia_new.git
$ git remote -v
origin_new https://github.com/oscargomezf/liga-justicia_new.git (fetch)
origin_new https://github.com/oscargomezf/liga-justicia_new.git (push)
REQUEST CHANGES FROM THE REMOTE REPOSITORY
$ git remote -v #Ver el repositorio remote
$ git pull origin main
PUSH/PULL TAGS TO/FROM THE REMOTE REPOSITORY
$ git push --tags
$ git pull --tags
WARNING - PULLING WITHOUT RECONCILE STRATEGY
$ git config pull.rebase false # merge (The default strategy)
$ git config pull.rebase true # rebase
$ git config pull.ff only # fast-fordward only
To add the desired method, execute the following command:
$ git config --global pull.ff only
$ git config --global pull.rebase true or false
$ git config --global -e
PULL REQUEST
A pull request is a fundamental tool in collaborative software development, especially on platforms like GitHub, GitLab, or Bitbucket.
What does it consist of? Imagine you are working on a project with other developers. Each of you has your own copy of the code (a 'fork') where you make your changes. When you finish a task or a new feature, you can submit a merge request (pull request) to the project's main repository.
HOW TO ACCESS A PRIVATE GITHUB REPOSITORY USING SSH FROM COMMAND LINE
Steps to follow if you need to access a private remote repository with write access:
Generate an SSH key (if the user doesn’t have one yet)
Run the following command in the terminal to generate a new SSH key:
$ ssh-keygen -t ed25519 -C "your_email@example.com"
This will create a public and private key pair (id_ed25519 and id_ed25519.pub) in the ~/.ssh/ directory.
Copy the public key
Display the public key using:
$ cat ~/.ssh/id_ed25519.pub
Copy the output, which looks something like: ssh-ed25519 AAAAC...your_email@example.com
Add the SSH key to GitHub
Log in to your GitHub account.
Navigate to Settings (by clicking on your avatar in the top-right corner).
Go to SSH and GPG keys in the left-hand menu.
Click New SSH key.
Give your SSH key a title (e.g., "My laptop SSH key").
Paste the public key you copied earlier into the key field.
Click Add SSH key.
4. Verify the SSH connection
Test the connection to GitHub using:
$ ssh -T git@github.com
If everything is set up correctly, you should see a message like:
$ ssh -T git@github.com
Hi username! You've successfully authenticated, but GitHub does not provide shell access.
5. Clone the private repository
If the user already belongs to the team with the correct permissions, they can now clone the repository using the SSH URL:
$ git clone git@github.com:organization/repository-name.git
6. Work with the repository
Use standard Git commands like git pull, git push, etc., to interact with the repository.
7. Add to another PC the private key:
$ chmod 600 ~/.ssh/id_ed25519
$ ssh-add ~/.ssh/id_ed25519
$ ssh-add -l
MANAGING MULTIPLE SSH KEYS
To manage multiple keys in different repositories, the following file must be edited ~/.ssh/config:
Host github-organization-1
HostName github.com
User git
IdentityFile ~/.ssh/id_rsa_organization_1
IdentitiesOnly yes
Host github-organization-2
HostName github.com
User git
IdentityFile ~/.ssh/id_rsa_organization_2
IdentitiesOnly yes
NOTES:
Start the SSH agent:
$ eval "$(ssh-agent -s)"
Delete all ssh keys:
$ ssh-add -D
Delete a specific key:
$ ssh-add -d /home/username/.ssh/private_key
If you need to be persistent, :please add these lines to your ~/.bashrc file:
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa_organization_1
ssh-add ~/.ssh/id_rsa_organization_2