"works well with others"

using Git & GitHub with a team

 🤓 🤓 🤓 🤓

WHAT we'll Cover

  • working with others in the same repo
  • merging and resolving merge conflicts
  • review of basic git concepts
  • making pull requests
  • using branches

the magical realms of git

It's all about the history

$ git log --oneline

A branch is essentially another copy of your repo that will allow you to isolate changes and leave the original copy untouched. 

BRANCHING

You can later choose to combine these changes in whole or part with the another branch or the mainline of development, or not.

BRanches

parallel lines of development with shared parents

Text

Text

image source: Atlassian git branching tutorial

How to Create a new branch

Always create a branch from up-to-date main

$ git switch -c favorite-component

On the main branch:
Make sure your local main branch is up to date with the remote main branch by pulling down:

$ git pull origin main

Now you're ready to create a new branch. Name it something that reflects the work you intend to do on this branch. Let's say you're building a component that allows you to favorite a post; you might name your branch favorite-component.

☝️ This command will do 2 things:

  • create a new branch named favorite-component
  • switch you to that branch

Come up with a branching strategy that will work for your Team

The Production branch

This is the shared branch that you deploy to production.  Feature branches are merged in via pull requests.

A Feature Branch (yours only)

This is where you will do your development work. You'll push changes to this branch, and open a pull request to main when you're ready to let other see your work.

Option 1   (recommended)

branch name: MAIN or PRODUCTION

branch name: <something-descriptive-of-what-you-are-building>

The Production branch

branch name: MAIN or PRODUCTION

It makes sense to have a branch that is deployable at all times. Merge the development branch here when it's ready to deploy.

Don't introduce broken code to the production branch!

A Feature Branch (yours only)

This is where you will do your development work. Push this up and open a pull request to the shared development branch.

The SHARED DEVELOPMENT branch

branch name: DEVELOPMENT

Merge separate feature branches to this branch for testing. It gives you a place to push changes and share work.

OPTION 2

(similar to the GitLab Flow workflow)

TEAM: How to start

  1. One dev creates a GitHub Organization, adds everyone on your team, and creates the repo. (⚠️ SKIP THIS STEP if using a GitHub Classroom assignment.)
  2. One dev makes the initial commit to start a new FE or BE project.
  3. That initial commit should be made on their local main branch and pushed to the remote main. This is the only time you'll commit on or push directly to main.
  4. Other devs on the team clone the repo (or pull if already cloned).
  5. Each dev chooses a task, creates a feature branch off of main, and begins work on that branch.
  6. Name the branch something descriptive of the work you are doing, not your own name.
  7. Write code and make commits on your branch.
  8. You can push your branch up to GitHub at any time (see the following slides on Individual Workflow).
  1. Each dev creates a feature branch
  2. Dev makes commits and tests locally on their branch.
  3. Dev keeps their branch up to date with main.
  4. Dev opens a Pull Request (PR) when ready and requests review.
  5. Teammate reviews PR (code review). Changes can be discussed on GitHub.
  6. If changes are needed, dev commits locally and pushes new commit to remote feature branch. This updates existing PR.
  7. When reviewer(s) + dev agree, the PR is merged on GitHub. Dev or reviewer can do this, using the green button on GitHub. 
  8. After merging, delete the merged branch remotely and locally. Do not keep working on a branch that has been merged.
  9. Remote main has changed, so each dev pulls down changes from remote to local main.
  10. Devs can merge the changes to their in-progress feature branch or  make a NEW feature branch from main to work on something else.

* This is basically the GitHub Flow.

Team Workflow*

INdividual: How TO START

$ git pull origin main

☝️ Fetches the latest commits from remote main and merges them into your local main

Step 1: STart on the Main branch

Get the latest code from GitHub (remote) into your local repo (on your computer).

$ git switch -c this-rad-feature

☝️ Creates the new branch called this-rad-feature and switches you to it.
Your prompt should change to show that you are on the new branch.

Step 2: create your Feature branch

Create a new branch, branching off from main.

You should be on the main branch when you run this command.

You should be on the main branch when you run this command.

INDIVIDUAL workflow

$ git pull origin main

This process is cyclic, so we'll jump in assuming that you are already working on a feature branch.

☝️ Fetches the latest commits from remote main and merges them into your local main

