1. Collaborating
1.1. Distributed model of version control
1.2. Copying the repository
1.2.1. git clone [remote-repo-location]
1.2.2. Create directory, init repo, copy commit objects...
1.2.2.1. And add a remote repository reference = origin, a remote head = origin/[head-name]
1.2.2.2. git branch --track [new-local-branch] [remote-branch] -> work with remote-branch locally setting up new-local-branch
1.3. Receiving changes from remote repository
1.3.1. git fetch [remote-repo-reference]
1.3.2. Retrieves new commit objects and creates/updates remote heads
1.4. Reflect remote repository changes
1.4.1. Merge
1.4.2. git pull [remote-repo-reference] [remote-head-name]
1.4.3. Merge head remote-repo-reference/remote-head-name into HEAD
1.5. Sending changes to remote repository
1.5.1. git push [remote-repo-reference] [remote-head-name]
1.5.2. Add new commit objects to remote repo and set its head
1.5.3. Git requires that push results in a fast-forward merge on the remote repo
1.5.3.1. Before the merge, the remote head must point to an ancestor of the commit that it will point to after the merge
1.5.3.2. Otherwise = dangling commit
1.6. Adding/removing branches remotely
1.6.1. git push origin new-branch git checkout [some-other-branch] git branch -f new-branch origin/new-branch git checkout new-branch
1.6.1.1. git push --set-upstream origin new-branch
1.6.2. git push [remote-repository-reference] :[head-name] -> delete a branch on remote repo (push no data into its head)
1.6.3. git branch -r -> list remote branches
1.7. Central Repository
1.7.1. Repo with no working files, only repo info
1.7.2. Only receives pushes and pulls
1.7.3. GitHub/Gitosis
2. Rebasing
2.1. Alternative to merging
2.2. git rebase [new-commit]
2.2.1. Identifies each commit that is an ancestor of the current commit but not of the new commit
2.2.2. Determine what changed for each of those commits
2.2.3. For each change, replay the change onto the current head and create a new commit
2.3. No merge commit created
2.4. Implies a changing of history
2.5. Use practices
2.5.1. To keep a branch you are working on your own up to date with respect to the main branch
2.5.2. If a commit is made to a branch that changes at the same time on a remote machine, rebase can shift your commits allowing a push
3. Rodrigo Landa Andraca A01339239 Duan, Charles. “Understanding GUIT Conceptually,” 2021. Understanding Git Conceptually
4. Repository
4.1. Contains
4.1.1. Commit objects
4.1.1.1. Contain
4.1.1.1.1. Set of files that reflect the state of the project
4.1.1.1.2. References to parent commit objects
4.1.1.1.3. SHA1 identifier from relevant aspects of the commit
4.1.1.2. git add, git commit, git commit -a, git commit -a -m [message]
4.1.2. Heads
4.1.2.1. Reference to a commit object
4.1.2.2. current head = HEAD
4.2. Stored in the same directory as the project
4.2.1. .git
4.3. Commands
4.3.1. git init -> start repo
4.3.2. git log -> log of all commits starting from HEAD back to the initial commit
4.3.3. git status -> which files have changed between the current state and HEAD
4.3.4. git diff -> diff between HEAD and the current state
4.3.5. git mv, git rm -> mark files to be moved/renamed and removed
5. Purpose
5.1. Manage set of files as they change over time
6. Branching
6.1. branch = head
6.1.1. Every branch is represented by one head
6.1.2. Every head represents one branch
6.2. Example
6.2.1. (A) -- (B) -- (C) | master | HEAD
6.2.1.1. git branch fix HEAD^
6.2.1.1.1. (A) -- (B) ------- (C) | | fix master | HEAD
6.3. Commands
6.3.1. git branch -> lists the existing heads/branches
6.3.2. git branch [new-head-name] [reference]
6.3.3. git checkout [head-name] -> switch to branch/head head-name
6.3.3.1. ALSO rewrites the files in the directory to match the files in the new HEAD commit
6.3.4. git dif [head1]..[head2] -> diff between the commits of head1 and head2
6.3.5. git log [head1]..[head2] -> change log between head2 and the common ancestor of head1 and head2
6.4. Use patterns
6.4.1. Master branch = releasable state
6.4.2. Other branches = half-finished work, features
6.4.2.1. Commits are cheap
7. Merging
7.1. To bring new features into a branch
7.2. Commands
7.2.1. git merge [head]
7.2.2. git pull . [head]
7.3. Process (assuming current head = current and head to be merged = merge)
7.3.1. Identify common ancestor of current and head
7.3.2. If common ancestor = head, do nothing
7.3.3. If common ancestor = current, fast forward merge
7.3.3.1. Set current to last merge commit
7.3.3.1.1. +-- (D) -- (E) -------- (F) / | (A) -- (B) -- (C) | | merge, current | HEAD
7.3.4. Otherwise, determine the changes between the common ancestor and merge
7.3.4.1. Attempt to merge changes into current
7.3.4.2. If there were no conflicts, create a new commit with two parents and update the files
7.3.4.3. If there was a conflict, insert appropriate conflict markers
7.3.5. +----------- (D) ---------------+ / | \ (A) -- (B) -- (C) -------------- (E) -- (F) | | merge master | HEAD
7.4. Resolving conflicts
7.4.1. Conflict = commit to be merged and current commit have a change in the same place
7.4.2. Edit the files -> git add -> git commit
7.5. Use patterns
7.5.1. Draw the changes from a new feature branch into the main branch
7.5.2. Draw the main branch into a feature branch
7.5.2.1. Keep feature branch up to date with bug fixes and new features
7.6. Deleting a branch
7.6.1. Recommended after merge
7.6.2. git branch -d [head1]
7.6.2.1. Raises an error if the branch is not reachable from other head
7.6.2.1.1. git commit -D [head1] -> "force" delete