Git Merging Explained

When you issue the command git pull usptream main you are actually executing two Git commands: a fetch command and a merge command.

• The fetch command pulls new documents from the upstream (or class) repository into your local workspace.
• And the merge command adds and commits those new files to your local repository.

For Git to merge change

Git works well when changes are linear across time. Here, the history of commits fall neatly along a line. When changes are made out of sequence, for example, when you add a file via upstream pull that’s older than your latest commit, Git has to reconcile these asynchronous changes into its history. You can see this if you have a look at your Git history in R-Studio where the vertical line represents time and the circles represent changes to your repository. In the figure below, note the divergence at “Adds 01_gitExercise.pdf”.

What’s going on here is that we instructors made two commits to the class repository (“Adds 01_gitExercise.pdf” and “Create 02_Reproducibility_CodingBasics.Rmd”) at some point prior to me making four commits to my local repository (“Initial commit of GitDemo.txt file” thru “initial commit of Assignments01 RMD file”). However, I didn’t pull the changes to the class repository until after I committed changes to my local repository. So, when I did finally pull the upstream changes, Git needed to insert those older files from the class repository into the time line. This insertion is called a merge because Git is merging two timelines back into one.

If that’s a bit confusing, really all you need to know is that Git likes to be fully transparent about all these changes, which can be quite important when