***

### Comandos Basicos
***
```bash


git add . // Agregar todos los cambios al proximo commit
git commit -m "Mensaje"
git push  // Enviar el o los commit al server Remoto

git pull  // Descargar las modificaciones desde el server remoto


```


#### Staging Changes (`git add`)

Before you can commit your changes, you need to tell Git which specific changes you want to include in the next commit. This is called "staging."

- **`git add <file_name>`**
    - Stages a specific file. For example: `git add index.html`
- **`git add .`**
    - Stages all changes in the current directory and its subdirectories. This is a very common command to stage all modified and new files.
- **`git add -u`**
    - Stages all modified and deleted files, but _not_ new files. Useful if you've only made changes to existing tracked files.
- **`git add -A`**
    - Stages all changes (modified, new, and deleted files) in the entire repository. This is equivalent to `git add .` if you are in the root of the repository.

**To check what's staged/unstaged:**

- **`git status`**
    - Shows the current state of your working directory and the staging area. It tells you which files are staged, unstaged, and untracked.

---

#### 2. Committing Changes (`git commit`)

Once your changes are staged, you can record them as a new snapshot in the repository's history using a commit. Each commit should represent a logical unit of work.

- **`git commit -m "Your descriptive commit message"`**
    - Creates a new commit with the staged changes. The `-m` flag allows you to provide a short, descriptive message directly in the command line.
    - **Good commit messages are crucial!** They explain _what_ changes were made and _why_.
    - Example: `git commit -m "Add user authentication feature"`
- **`git commit`**
    - Opens your default text editor (like Vim or Nano) to allow you to write a more detailed commit message. This is useful for longer explanations or when following a specific commit message convention.

---

#### 3. Pushing Changes (`git push`)

After committing your changes locally, you'll often want to share them with a remote repository (e.g., GitHub, GitLab, Bitbucket). This is done using `git push`.

- **`git push <remote_name> <branch_name>`**
    - Pushes your committed changes from your local branch to a specific remote branch.
    - **Common usage:** `git push origin main` (where `origin` is the default name for your remote and `main` is the primary development branch).
- **`git push -u <remote_name> <branch_name>`** (or `git push --set-upstream`)
    - This is typically used the _first time_ you push a new local branch to a remote. It sets up the "upstream" tracking relationship, meaning Git will remember that your local branch is connected to that remote branch. After this, you can often just use `git push`.
    - Example: `git push -u origin feature/new-design`
- **`git push`**
    - If your local branch is already tracking a remote branch (i.e., you've used `-u` before or cloned a repository), simply running `git push` will push your changes to the tracked remote branch.

---

#### 4. Pulling Changes (`git pull`)

When working with others, or even on different machines, you'll need to get the latest changes from the remote repository to your local machine. This is done using `git pull`.

- **`git pull <remote_name> <branch_name>`**
    - Fetches changes from the specified remote branch and then automatically merges them into your current local branch.
    - **Common usage:** `git pull origin main`
- **`git pull`**
    - If your current local branch is tracking a remote branch, simply running `git pull` will fetch and merge changes from its tracked upstream branch.

**Note:** `git pull` is essentially a shortcut for two other commands:

1. **`git fetch <remote_name>`**: Downloads commits, files, and refs from a remote repository into your local repository, but _doesn't_ automatically merge them.
2. **`git merge <remote_name>/<branch_name>`**: Merges the fetched changes into your current branch.

---

### Basic Workflow Summary:

1. **Modify files.**
2. **`git status`**: Check what you've changed.
3. **`git add .`**: Stage your changes.
4. **`git commit -m "Your descriptive message"`**: Commit your staged changes.
5. **`git pull origin main`**: Get the latest changes from the remote (to avoid merge conflicts later).
6. **`git push origin main`**: Share your committed changes with the remote.


# Essential Git Commands for Common Problems

This guide covers basic Git commands to help you handle common challenges like merge conflicts, overwriting changes, and navigating commit history.

## Basic Commands

```bash
# Check status of your repository
git status

# Check commit history
git log
git log --oneline --graph --decorate  # More visual representation

# View changes before committing
git diff
git diff --staged  # View staged changes
```

## Handling Merge Conflicts

When your branch falls behind and you encounter conflicts:

```bash
# Update your local repository with remote changes
git fetch origin

# Merge changes from origin/main to your current branch
git merge origin/main

# If conflicts occur, Git will tell you which files are in conflict
# Edit the files manually to resolve conflicts, then:
git add <conflicted-files>
git commit -m "Resolve merge conflicts"

# Alternative: abort the merge if needed
git merge --abort
```

## Force Your Version as the Latest

When you want your version to override others:

```bash
# Force push your changes (use with caution!)
git push --force origin <branch-name>

# A safer alternative: force-with-lease checks if remote has new changes
git push --force-with-lease origin <branch-name>

# Overwrite local changes with remote changes
git reset --hard origin/<branch-name>

# Overwrite a single file with the version from another branch
git checkout <branch-name> -- <file-path>
```

## Going Back to a Specific Commit

```bash
# Move back to a specific commit without changing files (detached HEAD)
git checkout <commit-hash>

# Reset your branch to a specific commit (will lose later commits)
git reset --hard <commit-hash>

# Create a new commit that undoes changes from a previous commit
git revert <commit-hash>
```

## Branch Management

```bash
# Create and switch to a new branch
git checkout -b <new-branch-name>

# Switch to an existing branch
git checkout <branch-name>

# List all branches
git branch        # Local branches
git branch -r     # Remote branches
git branch -a     # All branches

# Delete a branch
git branch -d <branch-name>   # Safe delete (prevents deleting unmerged changes)
git branch -D <branch-name>   # Force delete
```

## Stashing Changes

Useful when you need to switch branches but aren't ready to commit:

```bash
# Save changes to the stash
git stash save "Your stash message"

# List stashes
git stash list

# Apply the most recent stash without removing it
git stash apply

# Apply a specific stash
git stash apply stash@{n}

# Apply and remove the most recent stash
git stash pop

# Remove a stash
git stash drop stash@{n}

# Clear all stashes
git stash clear
```

## Fixing Mistakes

```bash
# Amend the last commit message
git commit --amend -m "New commit message"

# Add forgotten files to the last commit
git add <forgotten-files>
git commit --amend --no-edit

# Undo staging of files
git reset <file>

# Discard changes in working directory
git checkout -- <file>
git restore <file>  # In newer Git versions
```

## Advanced Techniques

```bash
# Interactive rebase to edit, squash, or reorder commits
git rebase -i HEAD~n  # Where n is the number of commits to go back

# Cherry-pick specific commits from another branch
git cherry-pick <commit-hash>

# Cleanup unnecessary files
git clean -n  # Dry run - shows what would be deleted
git clean -f  # Actually delete the files

# Temporarily save changes from a dirty working directory
git worktree add <path> <branch>
```

## Safety Tips

1. **Always create backups** before performing destructive operations
2. **Use `--dry-run`** when available to preview command effects
3. **Avoid force push** on shared branches (especially main/master)
4. Set up **aliases** for complex commands you use frequently
5. Configure Git to **require confirmation** for potentially harmful actions

Remember that Git preserves history in the `.git` directory, so most "destructive" commands can be undone, but it's better to be cautious.