Sharing changes on git

Now that the setup is complete it is finally time to work with Git. As stated before, git is a tool for version control and collaboration. Git works by storing the changes that have been made to your files. In the practice repository you will be able to find a document called README.md. We are going to work with this document to practise.

Assignment

---

First open the README.md document in your preferred editor (a plain text editor or IDE). Read the document and make a change of a few lines. Once you're done, save the changes and go back to the terminal to store the changes you made.

Staging

Saving changes on git is done in two steps, the first step is to select which changes need to be stored. This is called staging. Afterwards we actually store the changes by committing.

To see which files are staged run the command;

git status

The red files are not staged, the green files are staged. To see the changes of the files you can run the commands;

git diff [file]
git diff --staged [file]  

To stage or unstage changes you can respectively use the commands;

git add <file>
git restore --staged <file>

for partial commits you can add the -p flag to the add command.

Assignment

---

Stage the changes you made in the README.md file.

Committing

The second step of storing changes is called committing. This step can be seen as boxing all the changes that you have made and labelling them with a message which is called the commit message. This message is to make sure that you, your team members and the TAs know what the changes are without having to go through all the files. You have learned about the conventions for commit messages during the git lecture. To refresh you memory you can look at this guide.

To commit the changes in the terminal you need to enter the command;

git commit -m "your commit message"

You can also add your commit message in an editor by removing the -m and the commit message.

NOTE: The default editor on many systems is vim (which is a very useful tool to learn). If you enter it by accident, use the following key sequence (one by one) to exit: [escape][:][x][enter] (to store changes and quit vim). To exit without storing your changes you can use [escape][:][q][!][enter]. You can find a tutorial on vim here if you want to get started with it.

Commit cohesive sets of changes, and give the changes a clear description. You can find more best practices in this online article by Tower.

Assignment

---

Commit the changes you staged in the previous assignment.

How to reset a set of changes

Sometimes you committed something incorrectly, for example when you forgot to check if the code actually compiled. All the commits that are not online yet can be reset without too many problems.

Terminal

To reset the branch to the last commit you can use the following command;

git reset [--soft | --mixed | --hard] HEAD~1

Without specifying the reset option it will default to a mixed reset. The number behind HEAD~ is how many commits you want to go back. To see the log of the commits and check where you want to go to when you made multiple commits use the command;

You can see the history of commits using git log. Optionally add the shown parameters to make it look nice

git log --all --graph --decorate

Assignment

---

To try it out, make some changes in the README.md document that you do not want to share and commit them. Then reset the changes.

Try out all the different options for resetting your branch to see what the effect is. We recommend soft reset as it keeps your changes. Mind that these changes remain staged!