-
Notifications
You must be signed in to change notification settings - Fork 7
Using the Git Workflow
First, make sure that Git is installed. (If you ran the setup_conda.sh script and are going to be doing everything through lemur.montclair.edu, then you can just use the git installation that I referred you to in an earlier email, i.e., there will be no need to download and install git on your local computer. But, of course, you can always do that, too, if you wish. You can have multiple clones of a repository in different places.) You can download a GUI-based application for Windows here and a version for OSX can be found here. Both versions include GUIs and, thus, I can't help you with specifics about how to use them. However, they may also include a command-line interface, in which case much of what I present below will be usable. However, the command names will probably closely correspond to functionalities within the GUI interface, so you might still get something useful from the descriptions.
Second, you will want to clone the project into a local space on your computer. In the terminal, cd into the directory you wish to install the folder and then run the following command:
git clone https://github.com/mulhod/reviewer_experience_prediction.git
After this command completes, you will have a new directory in the current directory named "reviewer_experience_prediction". This directory will be accessible like any other folder on your computer.
Let's say that you create a new file (or edit an existing one), for example you create a file called CHANGELOG in the main folder. Any edits you make locally will stay that way until you decide you're ready to "push" your changes to the remote repository. First, however, you must add your edited files to a "staging" area and then "commit" them as changes. You would run the following command for the changed files (from within the project directory, so make sure you're cd'ed into it):
git add CHANGELOG
Running the command git status afterward will show you which files have been added to the staging area, ready to be committed. To commit the changes, run the following command:
git commit -m "Created new file to keep track of changes"
Provide a description between the quotes since this message will be attached to this particular commit, i.e., the "state" of the project at the point you made the commit.
Now, your changes have been committed and your local repository clone is ahead of the remote repository by one commit. In order to bring the remote repository up to speed, you will have to "push" your commit to the remote repository. You can do this by running the following command:
git push
If you're doing this for the first time, git will complain that you do not have an upstream repository set and it will suggest a command for you to run instead. This is git's way of telling you that it does not necessarily know where you want to push your changes. So, you will have to run the following command the first time:
git push --set-upstream origin master
This push command sets the up-stream repository that your local clone is connected to to be the master, i.e., "main", branch of the remote repository, which you can see on the GitHub website. Afterwards, run git push again, which should prompt you for your GitHub credentials, and this should push your changes successfully. After this, you will be able to use git push without running the other command (but you will probably have to enter your credentials every time).
Note that, just as there will be times that you have made a commit and the remote repository will be behind your clone as a result, there will also be times when somebody else has made a commit and pushed their changes to the remote repository and your clone will be behind. Thus, it is important to frequently "pull" changes from the remote repository. You can do this by running the command git pull. I like to do this especially right before I make a commit/push so as to avoid conflicts, which should in most cases be resolved automatically by git.