Here is a basic overview of how Git works:
- Create a “repository” (project) with a git hosting tool (like Bitbucket)
- Copy (or clone) the repository to your local machine
- Add a file to your local repo and “commit” (save) the changes
- “Push” your changes to your master branch
- Make a change to your file with a git hosting tool and commit
- “Pull” the changes to your local machine
- Create a “branch” (version), make a change, commit the change
- Open a “pull request” (propose changes to the master branch)
- “Merge” your branch to the master branch
init means initialize. The command sets up all the tools Git needs to begin tracking changes made to the project.
git clone creates a local copy of a project that already exists remotely. The clone includes all the project’s files, history, and branches.
git branch shows the branches being worked on locally.
We have a Git project. A Git project can be thought of as having three parts:
- A Working Directory: where you’ll be doing all the work: creating, editing, deleting and organizing files
- A Staging Area: where you’ll list changes you make to the working directory
- A Repository: where Git permanently stores those changes as different versions of the project
You can check the status of the modified file in working directory with “git status”.
In order for Git to start tracking files need to be added to the staging area we need to add the files to staging area with:
git add filename
we can check the differences between the working directory and the staging area with:
git diff filename
A commit is the last step in our Git workflow. A commit permanently stores changes from the staging area inside the repository.
git commit -m “Added file line”
Often with Git, you’ll need to refer back to an earlier version of a project. Commits are stored chronologically in the repository and can be viewed with:
One of the common undos takes place when you commit too early and possibly forget to add some files, or you mess up your commit message. If you want to try that commit again, you can run commit with the
$ git commit --amend
This command takes your staging area and uses it for the commit. If you’ve made no changes since your last commit (for instance, you run this command immediately after your previous commit), then your snapshot will look exactly the same and all you’ll change is your commit message.
The same commit-message editor fires up, but it already contains the message of your previous commit. You can edit the message the same as always, but it overwrites your previous commit.
As an example, if you commit and then realize you forgot to stage the changes in a file you wanted to add to this commit, you can do something like this:
$ git commit -m 'initial commit' $ git add forgotten_file $ git commit --amend
After these three commands, you end up with a single commit — the second commit replaces the results of the first.
git reset HEAD <file>
How can you easily unmodify it — revert it back to what it looked like when you last committed (or initially cloned, or however you got it into your working directory)?
git checkout — <file>
It will discard changes in working directory for the file and undo the changes made after the last commit/clone.
You should also realize that this is a dangerous command: any changes you made to that file are gone — you just copied another file over it. Don’t ever use this command unless you absolutely know that you don’t want the file.