Creating a git repository
Creating a git repository is a very simple. Git tracks all of your file changes by storing data about the state of the files in a hidden directory '.git' at the top level of the repository.
> cd some-directory > git init Initialised empty Git repository in some-directory
Cloning an existing repository
In reality you won't usually be initialising a repository from scratch, you will more than likely be 'cloning' a repository from some existing location. This will give you a full copy of the repository. This is achieved with the
git clone sub command. Here is an example of how that might look if you were cloning a repository from GitHub:
> git clone https://github.com/SiteMorph/protostore.git
You can confirm that your clone of the repository was successful using the
git status sub command.
> git status On branch master Your branch is up-to-date with 'origin/master'. nothing to commit, working tree clean
There are a few things to unpack in the status:
- Git uses 'branches' to track multiple histories of a repository. There is a convention to use the 'master' as the parent / source for all other branches. Many git based workflows may also use the master branch as the destination for when changes are merged before being deployed.
- There is also message about being up to date with
origin/master. Origin is the remote machine label from where we just fetched the repository state. You can see what these repository locations are by calling
git remote -v. Again by convention 'origin' is the default label for the remote location just cloned.
- Nothing to commit is self explanatory. There are no changes to files being tracked by git.
Adding files to be tracked
After creating a repository with
git init no actual files are going to be tracked by git so let's create one and add it to the files git is tracking:
> touch untracked.md > git status On branch master Your branch is up-to-date with 'origin/master'. Untracked files: (use "git add <file>..." to include in what will be committed) untracked.md nothing added to commit but untracked files present (use "git add" to track)
Adding your file to the set of those tracked by git is trivial with the
git add sub command.
> git add untracked.md > git status On branch master Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git restore --staged <file>..." to unstage) new file: untracked.md
Now we have a repo with a single tracked file which has uncommitted changes.
Committing a change to the log
Now that a change has been added to a file it's time to commit the change using the
git commit sub-command. These sub-commands have a lot of options, you will pick up as you learn them. You can find out more about them using the
git help commit sub command. Complete the prompts and you will now have a new checkpoint state in the log. Once the commit is in the log you can see the checkpoint commit states by using the
git log sub command.
> git log commit 8824fbd3e6djf8s5b20c893c9fe12d6dafecd647 (HEAD -> master) Author: Bob Builder <email@example.com> Date: Wed Jan 18 22:13:58 2023 +0000 Added a new file.
Resetting the state of the repository to some historical state
One of the most common questions about git is how to uncommit a set of changes. Git has a simple sub-command for this
git reset however it's often not what you want to do as changes will be lost.
> git reset --hard 8824fbd3e6djf8s5b20c893c9fe12d6dafecd647 HEAD is now at 8824fbd Some commit message
Resetting a repository is a rather destructive activity and is almost the opposite of the point of having a version control system. Rather than resetting hard to a given commit, a more common workflow would be to copy the current branch with local changes. Above the HEAD is tracking the 'master' branch on the local copy of the 'origin' repository. Creating a copy of the branch before resetting it is probably a good idea. This is achieved using the
git branch -c <your-new-branch-name>. You can then reset 'master' while keeping your changes on a different branch of the code. You can switch to that branch using the checkout sub command like
git checkout <your-new-branch-name> and work there witout disturbing the master branch.
Pushing your changes to the origin repository
After some time you will build up a change log on your local repository and you will want to push it to another location to share or backup your changes. This is simple using the push sub command like
git push origin. Note here that the origin remote location label is used again to push the current branch name to the remote host on the same branch name.
This post is intended to give you a flavour of the most basic commands, if you are interested in specific issues please comment below.
Post a Comment