Complete GIT Guide – Advanced GIT Commands

git rebase – Reorganize commits

The git rebase command is a powerful but potentially complex tool that allows you to modify the commit history of a branch. In essence, it allows you to “relocate” a series of commits from one branch onto another, creating a clean, linear history.

What does git rebase do?

1. Identifies the commits to relocate: It takes the commits from your current branch that are not present in the target branch.
2. Apply the commits on the target branch: Apply those commits one by one on the tip of the target branch, as if you had done them directly on that branch.
3. Create new commits: Instead of modifying the original commits, git rebase creates new commits with the same changes but with new identifiers (SHA-1).
4. Update current branch_: Move your current branch pointer to point to the new set of relocated commits.

When to use git rebase?

• Clean up the history: To reorganize the commits in a branch, remove unnecessary commits or combine several commits into one, creating a more linear and easier to understand history.
• Integrate changes from another branch: Instead of using git merge, you can use git rebase to apply changes from another branch to your own, avoiding the creation of a merge commit and maintaining a linear history.
• Collaboration: Before doing a git push to a shared branch, you can use git rebase to reorganize your commits and facilitate code review and change integration.

How to use git rebase:

1. Switch to the branch you want to relocate: Use git checkout <branch-name> to move to the branch whose commits you want to relocate.
2. Run the rebase: Type git rebase <branch-name-target> and press Enter. Replace <branch-name-target-branch> with the name of the branch you want to relocate your commits to.

Example:

Considerations:

• Rewrite history: git rebase modifies the commit history, which can cause problems if other developers are already working with the original commits. Use with caution on shared branches.
• Conflicts: If there are conflicts between your commits and those of the target branch, GIT will stop the rebase and ask you to resolve them manually.
• Alternative to git merge: git rebase can be an alternative to git merge for integrating changes, but it has different implications on the commit history. Choose the appropriate option according to your needs and your team’s workflow.

git reset – Undo changes

The git reset command is a versatile but potentially dangerous tool that allows you to undo changes to your repository. It can move the HEAD pointer, modify the Staging Area and even revert changes to your Working Tree. It is important to understand its different modes of operation and use it with caution, especially on shared branches.

What does git reset do?

• Moves HEAD: Changes the HEAD pointer to a specific commit, effectively modifying the current branch.
• Modifies the Staging Area: Can remove files from the Staging Area or even discard changes to the Working Tree, depending on the mode of operation used.

Operation Modes:

• --soft: Moves HEAD to the specified commit, but keeps the changes in the Staging Area and Working Tree. Useful for combining several commits into one or modifying the message of a recent commit.
• --mixed (default): Moves HEAD to the specified commit, discards the changes in the Staging Area and keeps the changes in the Working Tree. Useful for undoing git add or preparing a different commit.
• --hard: Moves HEAD to the specified commit, discards the changes from the Staging Area and overwrites the changes in the Working Tree. It is useful to discard all unsaved changes and return to a previous state of the project, but be careful, as changes in the Working Tree will be permanently lost.

When to use git reset?

• Undo commits: To remove recent commits from your local branch (before doing git push).
• Undo git add: To remove files from the Staging Area without losing changes in the Working Tree.
• Clean Working Tree: To discard all unsaved changes and return to a previous state of the project (use --hard with caution).

How to use git reset:

1. Identify the commit you want to return to: Use git log to find the identifier of the desired commit.
2. Run the command:
   • git reset --soft <commit-identifier>: To undo commits keeping the changes in the Staging Area and the Working Tree.
   • git reset <identifier-commit> or git reset --mixed <identifier-commit>: To undo commits and git add, keeping the changes in the Working Tree.
   • git reset --hard <identifier-commit>: To discard all changes and return to the state of the specified commit (be careful, you will lose unsaved changes!).

Examples:

Cautions:

• Shared branches: Avoid using git reset --hard on shared branches, as you may overwrite other developers’ work.
• Data loss: git reset --hard can cause permanent data loss if you are not careful. Make sure you understand what you are doing before using it.
• Safer alternatives: In many cases, it is preferable to use git revert to safely undo commits, as it creates new commits that revert the changes instead of modifying the existing history.

git stash – Temporarily save changes

The git stash command is like a magic drawer where you can temporarily save your changes without committing. It is useful when you are working on something and need to change branches or do a pull, but don’t want to lose changes that are not yet ready to be included in a commit.

What does git stash do?

• Saves the changes you have in your Working Tree and Staging Area to a temporary storage area called “stash ”.
• Clears your Working Tree and Staging Area, leaving them as they were at the last commit.
• It allows you to switch branches, do a pull or perform other operations without worrying about your unsaved changes.
• You can retrieve your changes later when you are ready to continue working on them.

When to use git stash?

