It’s essential for all developers to understand version control, and Git has become the leading system for this in software development. However, many developers only learn the basics and don’t realize how much more efficient Git can make them. For instance, managing releases is a breeze with Git’s git tag feature.
My experience teaching a beginner’s Git class after completing an advanced online course (through Github) revealed a lack of technical articles on my favorite Git functions. So, I’m sharing them here! This post will teach you how to use these advanced Git functions:
git stash: Temporarily save your code locallygit reset: Clean up your code before committinggit bisect: Find problematic commitsgit squash: Merge multiple commits into onegit rebase: Apply changes from one branch to another
Git Stash
With git stash, you can save your code without committing it. Imagine this: You have three well-organized commits, but your uncommitted code is messy and needs cleaning before committing. Suddenly, you need to switch branches, perhaps because you forgot to create a new branch for your current feature while working on the main branch. Here’s how your code might look:
1
2
3
4
5
6
7
8
9
| $ git status
On branch my-feature
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: css/common.scss
no changes added to commit (use "git add" and/or "git commit -a")
|
1
2
3
4
5
6
7
8
9
10
11
12
13
| $ git diff
diff --git a/css/common.scss b/css/common.scss
index 2090cc4..90fd457 100644
--- a/css/common.scss
+++ b/css/common.scss
@@ -13,6 +13,6 @@
body {
font-family: "Proxima Nova", Arial, sans-serif;
font-size: 13px;
- color: #333;
+ color: red;
background-color: #f00;
}
|
Using git stash makes the uncommitted code disappear without being committed. This creates a temporary, local save of your work. Since you can’t push a stash to a remote repository, it remains for your use only.
1
2
| $ git stash
Saved working directory and index state WIP on my-feature: 49ee696 Change text color
|
Your branch now looks as it did after your last commit, allowing you to switch branches safely without losing your work or making a messy commit. Upon returning to your branch and running git stash list, you’ll see a list like this:
1
2
| $ git stash list
stash@{0}: WIP on my-feature: 49ee696 Change text color
|
You can reapply the stashed content with git stash apply. For specific stashes (if you have multiple), use git stash apply stash@{1} (the ‘1’ represents the second-to-last stash). Here’s how to stash multiple commits and apply a specific one:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
| $ git diff
diff --git a/css/common.scss b/css/common.scss
index 2090cc4..90fd457 100644
--- a/css/common.scss
+++ b/css/common.scss
@@ -13,6 +13,6 @@
body {
font-family: "Proxima Nova", Arial, sans-serif;
font-size: 13px;
- color: #333;
+ color: red;
background-color: #f00;
}
$ git stash
Saved working directory and index state WIP on my-feature: 49ee696 Change text color
$ git diff
diff --git a/css/common.scss b/css/common.scss
index 2090cc4..b63c664 100644
--- a/css/common.scss
+++ b/css/common.scss
@@ -13,6 +13,6 @@
body {
font-family: "Proxima Nova", Arial, sans-serif;
font-size: 13px;
- color: #333;
+ color: red;
background-color: #f00;
}
$ git stash
Saved working directory and index state WIP on my-feature: 49ee696 Change text color
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| $ git stash list
stash@{0}: WIP on my-feature: 49ee696 Change text color
stash@{1}: WIP on my-feature: 49ee696 Change text color
stash@{2}: WIP on my-feature: 49ee696 Change text color
$ git stash apply stash@{2}
On branch my-feature
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: css/common.scss
no changes added to commit (use "git add" and/or "git commit -a")
|
git stash apply stash@{2} reapplies the oldest stashed code, where we changed the text color to red.
1
2
3
4
5
6
7
8
9
10
11
12
13
| $ git diff
diff --git a/css/common.scss b/css/common.scss
index 2090cc4..90fd457 100644
--- a/css/common.scss
+++ b/css/common.scss
@@ -13,6 +13,6 @@
body {
font-family: "Proxima Nova", Arial, sans-serif;
font-size: 13px;
- color: #333;
+ color: red;
background-color: #f00;
}
|
If you choose not to commit your restored stash, use git checkout . to revert all uncommitted changes.
Here’s another example: You have new files, one with a bug. Leave all but the suspect file unstaged (required for stashing), then stash and troubleshoot it. If the stashed file wasn’t the problem, restore the stash.
1
2
3
4
5
6
7
8
| $ git status
On branch my-feature
Untracked files:
(use "git add <file>..." to include in what will be committed)
css/colors.scss
nothing added to commit but untracked files present (use "git add" to track)
|
1
2
3
4
5
6
7
8
9
10
11
12
| $ git add css/colors.scss
$ git stash
Saved working directory and index state WIP on my-feature: 0d8deef delete colors
$ git status
On branch my-feature
nothing to commit, working tree clean
$ git stash apply stash@{0}
On branch my-feature
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: css/colors.scss
|
You can even transfer your stashed commits to a new feature or debugging branch using git stash branch:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
| $ git status
On branch my-feature
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: css/common.scss
no changes added to commit (use "git add" and/or "git commit -a")
$ git stash
Saved working directory and index state WIP on my-feature: 66f3f3b Add colors file
$ git stash branch debugging-branch
M css/common.scss
Switched to a new branch 'debugging-branch'
Unstaged changes after reset:
M css/common.scss
On branch debugging-branch
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: css/common.scss
Dropped refs/stash@{0} (d140624f60d8deef7bceb0d11fc80ed4fd47e0a1)
|
Remember, applying a stash doesn’t delete it. Remove stashes individually with git drop or all at once with git stash clear:
1
2
3
4
5
6
7
8
9
10
11
12
| $ git stash list
stash@{0}: WIP on my-feature: 66f3f3b Add colors file
stash@{1}: WIP on my-feature: 0d8deef delete colors
stash@{2}: WIP on my-feature: 49ee696 Change text color
$ git stash drop stash@{2}
Dropped stash@{2} (8ed6d2ce101aa2e28c8ccdc94cb12df8e5c468d6)
$ git stash list
stash@{0}: WIP on my-feature: 66f3f3b Add colors file
stash@{1}: WIP on my-feature: 0d8deef delete colors
$ git stash clear
$ git stash list
$
|
Git Reset
Accidentally committed messy code? A “soft” reset makes the code appear uncommitted, allowing you to clean it up in your IDE before committing again. Use git reset --soft HEAD~1 to reset the most recent commit. Adjust the number after ~ to reset multiple commits, like git reset --soft HEAD~2.
1
2
3
4
5
6
7
8
9
10
11
12
13
| $ git reset --soft HEAD~1
$ git status
On branch debugging-branch
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: css/common.scss
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: css/common.scss
|
1
2
3
4
5
6
7
8
9
10
11
12
13
| $ git diff
diff --git a/css/common.scss b/css/common.scss
index 2090cc4..90fd457 100644
--- a/css/common.scss
+++ b/css/common.scss
@@ -13,6 +13,6 @@
body {
font-family: "Proxima Nova", Arial, sans-serif;
font-size: 13px;
- color: $grey;
+ color: red;
background-color: #f00;
}
|
Git reset can be confusing, especially for beginners. Reserve soft resets for genuine mistakes and use stash for swapping code.
You can also perform a hard reset (git reset --hard HEAD~1), which erases your last commit. Exercise extreme caution with hard resets, especially if you’ve pushed your branch, as recovery is impossible.
Git Bisect
git bisect is a lifesaver, especially for large codebases with hard-to-find issues. It’s essentially a binary search between two commits, presenting you with a specific commit’s details. You provide Git with a known good commit and a bad one (they can be years apart).
The fun part? You often don’t know who wrote the buggy commit initially. Finding the source of the bug has sparked excitement amongst my colleagues more than once!
First, check out the buggy branch and find the good commit by reviewing the history, finding the hash, checking out that commit, and testing. Then, run git bisect.
Let’s say our website has red text, but we don’t know when or how it happened. This is a simple example; real-life issues are usually less obvious.
Checking git log shows the commit history:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
| $ git log
commit a3cfe7f935c8ad2a2c371147b4e6dcd1a3479a22 (HEAD -> main)
Author: Ursula Clarke <email@example.com>
Date: Tue Jan 11 10:52:57 2021 +0100
Update .gitignore file for .DS_Store
commit 246e90977790967f54e878a8553332f48fae6edc
Author: Ursula Clarke <email@example.com>
Date: Tue Jan 11 10:51:23 2021 +0100
Change styling of page
commit d647ac489ad43b3c6eaea5aceb02b0a7d7e5cf8e
Author: Ursula Clarke <email@example.com>
Date: Tue Jan 11 10:50:48 2021 +0100
Change text color
commit 032a41136b6653fb9f7d81aef573aed0dac3dfe9
Author: Ursula Clarke <email@example.com>
Date: Tue Jan 11 10:42:57 2021 +0100
Change text color
commit 246e90977790967f54e878a8553332f48fae6edc
Author: Ursula Clarke <email@example.com>
Date: Tue Jan 11 10:41:23 2021 +0100
delete colors
commit d647ac489ad43b3c6eaea5aceb02b0a7d7e5cf8e
Author: Ursula Clarke <email@example.com>
Date: Tue Jan 11 10:50:48 2021 +0100
Change text color
commit ce861e4c6989a118aade031020fd936bd28d535b
Author: Ursula Clarke <email@example.com>
Date: Tue Jan 11 10:07:36 2021 +0100
...
|
Opening the webpage with the most recent commit hash reveals red text, indicating a problem.
We start the bisect, informing Git of the bad commit.
1
2
| $ git bisect start
$ git bisect bad 8d4615b9a963ef235c2a7eef9103d3b3544f4ee1
|
Going back in time, we try the first commit…
1
2
3
4
5
6
7
8
9
10
11
12
13
| $ git checkout ce861e4c6989a118aade031020fd936bd28d535b
Note: checking out 'ce861e4c6989a118aade031020fd936bd28d535b'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b <new-branch-name>
HEAD is now at ce861e4 Add CSS styles
|
…and refresh the webpage…
The text is no longer red, so this is a good commit! The closer the good commit is to the bad commit, the better.
1
2
3
| $ git checkout d647ac489ad43b3c6eaea5aceb02b0a7d7e5cf8e
Previous HEAD position was ce861e4c6989a118aade031020fd936bd28d535b Add CSS styles
HEAD is now at d647ac4 Change text color
|
Git now estimates how many steps it needs to find the bad commit. This depends on the number of commits between the good and bad ones.
Next, test your branch again (remembering potential module updates or database changes).
git bisect checks out a commit between the good and bad ones, estimating one step to find the bad commit.
1
2
3
4
5
6
7
| $ git bisect good 1cdbd113cad2f452290731e202d6a22a175af7f5
Bisecting: 1 revision left to test after this (roughly 1 step)
[ce861e4c6989a118aade031020fd936bd28d535b] Add CSS styles
$ git status
HEAD detached at ce861e4
You are currently bisecting, started from branch '8d4615b'.
(use "git bisect reset" to get back to the original branch)
|
Refreshing the page shows the issue persists, so we tell Git it’s still a bad commit (no need to specify the hash). Repeat this until Git exhausts all steps.
1
2
3
| $ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[cbf1b9a1be984a9f61b79ae5f23b19f66d533537] Add second paragraph to page
|
Refreshing the page reveals the issue is gone; this is a good commit.
Git identifies the first bad commit:
1
2
3
4
5
6
7
8
9
| $ git bisect good
ce861e4c6989a118aade031020fd936bd28d535b is the first bad commit
commit ce861e4c6989a118aade031020fd936bd28d535b
Author: Ursula Clarke <email@example.com>
Date: Tue Jan 11 10:52:57 2021 +0100
Add CSS styles
:000000 100644 0000000000000000000000000000000000000000 092bfb9bdf74dd8cfd22e812151281ee9aa6f01a M css
|
Use git show to view the commit and pinpoint the issue:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| $ git show ce861e4c6989a118aade031020fd936bd28d535b
commit ce861e4c6989a118aade031020fd936bd28d535b
Author: Ursula Clarke <email@example.com>
Date: Tue Jan 11 10:52:57 2021 +0100
Add CSS styles
diff --git a/css/base.scss b/css/base.scss
index e69de29..26abf0f 100644
--- a/css/base.scss
+++ b/css/base.scss
@@ -1,7 +1,7 @@
body {
background-color: $white;
margin: 0px;
line-height: 20px;
- color: $grey;
+ color: red;
}
|
Finally, run git bisect reset to restore your branch to its normal state.
Closer commits make it easier for Git to pinpoint the problem, but it has successfully identified issues in as many as 10 steps for me. While not foolproof, it’s often effective.
Squashing Your Commits
Working on an open-source project taught me the importance of squashing (combining) commits. It’s a good habit, even if not required, as it benefits other developers reviewing your code.
Why squash?
Improved readability: A commit list like this:
- Implement carousel slider
- Add styling to carousel
- Add buttons to carousel
- Fix strange issue in IE with carousel
- Adjust margins in carousel
is clearer when squashed into “Add carousel to homepage.”
Better commit messages: Squashing before pull requests encourages meaningful commit names, avoiding vague ones like “WIP” or “bugfix.” Instead, aim for informative messages like “Bugfix for #444 login page - fix flicker due to missing $scope function.”
However, avoid squashing when working on large, complex features where maintaining a daily history for debugging is helpful. In such cases, squashing after ensuring the feature is bug-free and ready for the main branch still makes sense.
Consider this scenario: Five commits, all related to styling a new feature:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
| $ git log
commit a8fbb81d984a11adc3f72ce27dd0c39ad24403b7 (HEAD -> main)
Author: Ursula Clarke <email@example.com>
Date: Tue Jan 11 11:16:10 2021 +0100
Import colors
commit e2b3ddd5e8b2cb1e61f88350d8571df51d43bee6
Author: Ursula Clarke <email@example.com>
Date: Tue Jan 11 11:15:32 2021 +0100
Add new color
commit d647ac489ad43b3c6eaea5aceb02b0a7d7e5cf8e
Author: Ursula Clarke <email@example.com>
Date: Tue Jan 11 10:50:48 2021 +0100
Change text color
commit c005d9ceeefd4a8d4e553e825fa40aaafdac446e
Author: Ursula Clarke <email@example.com>
Date: Tue Jan 11 09:59:57 2021 +0100
Add CSS styles
commit 9e046b7df59cef07820cc90f694fabc666731bd2
Author: Ursula Clarke <email@example.com>
Date: Tue Jan 11 09:56:28 2021 +0100
Add second paragraph to page
commit 5aff973577d67393d914834e8af4c5d07248d628
Author: Ursula Clarke <email@example.com>
Date: Mon Jan 10 16:04:22 2021 +0100
Add colors CSS file and edit background color
|
While git merge --squash works, rebase provides a clearer view when cherry-picking commits. git merge --squash requires a hard reset (git reset --hard HEAD~1) before squashing, which can be confusing. I find git rebase more intuitive.
Run git rebase -i --root to open your default text editor with a list of commits:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
| pick eb1eb3c Update homepage
pick 5aff973 Add colors CSS file and edit background color
pick 9e046b7 Add second paragraph to page
pick c005d9c Add CSS styles
pick d647ac4 Change text color
pick e2b3ddd Add new color
pick a8fbb81 Import colors
# Rebase a8fbb81 onto b862ff2 (7 commands)
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
|
To squash only the last few commits, use git rebase -i HEAD~3:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| pick eb1eb3c Update homepage
pick 5aff973 Add colors CSS file and edit background color
pick 9e046b7 Add second paragraph to page
# Rebase b862ff2..9e046b7 onto b862ff2 (3 commands)
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
|
Now, squash all commits into the first one:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| pick eb1eb3c Update homepage
squash 5aff973 Add colors CSS file and edit background color
squash 9e046b7 Add second paragraph to page
# Rebase b862ff2..9e046b7 onto b862ff2 (3 commands)
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
|
Saving the file prompts Git to open the commit message for editing.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
|
# This is a combination of 3 commits.
# This is the 1st commit message:
Update homepage
# This is the commit message #2:
Add colors CSS file and edit background color
# This is the commit message #3:
Add second paragraph to page
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date: Wed Jan 13 18:31:28 2021 +0100
#
# interactive rebase in progress; onto b862ff2
# Last commands done (3 commands done):
# squash 5aff973 Add colors CSS file and edit background color
# squash 9e046b7 Add second paragraph to page
# No commands remaining.
# You are currently rebasing branch 'main' on 'b862ff2'.
#
# Changes to be committed:
# new file: .gitignore
# new file: css/base.css
# new file: css/base.scss
# new file: css/colors.css
# new file: css/colors.css.map
# new file: css/colors.scss
# new file: css/common.css
# new file: css/common.scss
# new file: index.html
#
|
While rebasing, edit the commit description for clarity.
1
2
3
4
5
| Implement new design for homepage. Add .gitignore file for Sass folder.
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
|
Save again, and you’re done! The Git log now shows one clean commit.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| [detached HEAD 574ec7e] Implement new design for homepage. Add .gitignore file for Sass folder.
Date: Wed Jan 13 18:31:28 2021 +0100
10 files changed, 215 insertions(+)
create mode 100644 .gitignore
create mode 100644 css/base.css
create mode 100644 css/base.scss
create mode 100644 css/colors.css
create mode 100644 css/colors.css.map
create mode 100644 css/colors.scss
create mode 100644 css/common.css
create mode 100644 css/common.scss
create mode 100644 index.html
create mode 100644 verylargefile.txt
Successfully rebased and updated refs/heads/main.
$ git log
commit 574ec7e5d7d7a96427e049cad9806cdef724aedd (HEAD -> main)
Author: Ursula Clarke <email@example.com>
Date: Wed Jan 13 18:31:28 2021 +0100
Implement new design for homepage. Add .gitignore file for Sass folder.
|
Git Rebase
Developers often hesitate to use git rebase due to its ability to permanently delete files from the codebase.
As seen earlier, git rebase can organize and even remove code. But what if you need to permanently delete a file from history?
I encountered a situation where a large file was accidentally committed and went unnoticed during code review. It slowed down repository cloning significantly! Removing it wasn’t simple due to other valuable code in the same commit.
After locating the problematic commit, check it out:
1
2
3
4
5
6
7
8
9
10
11
12
13
| $ git checkout ce861e4c6989a118aade031020fd936bd28d535b
Note: checking out 'ce861e4c6989a118aade031020fd936bd28d535b'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b <new-branch-name>
HEAD is now at ce861e4 Add CSS styles
|
Remove the file or make necessary code edits, leaving the desired code intact.
1
2
3
4
5
6
7
8
9
10
| $ rm verylargefile.txt
$ git status
HEAD detached at ce861e4
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
deleted: verylargefile.txt
no changes added to commit (use "git add" and/or "git commit -a")
|
Stage the deleted file using git add -A so Git knows to remove it. Then, run git commit --amend -v and edit the commit message as prompted.
Next, run git rebase --onto HEAD <commit-id> main. This might lead to merge conflicts, requiring manual resolution:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| $ git add -A
$ git status
HEAD detached at ce861e4
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
deleted: verylargefile.txt
$ git commit --amend -v
[detached HEAD 7c9516a] Add CSS styles
Date: Thu Jan 14 14:43:54 2021 +0100
3 files changed, 9 insertions(+), 2 deletions(-)
create mode 100644 css/common.css.map
delete mode 100644 verylargefile.txt
$ git status
HEAD detached from ce861e4
nothing to commit, working tree clean
$ git rebase --onto HEAD ce861e4
First, rewinding head to replay your work on top of it...
Fast-forwarded HEAD to HEAD.
|
Open the conflicting file in your text editor. Git marks the two versions – one between <<<<<<< HEAD and the equals signs, the other between the equals signs and >>>>>>> Add index file. Choose the desired version or edit accordingly.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| <p>
Toptal was created by engineers. We are entrepreneurs, all passionate about
working with top tech talent and exciting companies from all over the world.
</p>
<<<<<<< HEAD
<p>
Toptal connects the top 3% of freelance talent all over the world.
</p>
</main>
</body>
</html>
=======
</main>
</body>
</html>
>>>>>>> Add index file
|
Save the edited file and run git add filename followed by git rebase --continue. If there are no further conflicts, use git rebase --skip. Large gaps between commits might make rebasing time-consuming.
Patience is key, especially in large teams. Seek a second opinion and consult the original commit author(s) when possible.
Remember, merge changes relate to the specific commit, not your latest changes. Preserve the historical context of the commit.
Finally, be mindful of spaces and end-of-line characters as they can cause merge conflicts.
More Than Just Commit and Pull
Git offers much more than meets the eye. Share these invaluable features with newcomers to enhance their workflow and efficiency.
For further learning, explore Toptal’s Git Tips and Practices page.
