Git for Visual Effects beginners

“Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.”

You can basically compare git with Dropbox and Google Drive. All of them store data (online), sync them and recognize when changes happened. While Dropbox and Google Drive are commonly used for any type of data from docs, photos, videos to slideshows git focuses mainly on code. Git is specialized to handle, upload, compare, merge and share code in any scripting and programming language across all software development projects and film pipelines. Code collaborations with others is the most common reason to use git but also to keep your solo project in check, to restore lost data and to rollback updates and changes. All Technical Artist, Technical Director and Software Developer must know the basics of git to work properly in a production.

What are the biggest benefits of using git?

• sharing: Working on the same scripts and software modules can be tricky especially if everyone is coding remote or on local files. Similar to Google Drive you can share and accept other developers updates automatically without hand selecting files or doing tedious copying.

• merging: When every team member is working on different files in different folders, updating is easy. Even Dropbox and Google Drive can do the job but the moment two developers worked on the same files adding different parts at the same time - this is where things get tricky. Git allows users to merge files together automatically while tracking the differences. On unsolvable conflicts it asks the user to resolve the conflict by stating what was added, removed or overwritten.

• version control: Every version that is committed is documented and saved inside git. This means should something get lost or break the user can always roll single files or the whole system back to a specific point in time. In visual effects, animation and games pipelines this is often the case when a newly released tool creates production issues. The developer rolls back the public release to a previous version while working on the fix locally.

  
  

• tracking: Since most projects have multiple contributions from multiple sources each step is tracked and commented on which makes the step of reconstructing who did what and for what purpose of each update simpler. This comes especially in handy when merging different updates or rolling back to an older version.

There are even more benefits why git is so important for developers but these are the most common ones.

git workflow

The git workflow is usually pretty straightforward and can be summarized in these steps:

1. init or clone: Create or download the project

2. code: add, update or remove files and content 

3. add: Define tracked files

4. commit: Create a commented package

5. pull: Get and merge remote updates

6. push: Send and merge remote updates

If you’re a solo developer or are working on a simple project with rare overlapping this will be your main steps 95% of the time. Which sounds fairly easy and it is. Git only starts to become complicated when it either has an issue like a merge conflict or when you want to use one of its advanced features like a rollback. This is the moment when most developers find out that they only worked on the surface of what git actually is capable of. To avoid the same fate make sure to understand the purpose of each step since each of them can become problematic under a specific situation.

Next we will do a simple git workflow practice run to show the typical steps from a repository creation to delivery. The general git workflow relies heavily on the shell; lucky for us since we just learned the shell basics. It is possible to control git via a software with a user interface which is recommended after feeling comfortable with the basics. It is important to learn to control git via the shell since some issues are easier or only solvable via commands.

Let's say we just created our new project and want to link it with git and being accessible online on GitHub:

1. Install git on your computer. Be aware that the Git installation provides several options. If you’re new to Git, just select the recommended one for now - we can change it later.

2. Open Git Bash and navigate to the new project directory. With Git installed, we either can use it via the command prompt/Terminal or via a UI application like GitKraken. For now, we will focus on the most basic Git experience since it is important for us to be proficient in the Git basics. Later, we will be free to use more sophisticated, user-friendly applications. 

cd /path/directory/

The Git Bash has additional highlighting and information.

3. Link your directory to a new or clone an existing git repository. A repository is a git storage location from which software packages can be cloned or modified - aka project. My open source pipeline Plex for example is a git repository.

# Link a git repository to the current directory
git init

# OR

# Clone the Plex repository into the current directory
git clone https://github.com/alexanderrichtertd/plex.git

4. Check the current status of the new, modified or deleted files:

git status

Note: Tracked files are included into the git repository while staged files are ready to be packaged. Untracked files will not be synced while unstaged files will not be added to the latest commit and package.

5. Add unstaged and untracked files to the repository since they have to be registered to count for the commit and as project files:

# ADD a specific untracked or unstaged file
git add lib/libLog.py

# ADD all untracked or unstaged files to the next commit
git add *

After staging all files to the commit:

6. Commit: In the next step we package all the staged files (added, modified or deleted) in the repository by committing to the changes with a comment; quotations are optional but recommended. The commit also creates a rollback version.

# Creating a commit of the current staged files
# -m: message
git commit -m "ADD library function"

IMPORTANT: If you used git init you also have to define your remote git repository (e.g. GitHub link) to let git know where to pull and push the data. This only needs to be done once for every repository.

git remote add origin
https://github.com/alexanderrichtertd/plex.git

7. Log: Shows the commit logs.

git log

8. Revert: Reverts a previous commit using its hash and creates a new one. Only reverts one commit, it doesn’t revert everything back. For a reset check out “git reset”.

git revert 2a12bec620681dab857ce05456503013fce11e7e

9. Pull: Before pushing the committed files to the remote repository you first have to make sure that your local repository has the latest updates. This is essential especially if you work with other developers. The pull command compares your local files with the remote repository and updates them if needed.

git pull

Conflicts: Unclear changes between the files, especially modifications from multiple developers on the same lines can lead to conflicts. Git will solve these conflicts by itself and will mark lines that are problematic. Your job now is to open the marked files, solve the conflflicting lines manually, git commit them again and do another git pull.

10. Push: After updating your repository to the most recent state with the shared repository we are ready to push our updates and merge them with the remote repository (e.g. GitHub).

git push

Now your remote git repository is up to date with the newest changes. This means every time someone does a git pull with the remote repository they will have to merge their files with your updates first before pushing and overwriting with their own modifications.

To learn more about git, professional coding style and advanced UI:

Join our Python Advanced masterclass