• Context switching: When you need to switch branches quickly but have unsaved changes that you don’t want to include in a commit yet.
• Pull without conflicts: When you want to do a git pull but you have local changes that could generate conflicts. You can use git stash, do the pull and then retrieve your changes with git stash pop.
• Save work in progress: When you want to temporarily save an idea or experiment that is not yet ready to be committed.

How to use git stash:** ** git stash`: When you want to temporarily save an idea or an experiment not yet ready to be committed.

• git stash: Save all changes to the Working Tree and Staging Area in a new stash.
• git stash list: Lists all the stashes you have created.
• git stash pop: Applies the last stash created and removes it from the stash list.
• git stash apply: Applies the last stash created without removing it from the stash list.
• git stash drop: Removes the last stash created.

Examples:

Considerations:

• Multiple stashes: You can create multiple stashes and manage them with the git stash list, git stash apply <stash-number> and git stash drop <stash-number> commands.
• Conflicts: If applying a stash conflicts with the current changes in your Working Tree, GIT will prompt you to resolve them manually.
• Staging Area Changes: git stash saves both Working Tree and Staging Area changes. If you only want to save changes to the Working Tree, you can use git stash --keep-index or git stash -u.

git tag – Tag commits

The git tag command allows you to create tags at specific points in your repository history, marking important commits such as release versions, project milestones or other significant events. The tags act as permanent, friendly references to those commits, making them easy to identify and access later.

What does git tag do?

• Creates a tag (tag) that points to a specific commit.
• Tags can be either lightweight or annotated.
• Lightweight tags: These are simply pointers to commits, with no additional information.
• Annotated tags: They contain additional metadata, such as the tagger’s name, the date, a message and a GPG signature (optional). They are considered more complete and secure.

When to use git tag?

• Release versions: To tag commits that represent stable versions of your software, making them easier to identify and download later.
• Project milestones: To mark important points in the project’s development, such as the completion of a key feature or the correction of a critical bug.
• Permanent references: To create friendly references to specific commits, instead of having to remember their long and complex SHA-1 identifiers.

How to use git tag:

1. List tags:
   • git tag: List all existing tags in your repository.
   • git tag -l “<pattern>”: List tags that match a specific search pattern.
2. Create a lightweight tag:
   • git tag <tag-name>: Creates a lightweight tag in the current commit.
   • git tag <tag-name> <identifier-commit>: Creates a lightweight tag in the specified commit.
3. Create an annotated tag:
   • git tag -a <tag-name> -m “Descriptive message”: Creates an annotated tag in the current commit with the specified message.
   • git tag -a <tag-name> <commit-id> -m “Descriptive message”: Creates an annotated tag in the specified commit with the specified message.
4. Delete a tag:
   • git tag -d <tag-name>.
5. Send tags to a remote repository:
   • git push origin <tag-name>: Send a specific tag to the remote repository.
   • git push origin --tags: Send all tags to the remote repository.

Examples:

git cherry-pick – Apply branch-specific commits to another branch

The git cherry-pick command allows you to select one or more specific commits from one branch and apply them to another branch. It’s like taking cherries from one tree and placing them in another, allowing you to incorporate one-off changes without merging entire branches.

What does git cherry-pick do?

• It takes the specified commit from one branch and creates a new commit on the current branch with the same changes.
• The new commit will have a different identifier (SHA-1) than the original commit, but will contain the same file changes.
• It preserves the author and date of the original commit, but records the current date as the date the cherry-pick was applied.

When to use git cherry-pick?

• Bug fixes: If you have fixed a bug in a development branch and want to apply that fix to the main branch without merging the entire development branch.
• Specific functionality: If you want to incorporate a specific functionality from one branch to another without including all other changes from that branch.
• Revert changes: If you accidentally made a commit to the wrong branch, you can use git cherry-pick to apply that commit to the correct branch and then revert it to the original branch.

How to use git cherry-pick:

• Identify the commit you want to apply: Use git log to find the identifier (SHA-1) of the desired commit.
• Switch to the target branch: Use git checkout <branch-name-target-branch> to move to the branch where you want to apply the commit.
• Execute the cherry-pick: Type git cherry-pick <identifier-commit> and press Enter.

Example:

Considerations:

• Conflicts: If the commit you are applying conflicts with existing changes in the target branch, GIT will stop the cherry-pick and ask you to resolve the conflicts manually.
• Non-linear history: Excessive use of git cherry-pick can create a non-linear, hard-to-follow commit history. Use it sparingly and consider other options such as git merge or git rebase when appropriate.
• Multiple commits: You can apply several commits at once using their identifiers separated by spaces: git cherry-pick <commit1> <commit2> <commit3>.

Read the first chapter of this guide here or read the entire series here.