Git Basics: Staging Files
● Command: git add <path|file>
● Staging Area (aka Index) allows you to selectively choose which files
will be committed and which will NOT (e.g debug files)
● .gitignore files can be used to automatically exclude files
Git Basics: Excluding Files with.gitignore
● Each line specifies a file pattern to ignore.
● Many ways to implement .gitignore
(e.g. can have per-directory .gitignore files)
● But most common is to put in top-level directory of repo.
[anandg anandg@ /home/anandg (master)]$ cat .gitignore
venv/
*DS_Store
keep
.idea
*.log
*.pid
*.pyc
*.swp
*~
.#*
\#*
Git Basics: Checking File Status
● Command: git status
● This command shows files that are tracked by the repo…
and files that are not tracked by the repo (i.e. untracked)
● This command also shows files that are staged for next committal
Git Basics: Committing Files
● Command: git commit -m
● Commits ONLY files in the Staging Area / Index
● Committing creates a SNAPSHOT of the entire repo.
GIT doesn't use patches / deltas to track changes but rather entire snapshots
Git Basics: Viewing Commit History
● Command: git log
● Run this command to see the commit history of the repo (for the given branch)
[anandg anandg@ /home/anandg (master)]$ git log
commit 46968d4d20b636ada053571202317c01a4eb4d50 (HEAD -> master)
Author: Anand G anandg@google.com
Date: Wed Oct 4 02:17:11 2017 -0400
Demo of GIT workflow
commit fc813cde051518f7343d386799e24f279df7c039
Author: Anand G anandg@google.com
Date: Mon Oct 2 18:36:22 2017 -0400
Modified TestScript.py to allow for log demo.
Git Basics: Viewing a Particular Commit
● Command: git show
● Run this command to see all diffs from that commit
● The sha1hash is used to identify a commit.
● GIT actually uses SHA1 hashes to verify the integrity of the files.
● Immediately, GIT knows if the content of the a file is corrupt or not.
NOW,
Previously, we saw the "commit fc813cde051518f7343d386799e24f279df7c039"
To run this command, git show fc81
Git Basics: Publishing Changes to Git Server
● Command: git push [ [] ]
● This command pushes your changes (over the network) to a remote repository ( often the origin )
● origin is a shorthand notation of the repository from which you cloned
[anandg anandg@ /home/anandg (master)]$ git config -l | grep origin
remote.origin.url=git@github:testrepo.git
remote.origin.fetch=+refs/heads/:refs/remotes/origin/
branch.master.remote=origin
Git Basics: Pulling Changes from Git Server
● Command: git pull [ [] ]
● This command pulls your updates (over the network) to your local repository.
● Contrary to popular belief, git pull is NOT the inverse of git push. The git fetch command is. Both git push and git fetch don't involve any merging.
● This command is really two commands built into one:
git fetch + git merge
[anandg anandg@ /home/anandg/testrepo (master)]$ git pull
remote: Counting objects: 226, done.
remote: Compressing objects: 100% (126/126), done.
remote: Total 226 (delta 119), reused 180 (delta 100)
Receiving objects: 100% (226/226), 116.80 KiB | 1.07 MiB/s, done.
Resolving deltas: 100% (119/119), done.
From github:testrepo
4fc8080..3e06595 master -> origin/master
Updating 4ed9080..3b07595
Fast-forward
bin/lib/file1.py | 19 ++-
bin/tools/file2.py | 25 ++-
.
.
.
lib/file3.py | 2 +-
lib/file4.py | 132 ++++++++++++++
requirements.txt | 1 +
24 files changed, 1007 insertions(+), 252 deletions(-)
create mode 100755 bin/file5.py
Git Basics: Dangers of Git Pull
● The one BIG downside of git pull is that it does NOT allow you to review any changes before it merges into your current branch
● git fetch updates your remote tracking branches under refs/remotes/
● git merge
● If the project practice code reviews, this isn't as big of a problem. But it is * STRONGLY * recommend to do one or the other (i.e. code reviews or fetch reviews)
● Workflow
git fetch origin/
git log origin/
git diff
git merge origin/
● We'll discuss more later with branches...
No comments:
Post a Comment