05. Using Git
Each developer works on their own local version of the git repository managed by the git version control system.
Each local repository is connected to a remote Git repository, enabling manual synchronization of changes.
it's up to the user to Pull and Push changes from and to the remote git repository.
A commit in Git is like capturing a snapshot of your work at a specific moment in time, preserving it in your local repository’s history.
When you commit changes, you’re effectively bundling all the modifications you’ve made—such as edits, additions, or deletions of files—into a single record. The changes stay local until you Push to the remote repository.
Practical Guide
Branches in Git function as self-contained lines of development. All the different branches can contain different commits. When a new branch is created, it is created based on an existing branch and contains all the commits from the original branch. After which new commits can be added to the new branch that are unrelated to the original branch(See picture below), until they are merged together. This enables you to work on new features, bug fixes, or experimental ideas in a secluded environment.
By branching off from the main branch, you can add, modify, or remove code without affecting the stable foundation of your project. This is particularly beneficial in collaborative team settings, since developers can simultaneously work on different parts of the application, all within their own branches.
Main branch is the development branch in the Altzone project. The main branch is protected, which means that you need to merge your changes by Pull Request.
Feature branch is branch dedicated to developing a new feature to the project without affecting the main branch until you merge using a Pull Request.
The branch could for example be called, feature/ProjectileSpeed.
Pulling in Git is the process of retrieving and merging changes from a remote repository into your local repository. This ensures you’re working with the latest updates from your collaborators and helps prevent merge conflicts by keeping everyone’s work in sync.
-
Common Pitfalls
- Pulling with committed changes: If you have committed local changes that have not been pushed to remote, the default pull will create a merge commit. In this case you should rebase instead of pulling.
- Uncommitted changes: If you have changes in your working directory, the pull might produce conflicts.
- Merge Conflicts: You may need to resolve conflicts and commit or stash your changes before pulling again.
Practical Guide
Enabling Pull with Rebase for GitHub Desktop
Pushing in Git is the process of sending committed changes to the remote repository, making these updates visible and accessible to other contributors on the project. It is crucial for synchronizing your work with the shared codebase, ensuring teammates can build on or review your newly added code.
-
Common Pitfalls
- Pushing when there are new commits in the remote: If there are commits in the remote, that are not in your local branch, the push will not go through and it will ask you to force push. DO NOT FORCE PUSH! Especially if you are reading this to learn git. Instead you should pull the changes and resolve the issue. However this can also be problematic, so check Pulling with committed changes.
Both merging and rebasing integrate commits from one branch to another or less commonly commits with the same parent commit within a branch, but in different ways.
- Merging from one branch to another, you create a new “merge commit” that has two parent commits—one from your current branch and one from the branch you merged in. The picture below shows merging from a feature branch to the main branch but you can also merge from the main to a feature branch.
Practical Guide
- Another scenario where a merge can occur is after pulling new changes from a remote branch that shares the same parent as the commits in your local branch. However, in this situation, a rebase is typically preferred to maintain a cleaner, more linear commit history.
- Rebasing moves commits from one branch on top of another, effectively rewriting the project history in a linear fashion.
Practical Guide
-
Merging
- Pros: Keeps the original commit history intact.
- Cons: Can create numerous merge commits, resulting in a non-linear history.
-
Rebasing
- Pros: Creates a cleaner, linear history.
- Cons: Potentially more complicated conflict resolution, and rewriting history can be confusing for beginners. Rewriting history can also be dangerous overall.
More info: Merging vs. rebasing
A pull request (PR) is a way of merging branches to another branch, but in our case we mostly merge to the main branch. It triggers a review process where team members can comment on changes, request modifications, and ultimately merge them into the main codebase.
-
Benefits of Pull Requests
- Code Review: Ensures high-quality contributions.
- Collaboration: Multiple people can comment on and improve the code.
- Documentation: The PR itself documents the reason for the change.
This section shows how to use git in practice.
`git switch feature/<BranchName>`
- Switch to a branch that you wish to base the new branch on
- The following command creates a new branch from the current branch and switches to the newly created one:
git switch -c feature/<BranchName>
Use the following command to check if the remote branch has new changes:
git fetch origin <RemoteBranch>
If there are new changes in the remote, you can pull the changes to the local branch by using the following command:
git pull origin <RemoteBranch>
If there are new changes in the remote and committed changes not pushed to the remote, you can pull the changes to the local branch without unnecessary merge commits by using the following command:
git pull --rebase origin <RemoteBranch>
You have to stage you changes before you can commit them. This also means that you can leave changes from a commit, if you so wish.
- Make changes
- Stage your changes with the following commands:
-
git add .orgit add -ato stage all the changes. -
git add <path>to stage a single change.
-
- Commit your changes with the following command:
git commit -m "Implemented player movement"
After you have committed you can push your changes to the remote branch:
-
git push origin <RemoteBranch>- for example
git push origin feature/Movementwhich pushes your local changes to the remote branch feature/Movement. - If the remote branch doesn't exist, then it is created on the remote repository.
- for example
SourceBranch -> TargetBranch
-
Switch to the main branch so you can pull new changes
git switch <SourceBranch> -
Pull changes from the remote source branch
git pull origin <SourceBranch> -
Switch back to the target branch
git switch <TargetBranch> -
Merge the changes from the source branch to the target branch:
`git merge
Resolve Conflicts (if any) and Commit
- After fixing conflicts in your editor commit the changes:
git commit - If more conflicts happen fix the conflicts again and then commit again.
SourceBranch -> TargetBranch
-
Switch to the main branch so you can pull new changes
git switch <SourceBranch> -
Pull changes from the remote source branch
git pull origin <SourceBranch> -
Switch back to the target branch
git switch <TargetBranch> -
Rebase the changes from the source branch to the target branch
git rebase <SourceBranch>
Resolve Conflicts (if any) and Commit
- After fixing conflicts in your editor stage the changes:
git add . - Then continue the rebase:
git rebase --continue - If more conflicts happen then keep doing the above steps until no more conflicts happen.
You shouldn't create a pull request by terminal, so you should just use the GitHub website.
Go to GitHub and for example compare feature/Movement against main, and then create the pull request.
Once your pull request is approved, your team merges the pull request into main and optionally deletes the feature branch.
This section shows how to use GitHub Desktop in practice.
By default the GitHub Desktop causes the pulls to merge if you have made commit without pulling the latest changes first. This also happens if someone pushes their changes at the same time you are trying to push yours, forcing you to fetch and pull the new changes.
These merges can get pretty messy, especially if there are conflict between the changes you and someone else have made.
One way a circumvent this issue is to rebase the incoming changes from the remote into your local repo, however this function isn't available by default on GitHub Desktop.
To enable pull with rebase you will need to tell your .gitconfig file to use rebase specifically.
Your global .gitconfig file is found at C:\Users{Account_name}.gitconfig Add: [pull] rebase=true to the end of the file. Save the config file. Now you should see pull origin replaced with pull origin with rebase. The main caveat of enabling this, is that you will need to stash any changes you haven't committed yet each time you want to pull changes from the remote. Additionally any conflict would now need to be solved manually, but most IDE (like Visual Studio) offer easy tools to solve these conflicts. And you are in a less of a risk that the automatic merge messed something up.
TL;DR Most other version control system do this automatically and you don't need to think about this at all. Short explanation here: Merging vs. rebasing.
Example:
C:\Users\petays>type .gitconfig
[user]
name = Jari Petays
email = [email protected]
[filter "lfs"]
clean = git-lfs clean -- %f
smudge = git-lfs smudge -- %f
process = git-lfs filter-process
required = true
[pull]
rebase = true
[difftool "sourcetree"]
cmd = "'' "
[mergetool "sourcetree"]
cmd = "'' "
trustExitCode = true