Lesson Objectives¶
- Review git commands
- Describe individual and collaborative workflows with git
- Introduce git commands for collaborative workflows
- Demo of collaborative workflows in practice
- See additional useful git tips/tricks
Acknowledgements¶
This material is heavily influenced by the previous works of Karthik Ram and James Howison from the previous summer school
Other Resources I have found helpful/fun for git
Workflows with git¶
An Individual Workflow (without a remote)¶
commit, commit, commit .....
madicken@computer: ~/repos/research-code $ git init
Initialized empty Git repository in /Users/madicken/repos/research-code/.git/
madicken@computer: ~/repos/research-code $ git branch -M main
madicken@computer: ~/repos/research-code $ git add README.md
madicken@computer: ~/repos/research-code $ git commit -m 'add readme with code description'
[main (root-commit) 49c9e77] add readme with code description
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 README.md
An Individual Workflow (with a remote)¶
commit push, commit commit push, commit push .....
madicken@computer: ~/repos/research-code $ git remote add origin git@github.com:munkm/research-code.git
madicken@computer: ~/repos/research-code $ git push -u origin main
Enumerating objects: 13, done.
Counting objects: 100% (13/13), done.
Delta compression using up to 4 threads
Compressing objects: 100% (11/11), done.
Writing objects: 100% (13/13), 8.03 KiB | 4.01 MiB/s, done.
Total 13 (delta 1), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (1/1), done.
To github.com:munkm/research-code.git
* [new branch] main -> main
Branch 'main' set up to track remote branch 'main' from 'origin' by rebasing.
madicken@computer: ~/repos/research-code $ git add LICENSE
madicken@computer: ~/repos/research-code $ git commit -m 'add BSD-3 license for my code'
[main 6c65ead] add license
1 file changed, 401 insertions(+)
create mode 100644 LICENSE
madicken@computer: ~/repos/research-code $ git push
With your code on a remote (like github, gitlab, or an internal server for your lab), your work is easily accessed by peers!
... But what about working with others?¶
Centralized Workflow¶
All members work on the same repository
Centralized Workflow¶
git pull before starting work
Everyone commits to main
git push
If there is no merge conflict, 🙌
Otherwise fix merge conflict, then push
Feature Branching Workflow¶
Members work on the same repository but use individual branches to do feature development
Feature Branching Workflow¶
Create and switch to a branch
Add commits
Push feature branch to GitHub
Start a pull request
Discuss, add more commits, merge
Some important commands for this workflow:
git branchgit checkout -b <branchname>git push -u origin <branchname>
.. add some more commits
then git push and open a pull request
Pull Requests¶
Pull requests are an excellent tool for fostering code review. If you’re using Github for team projects, you should be using these extensively.
Pull request best practices:¶
A good practice is for someone else to merge your code into master, ensuring two people understand each feature. Sometimes a reviewer may not have merge rights; in these cases the requirement may be an approving review must be given before the feature is merged.
Pull request tip:¶
Using the github interface, you can change the target of a pull request. The default is to the main branch, but it could be another feature branch. This can be used if you want to help develop a feature branch outside of main with a collaborator.
⛔️ Never send a pull request from master 🙅
⛔️ Never send a large pull request without notice 🙅
Forking Workflow¶
In this workflow each collaborator "forks" a copy of the centralized repository. These forks represent individual remote repositories for each collaborator. Collaborators submit pull requests from their forks to the centralized repository.
Forking Workflow¶
Everyone has a fork of a "central" repository
Add commits to feature branches
Push feature branches to individual forks
Send pull-request from feature branch on fork to central repository
Extra Tips:¶
Tip #1: Always git pull before you start new work
Tip #2: Keep branch names descriptive
Tip #3: Generously use branches (but delete them when they're merged or stale)
Tip #4: Use github command line tool (gh) to simplify your workflow
More useful git commands¶
tagging commits¶
branches are special labels that track a series of commits, but what if you want a special name for a particular commit (like when you released a new version of your code)? you can "tag" these
git tag -a <tagname> <hash>-- useful for tagging a particular commit farther back in historygit tag -a <tagname> -m "tag message"-- this should tag the current commit with a descriptive messagegit push origin <tagname>-- push a particular tag up to your remotegit push origin --tags-- push all of your tags up to your remote
amending a commit¶
Oh no! I made a typo in my commit message!
git commit --amend is useful for both fixing commit messages and for adding in files that were suppoosed to be committed and werent
cherry picking¶
What if you have a commit that really belongs on a different branch? Or in development you fixed a bug that you think should be in its own PR? You can "cherry pick" that commit to a new branch.
git cherry-pick <hash>
undoing changes¶
Reverting vs. Restoring
stashing changes¶
oh no! I started making changes but I'm not on the feature branch I thought I was!
git stash can be used to hide the changes in your working tree and then bring them back out when you're on the appropriate branch
co-authoring changes¶
Have you pair programmed with a friend and come up with a solution together? How do you deal with attribution?
Co-authored-by: NAME <EMAIL> can add multiple authors to a commit.
Exercises¶
Choose one of the following:
- If you brought a project to work on: open an issue on your repository for something you'd like to improve that's a beginner friendly issue. Describe the issue thoroughly. Then, working in groups at your tables, have a partner fork your project and submit a pull request fixing that issue. Do not merge the pull request today.
- Consider the design patterns lecture or the packaging and distributing lecture from yesterday. Make a feature branch on your project and add one of these features to your project. Submit a pull request on your project using that branc. Do not merge the pull request today.