Git (out)
The only kind of VCS that matters
Git is a version-control system that tracks changes in the source code and can do so many different things at once to produce a single, very reliable way to keep track of work. Not only does git keep the files in a repository, it allows members to keep the repository in their computer as if it were just another file. As members contribute they can update all they want and just add their contributions very quickly.
So enough praising of git and let’s get right into it.
git Commands
git init
To first initialize a git repository we can use “init”. This will initialize a git repository on the current directory.
git clone
If a repository already exists, one can simply clone the https using “git clone <https of repo>” to copy the repo over to the local environment, set up the repository and setting up a remote to its origin (the original https of the repo).
git remote
When using git, we mostly work on the folder in our local environment/PCs, but when it comes time to connect to the internet to send our work, it will be done via remote. Previously we have already shown that the origin should be where the original repository is, but you could add more remotes to connect to other repositories. For example in our AP class we pulled from the origin but pushed to our own individual repository.
git pull
git is a version control system designed for teams. It only makes sense that you’re not the only one working on your jobs. So when the repository gets updated, you would pull the changes other people have made to it so that you are working constantly on the most updated model. Just “git pull <name of the remote> <name of the branch you want to update>” and it should be done.
git push
Remember when I said it was only natural that everyone works in a team? Yeah it’s your turn now. When you’re done with your local work, you can push the changes to the online repository. To do so, simply “git push <name of the remote> <name of the branch you want to update>” and it should be done.
git branch
But here arises a problem. Pushing pulling all from the same branch would be problematic as every time someone pushes, you have to pull again before you can continue or before you can push your work. They may have even edited your work! The solution is to work on different branches, having one branch for each department or division of work. The end result is a merger of these branches.
The git branch command itself creates a new branch which is essentially a copy of the current branch. It does not change to that branch however.
git checkout
Now that we’ve made a new branch, let us move to it. Simply “git checkout <branchname>” or, if you don’t want to git branch first, doing “git checkout -b <branchname>” so that you will move immediately to a newly made branch.
git merge
When we’re done, we will merge. Now that it’s merged, sometimes a file has been edited by two people at once upon which then a conflict will occur. The user will then decide who’s edits will be accepted or to custom edit.
git stash
git stash is used when we want to store commits, believing that it will do better to be used/discarded in the future. It is simply a stack that we push and pop changes into. Remember that it is branch-specific and each branch has individual stashes that doesn’t have the stash of the other branches.
How to use “git stash push” to push current changes, git stash pop to unstash and apply changes and finally git stash list to list all the changes that you have stored.
git status
git status is used to see the current branch’s changes and status.
git reset
We can undo commits using the reset function. Wanton use of this is very much recommended as it will be hilarious when you destroy your team’s repository.
“git reset HEAD~1 --hard”
This removes your team’s last 2 commits. --soft would just undo the commits, not remove them from the files itself.
git rebase
Rebase can also be used to integrate changes into a single branch, similar to merge. It allows for parallel development of two or more branches. When we want to merge our branch with their now commit-filled branch, some errors or just a lot of conflict can occur. The way to avoid this is to use rebase, where the root of our branch is moved onto the other branch and having the changes there to be brought back to our branch. The final result is that our branch is fully updated with their stuff as well. Conflicts may emerge, but those are easily solvable this way.
“git rebase <target branch>
git revert
So you wanna remove a commit? the git revert command will make another commit that will revert the changes back to the commit we specified. In this term, the commits still go forward and we aren’t changing the commit history.
“git revert <commit hash>”
Do we use git in our project?
YES.
Conclusion
Use git. Is good.
