111 Week 16/17 - Using Git and Gitlab Flashcards
Git Repository
A repository hosted on a server e.g., by GitHub, GitLab etc.
Local repository
The git repo can be cloned onto your computer where you can make changes.
This is a local copy so you will not change the git repo unless you commit changes and push to the repository.
git clone
Creates the local copy of the git repository which you can access and code on.
Takes a parameter to know which repo is being cloned.
E.g., git clone https://scc-source.lancs.ac.uk/username/reponame
git pull
Will pull any changes to the git repo onto your local repo.
You should do this every time before making changes so that you are working on the most up to date version of the repo.
git add command
Takes a file name as a parameter.
Adds the file to the local repository. Means that it will be included in the git repo when the user commits and pushes to the server.
E.g., git add Driver.java
git commit
Used to commit a change or set of changes to your local repo.
Acts as a bookmark to to show what changes have been made or as a place to move back to when looking through version history.
parameters:
-m “message”: adds a message to the commit to explain what was changed. Messages should always be relevant and clearly explain the changes made.
-a adds any files that have not been added from the directory to the git repo.
E.g., git commit -m “added background image to level 1”
git push
Pushes all changes made on the local repo to the git repo. Means that all your changes are not available to be viewed on the GitHub page. Any git pull commands will pull your changes to their local repo.
Has 2 parameters:
- where to push to (usually origin - wherever you cloned from)
- the branch to push to
E.g., git push origin main
git status
Will show the status of your local repo compared to the Git repo.
Will show if any new files have been added or any existing files have been changed.
.gitignore
To specify if you don’t want to include certain files or types of files in the git repo, use a .gitignore file.
Add file names to the .gitignore file so they will be ignored by commit and push commands.
Can use wildcards to stop certain file types to be excluded such as .class files as you don’t want these in the repo, only source code.
E.g.,
(inside a .gitignore file)
notes.txt
*.class
Merge conflicts
Happens when someone has updated the file on the server that you have edited locally.
Files in conflict will have both copies of lines of code that differ. Fix this by either choosing the version of the lines you want to keep or by editing the code until it is not in conflict anymore.
Issues
Can create an “issue” on the git page for the repo to specify an issue with the project. Can comment on issues and mark them as read. Can assign developers to an issue.
Helps identify what needs to be worked on, if anyone is working on it and if it has been solved yet.
Branches
Help support longer running changes by allowing developers to “branch” off from the main code.
There is always a main branch in a repo which is the definite “true” version of the code.
Creating a branch creates a subcopy that diverges from the main code at a given commit. This branch can then be worked on independently of the main branch then merged back into main later on.
git branch
Lists the branches in a repo
git branch branchName
Creates a new branch from main called branchName. Starts at the most recent commit pushed to the repo.
git checkout branchName
Switches to the branch with name branchName
git push origin branchName
Pushes commits to the branch with name branchName
git checkout main
get merge branchName
Changes to main branch then merges main with the branch with name branchName.
Possibility for conflicts so need to resolve any that occur as a result of merging branches.
Fork
A deep copy of a repository.
Allows developers to create a copy of the whole repository that is completely separate from the original repository.
The fork is created on the developers account/organisation, not on the account/organisation that hosted the original repo.
Merge requests
A way of accepting code from a source not trusted enough to be a collaborator but that could still make useful additions.
Anyone with a fork of a repo can request one of the branches on the fork to be merged to the original repo.
After a merge request has been submitted, the main repo collaborators can review the changes, communicate with the person requesting the merge and then accept or reject the request. This is all done through the website.
Continuous integration (CI)
A software development practice where developers regularly integrate their code changes into a central repository.
Each change is verified by an automated build and automated tests.
Allows early detection and fixing of integration issues and ensures code is high quality and reliable.
CI workflow steps
Define the CI workflow: environment, building and testing variables, etc.
1. Developer pushes changes to the version control system (e.g., git)
2. CI server detects the changes and triggers and automated build and test process
3. Results are reported back to the developer.
Continuous development (CD)
The next step in the CI/CD pipeline.
CD makes it so that any code that passes the CI stage is automatically deployed to a beta production environment.
It automates the deployment process, reducing manual intervention, which results on faster and more reliable software delivery.
