Collaborative Workflows (with Git)

Version Control Refresher

In term 1 we saw how a version control tool called git helps to provide resilience 

• Git repositories (repos) are typically stored on a server somewhere 

• Repos are then cloned onto other computers as needed (e.g. your laptop) 

• All changes made within a repo are automatically tracked

• When we have made some useful change (fix a bug, add a new feature…), we commit

• As frequently as we like we push those commits back to the server 

• As frequently as we like we pull changes into our local repo from the server 

• All versions of your code are stored, so no work is ever truly lost 

Accessing a Repository for the First Time

Once there is a remote repo, we often want a local copy to work on… 

• There is a standard command line tool called git

• There are also GUI tools, and VS Code integration

• The command line tool provides more control over your work, so is good to learn

• We recommend you learn the command line tool in this course

• To take a local copy of a git repo, we use the git clone command:

Accessing a Private Repository

• If your repository is private, you need to provide your credentials

• It is recommended providing an access token as the password

• Access tokens are similar to passwords, except you can limit access to resources, select a limited role, and provide an expiry date

What Git Does

Once you have a local repo, your computer is tracking ALL changes you make in that folder

• New files 

• Deleted files

• Changed files 

Your local copy will not change by itself – even if someone else updates the remote repo

• You can trust the local files no to change

• You can trust that ANY changes you make locally will not irrevocably affect others

• You can trust that any code that has been committed can never be truly destroyed as long as the repo exists

Adding New Files

If you create a new file in a repo, this will be noticed 

• But it will not automatically become part of the repo

• Do this explicitly

• Once added, the files content will be tracked for changes

• Therefore, only add files you want to be tracked

• Use "git status" to show untracked files, and changes in tracked files

• Use "git add" to add a newly created file to a repo

Committing Changes

When you reach a good "checkpoint" commit your changes 

• E.g. fixed a bug, added a new feature… 

• Keep commits clean (one meaningful code change per commit) 

• Choose a name for a commit that describes the change 

• Commit often and include as much detail as necessary

• Review changes before you commit. Did you intend to make all those changes??

Sharing Changes

Once you have one or more local commits, you can share back to the server

• This makes your changes visible to others 

• It also means your work is properly backed up… 

• Until you push, you are still vulnerable to local loss hardware fail, theft, damage, accidental deletion… 

Use git push to propagate your commits back to the server

• We specify where to push to (normally "origin" – wherever you cloned from) and the branch to push (the "main" branch is fine for now!)

Receiving Changing

You can receive updates from others via explicitly merging them into your local repo

• Changes only arrive when you want them to

• Use git pull to do this

• Any commit you don't have are then downloaded and merged into your local repo. 

Unless both you and someone else have editing the same file since you last pulled, no user intervention is needed… 

If the version on the server is newer than your local version, you will be required to perform a pull operation before you can push

Ignoring Changes

• We might need to keep some files only in our local repository (e.g. .class files)

• You can configure Git to ignore such files

• Create a .gitignore file in your local repository's root directory to tell Git which files and directories to ignore when you make a commit

Merge Conflicts

If someone else has updated file on the server as you have edited locally… 

• This is called a merge conflict 

• Git will need some help from you to resolve this

• Any files in conflict will be updated with BOTH copies of lines of code that differ

• Fix this conflict by ether choosing the versions of the lines you want

• Or by editing the code until it is correct

• Then add these changed files that were in conflict and commit