It’s Yoyo again. So this time we were asked to consider version control in a heritage project and this is where my mind went:
I keep thinking about what “version control” actually means in the context of digital humanities, and what it means to me, and what I have learned about it. Even after the second project, the mapping challenge started, and I still saw it as something programmers needed. Still, as I started writing this post, I kept thinking about it in relation to my work on Palestinian film and literature. But the more I have been considering my fellowship heritage project and mapping surveillance across Palestinian cinema, the more I have come to realize that version control is more aligned with the kind of memory work I care about than I initially thought. I am looking it as not just something that is tracking the changes of code we have been making to our projects or the files we have been updating and sharing to our group members in our challanges, but as the documenting of the process itself; the ability to preserve multiple narratives while resisting the kinds of erasure that typically happens when we only keep the “final” or “finished” version of something.
So then, for the type of project I want to work on and build, which is currently one that is intertwined with contested histories and documents Palestinian cultural production, then version control becomes a form of archival practice itself. Whether I am working on films, literary texts, oral histories, or spatial data, it is critical that I can track how my understanding changes over time and how my interpretations shift. Also, how different team members contribute to the work. This is not just convenient but an integral part of my methodological approach. In my research on sumud and Palestinian resistance, I have been constantly thinking about counter-archives and the ways specific communities create and preserve knowledge that dominant narratives seek to control or erase. Traditional archives currently exist with gatekeepers who decide what gets preserved, how it is categorized, and who has access to it. Because of this, they create a single authoritative version of history, but through thoughtful use of version control, which can function as a type of counter-archive practice that preserves multiplicity rather than singularity, this is different.
So, when I used GitHub to track changes to the Project Vision Challenge and the Mapping Memory project, we weren’t just saving different versions of the files; we were also documenting how our knowledge of these cultural materials developed over time. I am then preserving the messy, non-linear process of interpretation and keeping track of who contributed what aspects of the projects and when. This feels particularly important for my future project, as I consider how working with materials from communities whose histories have been erased and continue to be erased functions in every commit message and every branch I create. Every merge becomes part of the history of how I came to understand the materials I interact with. With our second project, version control was essential for knowing which parts were completed by which person, and it allowed us to work in different spaces and achieve more than we were able to during our residency hours. This makes sense for working with multiple people on larger projects over longer periods of time and with more content.
For instance, when I was building my digital project through Storymaps that maps surveillance infrastructure across Palestinian films, I saw how my understanding of how a particular checkpoint functions in a film might have changed as I read more scholarship or as I talked with people around, went to conferences, or as I noticed something different or new when I viewed the film again. I see the version as a “living archive,” which I discussed a bit in my last post, but here I see it as a place where you can see the project grow, what questions emerge, what dead ends I might hit, and what might emerge.
This also makes me think about how important transparency is, especially for the communities whose cultural materials we are working with and interacting with. It is valuable to have this type of documentation of who did what, and a place that highlights what we considered at each phase. And what is most important to me is that it models a different relationship between authority and expertise. Instead of presenting my project as a finished, authoritative product, this history of version control lets me show my work in progress. It recognizes that the process of interpretation is ongoing and that I make mistakes, which I can and have corrected. One of the central issues of my research, as I stated earlier, is erasure, so, in this light, version control becomes a tool for resisting erasure at the level of my digital project itself. Nothing is ever truly deleted; here, everything is preserved in the version history. Even if I were to change my mind about something or revise it from a previous version, I have learned that it will remain accessible when I save and push.
This is how I think about version control: how I interact with my own materials and work that documents resistance to occupation and erasure. My methods should embody the same commitment to preservation and memory. This is not just a backup strategy for when something goes wrong; I see it as a commitment to conservation and continuity that aligns with the principles of sumud. And I am aware that version control is not perfect, as I experienced in our second challenge: when working on the same file, versions could not be saved, and data was lost. The concepts of branches, merging, and pull requests are not always intuitive. However, my comfort with technology and my version control skills have grown and will continue to grow as we work through challenges and our own fellowship heritage projects.
Ayaat (Yoyo) Ismail
Recent Comments