← Back to Git Course | Chapter 4: Remote Repositories | Lesson 2 of 11

GitHub Edit Code

Once a repository is cloned, editing its files is just normal local file editing -- Git compares your changes against the last commit, and staging plus committing is how those local edits become part of history before they're ever pushed anywhere.

In this page:

  1. The Local Working Directory After Cloning
  2. Making Changes to Cloned Files
  3. Checking What Changed with git diff
  4. Staging and Committing Local Edits
  5. Keeping Local Edits in Sync Before Pushing
Syntax
bash 
git diff
git diff --staged
git add file_name
git commit -m "message"

The Local Working Directory After Cloning

Cloning a repository downloads its full history and checks out a working copy of every tracked file into a local folder, so immediately after cloning, the working directory, staging area, and remote all contain exactly the same content.

Example: The Local Working Directory After Cloning

bash 
git clone https://github.com/user/repo.git
git status

Making Changes to Cloned Files

Any text editor or IDE can be used to change a cloned file's content, since Git only cares about what's on disk -- as soon as a tracked file's content differs from the last commit, Git marks it as modified in the working directory.

Example: Making Changes to Cloned Files

bash 
echo "Updated content" >> README.md

Checking What Changed with git diff

git diff compares the current working directory content against the last commit and prints the exact lines that were added or removed, which is the fastest way to review an edit before deciding whether to stage it.

Example: Checking What Changed with git diff

bash 
git diff

Staging and Committing Local Edits

Local edits only become part of the repository's history once they're staged with git add and recorded with git commit -- until that point, changes exist only in the working directory and would be lost if the folder were deleted.

Example: Staging and Committing Local Edits

bash 
git add README.md
git commit -m "Update README"

Keeping Local Edits in Sync Before Pushing

Before pushing local commits, running git fetch (or git pull) checks whether the remote has moved ahead in the meantime, and rebasing or merging local work onto the latest remote history avoids a rejected push and keeps the shared history easy to follow.

Example: Keeping Local Edits in Sync Before Pushing

bash 
git fetch origin
git rebase origin/main
Related Topics

GitHub Remote Branch · Git GitHub Introduction · Git Code Review · Git VS Code Integration

{# common_mistakes/chapter_summary/browser_support: on Hindi pages the view already swaps in the hi_ translation fields (or blanks these out if untranslated), so this renders correctly for both languages without a lang_code check here. #}
Common Mistakes
  1. Editing the files and expecting GitHub to see the change, when you must commit and push first.
  2. Running git diff after git add and seeing nothing, because staged changes need git diff --staged.
  3. Editing a file in the wrong clone, or the wrong folder, and not seeing the change in git status.
🔒

Chapter Quiz — Complete all 11 topics to unlock

0/11 topics done

Complete these topics first:

← Previous Lesson Git Remote Introduction Next Lesson → Git remote Command

Login to run this code

C/C++/Java/PHP execution requires a free account. Your code is saved — you'll land right back in the editor after logging in.