8.2 KiB
Comandos Basicos
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
- Stages a specific file. For example:
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.
- Stages all changes (modified, new, and deleted files) in the entire repository. This is equivalent to
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"
- Creates a new commit with the staged changes. The
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
(whereorigin
is the default name for your remote andmain
is the primary development branch).
git push -u <remote_name> <branch_name>
(orgit 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
- 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
- If your local branch is already tracking a remote branch (i.e., you've used
-u
before or cloned a repository), simply runninggit push
will push your changes to the tracked remote branch.
- If your local branch is already tracking a remote branch (i.e., you've used
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.
- If your current local branch is tracking a remote branch, simply running
Note: git pull
is essentially a shortcut for two other commands:
git fetch <remote_name>
: Downloads commits, files, and refs from a remote repository into your local repository, but doesn't automatically merge them.git merge <remote_name>/<branch_name>
: Merges the fetched changes into your current branch.
Basic Workflow Summary:
- Modify files.
git status
: Check what you've changed.git add .
: Stage your changes.git commit -m "Your descriptive message"
: Commit your staged changes.git pull origin main
: Get the latest changes from the remote (to avoid merge conflicts later).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
# 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:
# 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:
# 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
# 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
# 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:
# 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
# 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
# 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
- Always create backups before performing destructive operations
- Use
--dry-run
when available to preview command effects - Avoid force push on shared branches (especially main/master)
- Set up aliases for complex commands you use frequently
- 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.