3. Commit change

Posted on by

git commit is a fundamental command in Git for capturing snapshots of your project’s changes and maintaining a version history.

  • Creates a permanent record of your project’s state at a specific point in time.
  • Allows you to revert back to previous versions if needed.
  • Facilitates collaboration by tracking individual changes and who made them.
  • Provides a clear history of the project’s evolution.

How it works:

  1. Changes in Working Directory: You modify files in your project using a code editor or IDE. These changes initially exist only in your working directory, which is your local development environment.
  2. Staging Changes (Using git add): Git doesn’t automatically track changes. You need to explicitly tell it which modified files you want to include in the next commit using git add.
    • Syntax: git add <filename(s)>
      • Replace <filename(s)> with the specific files you want to commit. You can use wildcards (e.g., git add * for all modified files) or patterns (e.g., git add src/*.cpp for all .cpp files in the src directory).
  3. Creating the Commit (Using git commit): Once you’ve staged the desired changes, use git commit to create a snapshot.
    • Syntax: git commit
      • Git typically opens your default text editor for you to write a commit message.
  4. Commit Message: This message is crucial. It should be concise, clear, and informative, summarizing what changes were made and why. Good commit messages help you and others understand the project’s history.

Note that git commit does not commit changes to remote repository, it just first step.

Additional Notes:

  • Use git status to see the status of your changes (modified, staged, untracked).
  • If you need to modify the staged changes before committing, use commands like git rm (remove from staging) or git checkout (revert changes in working directory files).
  • You can skip staging with git commit -a -m "message" to directly commit all modified and tracked files, but it’s generally recommended to be selective with staging for better control.

Update remote repository

The command git push origin is a vital for sharing your local project’s changes with a remote repository, typically hosted on platforms like GitHub, GitLab, or a self-managed server.

It’s purpose:

  • Uploads your local changes (commits) to the remote repository named origin. This is the conventional name for the remote, but you could have used a different name during setup (e.g., upstream, backup).
  • Makes your changes accessible to collaborators or for backup purposes.

What happens when you run git push origin:

  1. Verification: Git first verifies that you have a connection established with the remote repository origin.
  2. Authentication: It attempts to authenticate you with the remote repository using your credentials (username and password or SSH key). You’ll need to have set up these credentials beforehand, typically following the instructions provided by your hosting platform.
  3. Pushing Changes: If authentication is successful, Git starts uploading your local commits that haven’t already been pushed to the remote repository origin. It typically pushes them to a branch on the remote repository with the same name as your current local branch.

Alternatively you can use git push origin [branch] to push file of a local branch.

Important Considerations:

  • Existing Remote Branch: If a branch already exists on the remote repository origin, your push operation will typically attempt to:
    • Fast-forward merge: This is the simplest scenario where your local branch is ahead of the remote branch with new commits. Git seamlessly integrates your commits onto the remote branch, essentially extending its history.
    • Merge conflict: If there are conflicts (i.e., changes made to the same lines of code in both the remote and your local branch), the push operation will be halted, and you’ll need to resolve the conflicts manually before retrying.
  • New Remote Branch: If there’s no branch on the remote repository yet, your push operation will create a new branch named branch on origin and push your local commits to it.

Alternatives and Best Practices:

  • It’s generally a good idea to be sure your local branch is up-to-date with the remote branch before pushing using git pull origin [branch] to avoid conflicts.
  • You can also use more specific branch names for pushing to different branches on the remote repository. For example, git push origin feature/new-feature would push your local feature/new-feature branch to the remote origin repository.

Example..

$ touch file2.txt
$ git add file2.txt
$ git commit -m "adding file2.txt"
[b2 5245dc0] adding file2.txt
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 file2.txt
$ git push origin b2
Branch 'b2' set up to track remote branch 'b2' from 'origin'.
Everything up-to-date