Step 1: Keep Local Main Up To Date

Get the latest code from GitHub (remote) into your local repo (on your computer).

⚠️ There should never be any commits on your local main that don't exist on the remote main, because no one is ever working directly on the main branch. Therefore, you should never have a merge on the main branch.

You should be on the main branch when you run this command.

INDIVIDUAL workflow

$ git merge main

👆This command merges your local main into the feature branch.

Step 2: Keep Your Feature Branch Up to date with main

You want to develop your feature in the context of the latest code, so you will have to keep merging the commits that are on main into your feature branch.

You should be on your feature branch when you run this command.

⚠️ The only way commits from other branches get onto your branch is via main. You'll need to be strategic about when you merge the commits from main -- it's up to you to decide when you need that work.
Don't pull remote main directly into your feature branch.

Don't merge other branches directly into your feature branch.

If there are merge conflicts, resolve them here on the feature branch.

INDIVIDUAL workflow

Why? This lets other people see your branch and even pull it down to run for themselves. 

$ git push origin feature-branch

👆When you run this command the first time, it creates a copy of the branch on GitHub. When you run it again, any commits that you have on your local branch will be transmitted to the remote copy of the branch. You can run it multiple times without messing anything up.

Step 3: PUsh your feature branch to Github

No one else can see what you have on your branch until you create a remote copy of your branch. 

You should be on your feature branch when you run this command.

When? At any time in order to share what you're working on, but you have to do it before you can open a Pull Request.

WHen to Open a Pull REquest?

✅ Finished all the code needed for this feature?

✅ Merged the most recent commits from main into my feature branch?

✅ Tested that the code works before and after merging the main branch?

If you answered yes to these questions,

Then you are ready to open a pull request + ask someone to review

✅ Need feedback from someone else?

INDIVIDUAL workflow

Step 4: Create a pull request on GitHub

When you've finished writing the code for a feature, you will want to propose merging your code into the main branch. A Pull Request allows teammates to review and agree to merge your code.

  1. Go to your repo on GitHub.
  2. Click on the button to open a Pull Request. Type in the details.
  3. Ask someone on your team to review your Pull Request.
  4. If changes are needed, you make them locally, commit, and push up to the same branch. You do NOT need to close the PR and open a new one; just add new commits to the branch.
  5. When the reviewer and the PR owner both agree 👍 then it's time to MERGE that pull request on GitHub. 🚀
  6. Merging the pull request incorporates the commits from that branch, plus a merge commit, into the main branch.

See these slides for more about how to create and review Pull Requests.

INDIVIDUAL workflow

Step 5: AFter Your Pull Request is mErged

Merging your branch means that your branch and all its commits have been included in the main branch on GitHub. 

Consequently, the remote version of the main branch has changed. To get the latest code into your local repo, you need to go back to Step 1 to pull down the latest changes from remote main to your local main.

Then, you can create a new branch for the work you intend to do next.

Once a branch has been merged, you should delete that branch. GitHub will give you a button to delete the remote branch, and to delete the branch locally you can run:
    git branch -d name-of-branch

⚠️ Don't continue working on a branch once it has been merged.

Merging brings two lines of development (branches) together, still preserving the history of each commit

Merging

Merge to get commits from one branch to another

MERGING STrategy

1. merge remote main to local maIN (local)

3. Merge feature branch to MAin On GITHUB 

$ git checkout main 
$ git pull origin main

2. Merge main to FEATURE BRanch (local) 

$ git checkout feature-branch 
$ git merge main

👉 This happens via a PULL REQUEST

When new code has been merged to remote main but you don't have it locally yet.

Once local main is up-to-date you can use it to update feature branches.

When you are ready to incorporate your feature into the main line

What could possibly go wrong??

Merge Conflicts

Conflicts occur when changes to the same line or group of lines occurred in each branch, and Git doesn't know which to choose. 

Here are lines that are either unchanged from the common ancestor, 
or cleanly resolved because only one side changed.
<<<<<<< HEAD
Your changes are reflected here in this section.
=======
Their changes are here in this section, in conflict with yours.
>>>>>>> other-branch
And here is another line that is cleanly resolved or unmodified.

<<<<<<<   indicates the start of a specific conflict

 ======= separates the two sets of changes that are in conflict

>>>>>>>  indicates the end of a specific conflict

