These instructions are for connecting your CSE Linux environment (cancun) to your GitLab repo. The following section has more tips and tricks for using git as you work on your hw.
Allows you to access your repo without having to authenticate (i.e., type your password) every time. Constant password authentication can sometimes make gitlab almost unusable.
cancun:
cat ~/.ssh/id_rsa.pub
ssh-keygen -t rsa -C "<netid>@uw.edu"
cat ~/.ssh/id_rsa.pub
For the most part, git has sensible default options and things work as expected. However, if you've never used git before, it will ask / remind you to set some options every time you try to commit or push something. Before starting to work with gitlab regularly, we suggest you enter these commands in a terminal window.
git config --global user.name "Your Name Here"
git config --global user.email netid@uw.edu
git config --global pull.rebase false
Of course you should substitute your own name and email in these commands.
This only needs to be done once and the settings will be retained and
used as defaults in the future.
Any commands shown below should be run from your CSE Linux
environment (cancun)
git clone <repo url>
touch README.md
README.md.git status
README.md.git add README.md
git status: README.md staged for
commitgit commit -m "First Commit"
git status: Your branch is
ahead by 1 commitgit push
Once you have a made a local copy of your Gitlab repository in your
CSE Linux environment, you can now have access to and
make changes to files your repository locally on cancun! However, note that the
repository on Gitlab and the copy in your CSE environment do not
automatically synchronize with each other, so you have an additional
responsibility of keeping both of them up to date (so you don't
have out-of-date copies in either place or lose work if something goes wrong with
your local copy of the repo).
We recommend you use the git workflow described here. (If you are interested in more details, the Git Community Book is a great resource as well).
To update your local copy of the repository with any new information in the Gitlab copy of the repository, type the following command (in your local repository):
[cancun]$ git pull
Commit and add changes from your local copy to the Gitlab repository:
[cancun]$ git pull # make sure your local copy is up to date with Gitlab[cancun]$ git add <files> # stages files to commit to Gitlab. (period character) in
<files> from the top-level git
repository directory to stage all files to be added to
Gitlab repository. (Note: . represents current
directory, so at top-level of the repository, you are
adding and staging all changes in local copy of the
repository!)git add that you do
not want to commit to the Gitlab repository.[cancun]$ git commit -m “<message here>” # add a descriptive message about your update[cancun]$ git push # push your changes to your Gitlab.gitignore
file that list files and file types that will be ignored when updating
the Gitlab repository. This may be particularly useful for not
including executables or object files (.o files),
which is already done for you. You can add more files that you
may not want to include in .gitignore.
Keeping your workspace organized is crucial to keeping your workflow smooth, efficient, and as productive as it can be. By making sure to frequently update your local and Gitlab repository, you reduce the chances of getting into trouble. Nevertheless, you might end up with a “Git spaghetti ball,” so here are some useful survival tips and commands.
Avoid branching, merging, and other complex git structures in your gitlab repo. While these are widely used in large projects and in industry, they are not needed for this class. When not used correctly, these can leave your repo in an unexpected state where new changes seem to disappear or other odd things happen. Keep it simple.
Git, github, and gitlab have enormous user bases and are used for a huge variety of projects. They also have many, many, many features and options and are very complex. Because of that, web searches about git can produce a huge number of potentially off-topic or inapplicable results and, if blindly followed, can leave your repo in strange and potentially very hard to fix states. If you are having problems with your gitlab repo, please contact course staff so we can help you fix things. We deliberately are not taking advantage of many git features to keep things simple and understandable for what we need for this class.
These git commands are ways to manage local changes to your git repository before pushing to your Gitlab repository.
git stash
git stash pop
git stash drop
git reset --hard HEAD
git checkout HEAD -- path/to/file
git reset --soft HEAD~1