Git

Using Git to access, edit, and publish changes

Basics

Clone

To access any repositories on your PC, the first thing you need to do is clone them.

To clone a repository, you will first need to get its clone URL. First, visit the repository page (Example: https://github.com/tj-uav/repo-name). Then, Click on the Code button, and copy the HTTPS URL.

To actually clone the repository, you will need to open either a Terminal or a Git Bash Console. Next, you should navigate to the directory where you want to clone the repository. Here, you should run the following command, where <url> is the repository URL you copied from the previous step.

git clone <url>

Now, the repository is succesfully cloned to your PC in your chosen directory.

Pull

When working with a team, there are often new changes made by other team members that you will need to use to continue working. To update your cloned repository's code with the cloud, you will need to pull changes.

The simplest way to pull changes is by simply using this command:

git pull

As long as the terminal or Git Bash Console is open inside a cloned directory, the directory will be updated with the most recent changes from the cloud.

Commit

After you've made a bunch of changes to the cloned repository and want to publish them as a version, you'll need to commit. Simply use:

git commit

This will save your current changes as a version in Git. However, your changes are still not published to the repository, which will require Pushing.

Push

After you have made one or more commits, you might want to publish them to the cloud repository on GitHub. To do this, use:

git push

This will take all your unpublished commits and push them to the cloud.

Branches

Branches are separate copies of the source repo, used to make changes without interfering with another person's changes. You can create branches, switch to a branch (git checkout <branch>), and merge a branch in with the main or master branch, with the official code.

Forking and Pull Requests

Fork

If you want to work on your own version of the current repository (without having to worry about pulling), and then merge it with the actual one, you need to use forking.

On the Repository page, click the Fork button on the top right. This will create a new repository on your account that is linked to the actual one. Now you can make your changes.

Pull Request

If you have made all the changes you need to make on the forked repository, you can create a pull request to merge your changes to the actual one. After an organization admin approves the pull request, conflicts will be removed and your new code will be merged in with the existing repo. You may be asked to add new features, and bugs may be reported for you to fix before your pull request is accepted. Every new commit and push to your repo will add it to the pull request, and will be merged once the pull request is approved.

Common Errors

Merge Conflicts

Merge conflicts are one of the first errors you will run into when using Git. It may seem you messed up badly at first, but it just means that Git can't correctly reconcile the differences when two branches have merged. Instead, you would have to manually resolve the conflicting changes.

Here is how you can know where there could be one or more conflicting files:

git status

Here is what you would see when a merge conflict happens in a file:

<<<<<<< HEAD
hello world
=======
bye world
>>>>>>> new-feature

Everything in between the < and the = signs is the change in the current branch (the one you are merging your changes into). Everything in between the = and the > signs is the change coming from the branch you want to merge into the current branch. Now it is up to you to decide which change you would like to accept or you can edit the file to combine the changes. When you do this, remove the markers that indicate the beginning and end of the changes, leaving only the code you want:

bye world

Now you can commit the changes and the message "Resolved merge conflicts" will show. You can now push the changes to the repository with no merge conflict errors.

Undo Commit

If you're reading this, that means you've really screwed up. Not in making a frivolous commit that contains something it shouldn't have, but rather in the time, git punishes you for such a mistake.

Now here's where you might be lucky. If you didn't push to GitHub yet, all you need to do is the following:

git reset --soft HEAD~1

This here will undo that last commit, as if it never happened. The --soft flag keeps everything that would have been pushed (i.e. pre-push state). To revert to what the previous push would have looked like without the changes you made, replace --soft with --hard.

Now let's say you already pushed to the GitHub ("remote") repositories. If it's a non-sensitive mistake, make another commit that fixes it. Not completely sure what constitutes a sensitive mistake? Basically no large files , passwords, or anything that reveals a major security flaw.

It's best practice to just fix the mistake, but if need be git revert also generates an automatic commit revert. This won't remove the commit completely; rather, just undo the changes. It's an easy way of going back without loosing progress or interrupting anyone else's workflow. This means files no longer part of the repository will still be downloaded, hence why large files have to be removed with the next steps.

Had to get here? Here's where it starts to become a total pain.

Any steps from here on should be additionally accompanied by a ping to everyone on Discord saying that this change has been made. This WILL affect the workflow of all users and means EVERY SINGLE PERSON will have to make sure they didn't pull what you had now since it was completely removed. And yes, this is perhaps one of the only times where it is completely appropriate to perform an @everyone ping.

Remove previous commit

git push <repo clone address> +<commitID to remove>^:<branch>

This should in theory push the branch back to commit and practically destroy the very existence of the commit. There are other ways to do this but this is probably the safest method only if you know no other commits were made up to this point.

Remove older commit

Let's say you realize that it wasn't the latest commit but instead one that's a bit older. Start out with the following, where commitID is the ID of the commit that you want removed:

git rebase -i <commitID>^

This brings up an editor with a list of all the commits made since that one.

his editor's probably vim, which can be notoriously difficult to use sometimes. To be clear, this is not vim which can be found rather commonly, so it might be even more unfriendly than some users realize. vim basics still apply. Though it can be incredibly powerful, don't worry about needing to learn how to leverage it.

Use the arrow keys to put your cursor on the line that has the commit ID of the commit you want to remove, then type dd. Don't worry, you won't add anything, as you aren't in insert mode. Then type :wq (command, write, quit) and press enter to exit.

Finally, force push the branch with the following command.

git push <branch> -f

As mentioned earlier, an @everyone ping is appropriate to ensure all programmers pull this edit and make sure your force push doesn't break their code. To be clear force pushing should be reserved for the most terrible of situations.