git CLI Step By Step Process

In general, the process to make changes to our repository is:

There are numerous other steps you can take in between to verify your work, which we will denote as (optional) steps in between the primary mandatory steps.

You must do all of these steps in order, otherwise you might cause commit conflicts.

For starters, make sure you are on Anvil and in your cloned repository directory and checked out on the main branch. To do this, in the terminal on Anvil, do:

You should see a list of branches displayed, along with an asterisk next to the one you are currently checked out on. Be sure the asterisked branch is main before going on further. If it is not, you can "checkout" (switch to) that branch by doing:

Now let’s make sure the repository that we have locally is the same as the one that is at the origin. origin is relative depending on where you are pushing and pulling from, but in our case, we are always referencing the repository on github.com, not our locally cloned copy. Origin can be set to whatever you want it to, but typically Git users will set the origin to be the remote repository they originally cloned from.

Now, let’s get all the changes that other users have made to the origin repository to our local repository by using git pull:

You will see a brief summary of changes, or a notification that the repository is already up to date.

We are now ready to make coding changes.

Any of the files that are in your repository folder are being tracked by Git, including all the subfolders. For instance, you can open up a file in Jupyter Lab, make edits to it and save it. The amount of edits you make are up to you, but the general rule of thumb is that if you can’t explain the changes you made in less than 5-10 words, you might want to split up your changes into multiple separate commits.

You can check to see which files Git noticed you made changes to do by doing

You will notice that there are untracked and tracked files. Untracked just means they haven’t been added to staging yet. Staging is the list of files that will be added to the next commit. This is a good way to double check that the changes you made were noticed by Git (sometimes, if you forget to save a file, the changes might not show up here).

We made changes to our files and we are ready to push them. We now have to add them to staging by doing

You can also directly add all the files that are untracked to staging by doing

Maybe you made a mistake, and there was a file you accidentally added to staging. You can use the command below to remove it (back to untracked):

Once again, double check with git status:

Now we have all our files ready to send to origin, and they are in staging. We’ve confirmed with git status that everything is as it should be. Now let’s create the commit:

Describe the changes you made to the repository in the "My Commit Comment". You must use the "" double quotes, but you can have any message you want in there.

We realized we made a mistake on our previous commit, or the comment wasn’t right, etc. Yet we want to keep the changes we made to the file. The code below will remove the commit we just made, but keep the changes on our local repository:

We are ready to send our changes to origin. Go ahead and push:

Congrats! You just sent your changes to the origin for everyone else to see. Now, when they git pull, they will receive your changes to their main branch.

Some users of git prefer to use local branches (that is, their own personal branch) to make edits on, push the changes to, then push the changes from their personal branch to the main branch. This can be helpful if you are pushing complex coding changes to live production Github repositories whose changes impact live services by pushing locally first (and thus keeping track of your changes) and testing locally, then making pushes. You can find an example of this style of branching here.

Once you feel like you’ve got the general Git flow down, it can be convienent to write a simple shell script to run through all the steps of pulling, adding, committing and pushing into a shell script. The script below assumes only one branch is used and that you are the only person working on a file in the repository. If you’ve made changes to a file which others have as well, doing git pull like this might overwrite some of the changes you’ve made.