The part above the ======= shows your changes,
and the part below shows the changes from the branch you're merging in.

Git marks where the conflicts are in the file with special characters.

Merge Conflicts
in VS Code

Documentation for resolving merge conflicts in VS Code

REsolving Merge Conflicts

All you need to do is edit the file that the conflict is in so that the file is the way you want it to be.

TALK to a teammate if you are not sure what to keep and what to delete

Delete everything that should not be there when the code runs, including the conflict markers Git put in the file.

Here's some detailed instructions from GitHub on resolving merge conflicts.

😃 it will all be ok! 😃

Then, save the file and go back to the command line.

Add (stage) the file(s) that you just edited to fix the conflict. Use git status to help you.

Finish by committing.

All ABout PUll REquests

a collaborative way
to request thaT BRanches be mergeD

Create a pull request when you want a collaborator to look at and approve changes on your branch. 

GitHub: How to create a pull request

CODE REVIEW

REviewing a Pull REquest does not mean you fix someone else's code

REVIEWERS:

  • Read the code on GitHub.
  • You might pull the code down and run it.
  • It is not your responsibility to check the code for mistakes!
  • Notice what is in this pull request. This is important knowledge sharing and the way you stay informed about the codebase!
  • Make good comments and ask good questions.
  • If you see an issue or have any concerns, talk to the owner of the PR.
  • If changes need to be made, the owner of the PR makes them locally and pushes up new commits to the open PR. 
  • The reviewer or the owner of the PR can merge the pull request when both agree it's ready to be merged in.

Good comments on Pull REQUests

Questions about what the code does

I have not seen this syntax before. What do these three dots do here?

Praise for something smart or cool or New-To-You

I didn't know you could do this in Python. Nice!

Helpful & REspectful suggestions

There's a method in the helpers file that might do what you want here (link-to-method). 
I notice your template isn't using this variable, so I think you can safely remove it from the view context.

❤️ Reasons to love pull requests & code review

Don't worry. Git is your friend.

We all make mistakes

...and the file has gone back to its state at the previous commit 🎉

UNDOING CHANGES IN YOUR WORKING TREE

If you haven't added (staged) files  or committed yet.

👉🏾 Your changes are gone from the working tree (and your editor)

Replace this path with the path to the file that has the changes you want to get rid of.

$ git restore books/models.py

👉 The file is removed from staging, but your working copy will be unchanged.

 UN-STAGING A FILE 

$ git reset books/models.py

When you want to keep the changes in your working tree

 $ git restore books/views.py

😌 DIscarding CHANGES completely

Your changes are gone from the working tree.

Reset the working tree to its state at the last commit

if you have not staged:

if you have ALREADY staged:

You can reset a file first and then discard all changes:

 $ git restore books/views.py
 $ git reset books/views.py

Or, if you want to discard everything, use the --hard option:

 $ git reset --hard

Undoing committed changes

Rewind, but learn to live with your regrets.

Find & copy the SHA of the commit you NOW regret

$ git revert 53d23c4

 👆🏽Notice that the original bad commit is still there, but now you also have another commit that undoes the changes introduced by the original one.

GIT REVERT

😳 ER, WHAT IF I ALREADY COMMITTED IT?

$ git log --oneline

👆🏽Your default text editor will open; you can just save it as is.

$ git log --oneline

keep calm & Follow these instructions

Things to Discuss & Decide Before you write code

  • Who is working on what? How will you assign tasks?
  • Who will create the first commit in the repo?
  • How will reviewing and merging pull requests work?
  • If you are deploying:
    • When will you deploy, and how often?
    • Who will deploy?

PULL OFTEN so you will have your colleagues' work.

PUSH OFTEN to keep your remote branch up to date.

COMMIT OFTEN to collaborate effectively.

PULL REQUEST so team members can review your work.

MERGE feature branches to main on GitHub

PRO TIPS

communication is key!

It's your job to keep your feature branch up to date with main. 

Tell your team when you are pushing up changes or have opened a pull request that needs to be reviewed.

MAINTAIN YOUR BRANCHES

WRITE GOOD COMMIT MESSAGES

Say why a change is needed or what it does.

Make sure your local and remote branches are in sync.

git status...git status...git status

 

Git resources

Questions?

Made with Slides.com