Git is a free and open-source distributed version control system.
Install git and create a GitHub account
- more about how to install git – here. There is a GUI option to use git, but I would recommend start (and probably stick with CLI)
- Create GitHub account here
install git in Linux:
sudo apt install git-all
Set your user name and email address
every Git commit uses this information, and it is been added into the commits you start creating:
git config --global user.name "Dmitry Golovach" git config --global user.email firstname.lastname@example.org
Create a local git repository (project folder)
mkdir sandbox cd sandbox git init ==> Initialized empty Git repository in /home/cisco/sandbox/.git/
The idea: make changes in the repository, if it is in the state we want to record – commit.
Each file in the working directory can be in one of two states (check the status with git status command):
- git knows about these files
- can be unmodified, modified, or staged
- everything else
The idea: change files – selectively stage these modified files and then commit all those staged changes
Once we add a new file – it will be untracked (it is new and uknown for git), but git recognizes that new file was added:
Staging environment – git add
To add a file to a commit, we first need to add it to the staging environment using git add command:
Commit – git commit
Now files are ready to commit using git commit -m “message” command. It’s good to add a comment about what has been changed in this commit.
If we need to keep track of own code locally – don’t need to use GitHub. But it is always good to have a copy of repository somewhere else or for work in team => GitHub
GitHub – git push
Create a new repository and you can keep it Private (later change it to Public) or Public:
Quick notes how to work with GitHub:
push the commit in your branch to your new GitHub repo.
Note: if you have 2FA enabled (you probably should), follow the “Creating a personal access token for the command line” to use a Personal token as a password:
git remote add origin email@example.com:dagolovach/sandbox.git git push -u origin master
As result files have been pushed to the GitHub:
Work with repository and files, once done
#Add the file to your local repo. Files are ready to be committed git add <filename> #Remove from staging (unstage) git reset HEAD <filename> #Commit the tracked changes. Files are aready to be pushed to remote repo git commit -m "message" #Remove commit and modify the file git reset --soft HEAD~1 #Push the changes in your local repo up to the remote repo git push -u origin master
git clone <url>: take a repository stored on a server (like GitHub) and downloads it
git add <filename(s)>: add files to the staging area to be included in the next commit
git commit -m "message": take a snapshot of the repository and save it with a message about the changes
git commit -am <filename(s)> "message": add files and commit changes all in one
git status: print what is currently going on with the repository
git push: push any local changes (commits) to a remote server
git pull: pull any remote changes from a remote server to a local computer
git log: print a history of all the commits that have been made
git reflog: print a list of all the different references to commits
git reset --hard <commit>: reset the repository to a given commit
git reset --hard origin/master: reset the repository to its original state (e.g. the version cloned from GitHub)
More on Git
- ‘Branching’ is a feature of Git that allows a project to move in multiple different directions simultaneously. There is one master branch that is always usable, but any number of new branches can be created to develop new features. Once ready, these branches can then be merged back into master.
- When working in a Git repository, HEAD refers to the current branch being worked on. When a different branch is ‘checked out’, the HEAD changes to indicate the new working branch.
- When merging a branch back into master, there is the possibility for merge conflicts to arise. These can be resolved in the same way discussed in Lecture 0.
- Some Git commands related to branching:
- git branch : list all the branches currently in a repository
- git branch <name> : create a new branch called name
- git checkout <name>: switch current working branch to name
- git merge <name> : merge branch name into the current working branch (normally master)
- Any version of a repository that is not stored locally on a device is called a ‘remote’. ‘Origin’ is used to refer to the remote from which the local repository was originally downloaded from.
- Some Git commands related to remotes:
- git fetch : download all of the latest commits from a remote to a local device
- git merge origin/master : merge origin/master, which is the remote version of a repository normally downloaded with git fetch, into the local, preexisting master branch
- Note that git pull is equivalent to running git fetch and then git merge origin/master
- A ‘fork’ of a repository is an entirely separate repository which is a copy of the original repository. A forked repository can be managed and modified like any other, all without affecting the original copy.
- Open source projects are often developed using forks. There will be one central version of the software which contributors will fork and improve on, and when they want these changes to be merged into the central repository, they submit a ‘pull request’.
- A pull request can be made to merge a branch of a repository with another branch of the same repository or even a different repository. Pull requests are a good way to get feedback on changes from collaborators on the same project.
- Note that forks and pull requests are both GitHub specific features.