Git and Github exists to help us keep track of who is making a change in the remote versus local spaces especially when we're working collaboratively.
Collaborative Git workflows are usually determined based on the team that we're working in. Since there are all sorts of team types that exists in the world, then there are also different workflows that exist. We'll be covering a workflow walkthrough for working in the same workstation (also known as pair programming).
The following workflows are written with the assumption that we're working in a relatively small team (2-30 people).
Data Movement
To review, our data moves from local locations to remote locations and vise versa.
One Workstation Workflow: for Pair Programming Team Members
Person A Driving:
Step 1. the first step to working with Git and Github is to clone the remote's repository with git clone. Once Person A runs git clone they're able to cd into their local copy of the remote repository and start working locally.
Then they can move on to steps 2-11. To view the more detailed walkthrough of these steps, feel free to read the previous blog post in this series on Git Individual Workflow.
Step 2. git branch: view current branch & view all branches in our local repository
Step 3. git pull origin master: pull remote master branch data to our local master branch
Step 4. git checkout -b personA-branch: create a new local branch and move to that branch
Step 5. git branch: sanity check that we're in proper new branch
Step 6. Make code changes
Step 7. git status: shows what files have had changes made & shows whether our files have been staged or not (green for yes, red for no)
Step 8. git add filePath/wanting/toStage.txt: add files, via their file paths, to the staging/index area
Step 9. git status: sanity check that only preferred files are staged/added to index
Step 10. git commit -m "any commit message": snapshot currently staged changes via a singular commit & write concise message
Step 11. git log: view our commit history to sanity check that our most recent commit is at the top of the history list
Step 12. Person A can keep making local code changes and looping through steps 6-11 before moving on to step 13.
Step 13. Once Person A's local repository is at a ready-enough state for their team's review and/or collaboration, they can push their changes to the remote repository with git push origin personA-branch.
git push will send all of Person A's local repository's commits and branches to the remote repository (in Github).
Step 14. When Person A signs into Github and visits the remote repository, they should be able to create a new pull request(PR). Pull requests are akin to a form requesting to officially merge Person A's changes to the remote branch they originally branched-off of. PRs enable team members to share the purpose of their code changes in layman's terms. PRs also enable team members access to review changes and view diffs from making changes collaboratively.
At this point, Person A can take a backseat for the moment while Person B drives.
Person B Driving:
Step 15. Person B will need to git clone the remote repository to have a local copy of the repository on their machine, same as Person A had.
The fun part is that now that Person A's work is available remotely (because Person A git push-ed), Person B can fetch and checkout a local copy of the remote branch that Person A just pushed.
Step 16. git fetch --all fetches all remote branches and makes those branches available locally to Person B.
Fetch will not move any code changes; fetch will only move meta data (such as branches) from the remote space to Person B's local machine. So, Person B can fetch in any branch and as often as they like.
Step 17. After fetching, Person B is able to checkout Person A's branch.
user@ repo-name % git checkout personA-branch
Branch 'personA-branch' set up to track remote branch 'personA-branch' from 'origin'.
Switched to a new branch 'personA-branch'
Running git checkout will 1. create a new local branch, called personA-branch in Person B's workspace, 2. set up this newly created local branch to track its remote counterpart with the same name, and 3. place Person B in their newly created local personA-branch copy branch.
Step 18. Running git branch again to sanity check that Person B is in the proper branch should yield something like this:
userB@ repo-name % git branch
master
*personA-branch
Step 19. Now, when Person B runs git pull, they are pulling the updated commit history from Person A's remote branch (called personA-branch) to Person B's local copy of Person A's branch (also called personA-branch). If the remote repository has no changes, then git pull will show an 'Already up to date' message.
user@ repo-name % git pull origin personA-branch
From github.com:PersonA/repo-name
* branch personA-branch -> FETCH_HEAD
Already up to date.
Reminder: everyone should git pull only the remote branch name that matches the local branch they are currently in.
Step 20. Person B's local copy of PersonA's branch will end up tracking the version history of Person B's local changes via commits.
So, Person B can go ahead and complete steps 6 - 11 while making code changes and adding those to their commit history.
git log within the 11th step will show Person B's local commit history that Person B made to their local copy of Person A's branch.
Step 21. In order to update Person A's remote branch, Person B would run git push origin personA-branch.
On Github, Person A and Person B should both see the remote branch was updated with Person B's commit history.
To switch drivers, Person A and Person B can each take turns with steps 17-21 until the PR is ready to be reviewed and merged to the branch PersonA's branch had originally branched off from.
TLDR: One Workstation Workflow (for Pair Programming)
-
git clone repo-link && cd PersonA-repo: make a clone/local copy of PersonA’s remote repository and move into it -
git branch: view current branch & view all branches in our local repository -
git pull origin master: pull remote master branch data to our local master branch -
git checkout -b personA-branch: create a new local branch and move to that branch -
git branch: sanity check that we're in proper new branch - Make code changes
-
git status: shows what files have had changes made & shows whether our files have been staged or not (green for yes, red for no) -
git add filePath/wanting/toStage.txt: add files, via their file paths, to the staging/index area -
git status: sanity check that only preferred files are staged/added to index -
git commit -m "any commit message": snapshot currently staged changes via a singular commit & write concise message -
git log: to view commit history to sanity check that most recent commit is at the top of the history list - Driver can keep making local code changes and looping through steps 6-11 before moving on to step 13
-
git push origin personA-branchpush driver’s commit history to remote repository - Driver creates pull request(PR) in Github & drivers switch (so from this point forward, actions should be of new driver)
-
git clone repo-link && cd repo-nameclone the remote repository to the new driver’s local machine -
git fetch --allfetches all remote branches and makes those branches available locally to the new driver -
git checkout personA-branchin the new driver’s workspace: creates a new branch that matches the remote branch name (personA-branch), tracks the remote counterpart, and places the new driver in their localpersonA-branchbranch -
git branchto sanity check that new driver is in the properpersonA-branchbranch. -
git pull origin personA-branchpulls the updated commit history from Person A's remote branch (calledpersonA-branch) to Person B's local copy of Person A's branch (also calledpersonA-branch) - New driver can keep making code changes and adding those to the commit history by repeating steps 6 - 11
-
git push origin personA-branchupdate remotepersonA-branchwith new driver’s local commit history - Switch drivers and new driver will repeat steps 17-21 until PR is ready for to be reviewed and merged
Top comments (0)