DEV Community: adelinealmanzar

Build Your First Mobile App Using React Native and Expo

adelinealmanzar — Thu, 21 Apr 2022 20:05:05 +0000

React Native is an open source framework used to make applications for mobile, specifically Android, Android TV, iOS, macOS, tvOS, Web, Windows and UWP.

Expo is a framework for React Native that helps us create the skeleton of our application and view our application’s progress.

To get our React Native application started, we need to create a project with Expo!

Setup our React Native App Using Expo

To setup expo, we would run
- npm install --global expo-cli to install expo globally
- we would then run npm init project-name to create our React Native project within the current directory (similar to create-react-app)
- the previous init command will prompt us, in the terminal, to choose the type of template workflow we’d prefer (folks typically go with blank on their first app if building from scratch)

Now that we have our project directory created, we can start our frontend server so we can view our application as we code.

Start our Client Server

to start our client side server, we would cd into our project’s directory and run npm start
this start command will automatically open up the devtools in our browser and start Expo’s Metro Bundler on a local port. To open a preview of our application, we can either:
- open the Expo Go application on our mobile device by scanning the QR code that appears in the browser
- OR we can run our preferred simulator (using i for ios or a for android). If we’d like to view a preview of our frontend application within a simulator, we would need to install XCode first.

Here’s where the fun begins! Now we get to code in React Native!

Code in React Native

React Native provides core components, which are pre-built components with mobile optimization. Below are a few starter core components and APIs, which may be useful for when building our first React Native application and getting a feel for this framework if we’ve never used it before.

Helpful Starter Core Components

View the view component is the most fundamental React Native component that acts as a container with flexbox, style, some touch handling, and accessibility controls. The View in React Native is the mobile equivalent to <div> in JSX or HTML.

Text the text component in React Native is for displaying text. It is equivalent to JSX or HTML relative text tags, such as <small>, or header tags, such as <h1>, <h2>, <h3>, or paragraph tags, such as <p>.

Image is a component that displays different types of images. This component is similar to the <img> tag in JSX or HTML.

ImageBackground is a component that acts similarly to the Image component and it allows any children components to be layered on top of it self. This component is the React Native equivalent to using a background-image or backgroundImage property within the styling of a custom JSX component.

TextInput is a component that allows users to input text into the application via a keyboard, which (when using on a mobile application) usually slides on screen. The TextInput props allow for configurability of auto-correction, capitalization, placeholder text, and different keyboard types. To read and create a call back function based on a user’s input, we would use the onChangeText event.

Additionally, there are other types of TextInput events as well, such as onSubmitEditing (which elicits a callback function when the submit button is pressed) and onFocus (which blurs texts, such as when inputting a password). TextInput and its event handler props are similar JSX forms, which usually use the <form>, <input>, and <label> tags along with the onSubmit event.

ScrollView or FlatList are components that enable viewing children components via screen scrolling capabilities with a touch locking ‘responder’ system. ScrollView loads all of its children components on first render, so if we have a bunch of child components that need to load at once we would see a performance downside. FlatList improves this performance downside by loading its children components ‘lazily’, when the children are about to appear on the screen as the user is scrolling.

Button or Pressable are components that enable event handlers via user interactivity. Button is a simple component that acts as a button and supports minimal levels of customization. The Pressable component allows for more complex customization as well as more complex user interactions with itself and its children components.

React Native also offers other types of interactive pre-built components depending on what we need for our app. Some notable mentions are TouchableOpacity, which dims the opacity of its wrapped View on press down, and TouchableWithoutFeedback, which allows for pressing anywhere within its singular View child. Although there are warnings in the documentation to avoid using TouchableWithoutFeedback unless we have a good reason, this component is cool because it can be used for user presses anywhere on screen (useful for games).

These touchable components are similar to using the <button> tag or the<input> tag with a submit type in JSX or HTML.

Some Useful APIs

StyleSheet is an abstraction that is similar to CSS StyleSheets, almost like ReactJS styled components and inline styling mixed together. This component is pretty cool because it supports reusability in allowing for pre-defined variables within its style values.

Dimensions is an API that allows us to get the height and width of the currently used window. For developing in mobile, this API is extremely useful if we want to develop dynamically-styled components that render well on sorts of different of mobile devices and screen sizes.

Additional Components

These components mentioned are just some of the most fundamental and most used components, but React Native offers a plethora of pre-built core components and APIs. In addition, the community also offers a bunch of custom pre-built React Native components for whatever use case we may need!

Resources

Common Git Mistake Fixes

adelinealmanzar — Tue, 05 Apr 2022 21:01:38 +0000

Everybody makes mistakes and everybody has those days especially when it comes to git, so here is a summary of solutions to common git errors (although of course there may be many approaches).

Circumstance: Made code changes and/or staged changes before creating a new branch

we either made changes to our code or made changes and staged those changes to our index while in a wrong branch

If we made changes to our code before branching off of our starter branch (for ex: main/master) or we made changes and staged those changes, we can run git status to check which files contain changes.

Since we haven’t committed our changes to our current wrong branch’s history yet, we can simply run git checkout -b new_branch_name and our changes (staged or not) will follow us to whichever new branch we just created. From our new branch, we can then add and commit our changes to this new branch’s git history.

We’ve tackled a slip up for when we’ve been wanting to create a new branch; but, if we want to move our changes to a pre-existing branch, we would need to follow some kind of stashing workflow.

Circumstance: Made code changes and/or staged changes before checking out a pre-existing branch

we made changes to our code and forgot to checkout a pre-existing branch
we may have added/staged our changes as well

If we made code changes in the wrong branch but those changes haven’t been committed yet, we can use a git stash workflow to shelve/stash our changes before we checkout the proper pre-existing branch.

`git stash` Workflow

When running git status we can view which file changes we would like to be taking with us to the proper branch. Then, we can run git stash, which will stash/shelve all of our current changes (whether added/staged or not). After stashing, we can checkout the pre-existing proper branch with git checkout <correct_branch>. Once we’re in the proper branch, we can run git stash pop to pop all of our changes out of the stash/shelf. After popping, we would be able to continue our usual git add and git commit workflow to add and commit those changes to the proper branch.

Note that if we had changes staged before our stash and we later popped our stashes, those staged changes would be un-staged on-pop automatically.

So the full workflow would look like:

git status to check which changes we would be stashing
git stash to stash/shelf all of our changes
git checkout <branch> to checkout the proper branch
git stash pop to remove the most recent stash from our shelf and track those changes in our proper branch
git add & git commit workflow to add/stage and commit specific files to our proper branch’s history

If we altogether committed in the wrong branch, we can use a resetting workflow.

Circumstance: Committed in the wrong branch

we made changes to the code
git add . we staged all of our work
git commit -m "my first commit!" we committed our work
git branch we check our branch and OH NO! We realize we were in the wrong branch all along

If we added and committed our changes to the wrong branch locally, we could always rollback however many commits we need and move our un-staged changes into a new branch.

First, we would run git log to check our commit history and view how many commits we would like to undo.

Then, we would run git reset HEAD~N where N is the number of our commits to undo.

If we do git log again, we can see that our commits are no longer in the history of the current wrong branch. When we do git status, we can also sanity check that the changes have been tracked and are ready to be staged.

Because we would be checking out a new branch, we can simply run git checkout -b new-correct-branch where new-correct-branch is the new branch we wish to track, stage, and commit our changes in. Note: if were checking out a pre-existing branch, we would probably need to run our git stash workflow to move our changes to the proper pre-existing branch.

Once we’re in our new-correct-branch, we can run git add <paths-for-files-we-wish-to-add> (or we can also run git add . to add all of our changes that appear when we run git status). And then we can run our git commit -m "insert commit message here" to finally commit our changes to the proper branch.

If we run git log, we should see the proper commit history in our proper branch.

So overall the workflow would look like so:

git log to check our commit history to determine the number of commits we would like to roll back
git reset HEAD~N to reset the head of our current wrong branch back by our previously determined N number commits
git log to sanity check that our commit history no longer contains the wrong commits
git status to sanity check that our changes are being tracked and ready to move with us to whichever branch we checkout
git checkout -b new-correct-branch to create and move into our new proper branch that will store our accurate commit history
git add <file-paths> to stage our desired files
git commit -m "insert commit message here" to commit our changes to the proper branch history
git log to sanity check our current proper branch’s commit history

Sometimes our mistakes aren't related to where our changes were made. Sometimes we pulled down the wrong branch altogether, so then what?

Circumstance: Pulled the down the wrong branch

thinking we’re in branch1, we git pull origin branch2 and OH NO! We realize we pulled down the wrong branch from the remote to our local branch

If we pull down the wrong remote branch to our local branch, we can always run a hard reset of the current branch with git reset --hard origin/current_branch. Note of caution: reset --hard is destructive in nature, so it will remove all staged and un-staged changes to overwrite the current local branch.

If we want to save our changes somewhere before we do a hard reset of the branch, we can use the git stash workflow mentioned above.

TLDR:

We shouldn’t get into the habit of making mistakes, but there are ways to fix them
We can always checkout a new branch if we’ve made staged or un-staged changes in a wrong branch as long as we don’t commit those changes yet
If we’re trying to move our changes to a pre-existing branch, git stash is a pretty useful command for shelving our changes temporarily
If we ever do commit our changes to the wrong branch, we could always run a reset of any branch to rollback commits (and then continue to move our staged or un-stanged changes to the proper branch)
If we ever pull down the wrong branch, we could run a hard reset

For Funsies

Here are some extra useful commands:

git stash list to view all of the stashes in our shelf
git stash pop <stashID> to pop a specific stash
git stash drop <stashID> to delete a stash from our shelf use with caution
git reset -- <filepath> to un-stage a specific file from our index
git checkout <filepath> to undo/delete all changes of a specific file use with caution

Resources:

git stash documentation: https://git-scm.com/docs/git-stash
git reset documentation: https://git-scm.com/docs/git-reset
git checkout documentation: https://git-scm.com/docs/git-checkout

React Context vs. Containment

adelinealmanzar — Mon, 14 Mar 2022 18:56:46 +0000

Context allows us to pass data through the component tree without relying on props every time (often referred to as ‘broadcasting’ data). Implementing context is useful for when we need many components at different nesting levels to have access to the same data (ex: UI theme, locale preference, current user) or in other words, when we need data to be considered ‘global’.

Implementing Context

The following code breakdown is inspired from the UI theme use-case example provided by the React documentation.

To use and update context, first we would need to define our theme object from which we will be pulling the context values from.

const themes = {
  light: {
    foreground: "#000000",
    background: "#eeeeee"
  },
  dark: {
    foreground: "#ffffff",
    background: "#222222"
  }
};

Then we need to use React.createContext to create a context for theme with a default value. In the code example below, we’re using the themes.dark object as our default value.

const ThemeContext = React.createContext(themes.dark)

We then need to use .Provider to provide an updated value for the specific context.

function App() {
    return (
        //provide the theme context's value to change/update the previous theme context's value
        <ThemeContext.Provider value={themes.light}>
            <Navigation />
        </ThemeContext.Provider>
    )
}

To access our theme context value, we can use the useContext(SpecifiedContext) hook. useContext(ThemeContext) accepts our ThemeContext context variable in the format of an object (the returned object value from React.createContext) and it returns the current context value for the specific context. We can save this returned context value to a variable in order to use it in our code.

function ThemedButton() {
    // save theme context value to theme variable
    const theme = useContext(ThemeContext)
    return (
        // use theme variable to manipulate button styling
        <button style={{ background: theme.background, color: theme.foreground }} >
            My styling comes from theme context!!!
        </button>
    )

function Navigation() {
    // return our ThemedButton component to display our ThemeButton
    return <ThemedButton />
}

The current context value is determined by the value prop of the nearest SpecifiedContext.Provider above the calling component in the tree. When the nearest SpecifiedContext.Provider above the component updates, the useContext hook will trigger a re-render with the updated latest context value.

Implementing Containment

Something to consider is that context makes component reuse harder. So, if we need to simply avoid the prop code redundancy of passing props through unnecessary intermediate levels, we should consider using the children prop within component composition. Component composition is React’s original development model of using either explicitly defined props or using implicit children props to pass down JSX components or elements via containment.

children is a special prop that passes implicit children elements directly into a component’s output via nesting within the parent component.

function ChildComponent(props) {
    return (
        <div>
            {props.children}
        </div>
    )
}

function ParentComponent() {
    return (
        <ChildComponent>
            <h1>I am the first child prop!</h1>
            <h2>I am the second child prop!</h2>
        </ChildComponent>
    )
}

We can make our own custom convention if we’re needing to use a more specific children-prop-breakdown.

function ChildComponent(props) {
    return (
        <div>
            <div>{props.left}</div>
            <div>{props.right}</div>
        </div>
    )
}

function ParentComponent() {
    return (
        <ChildComponent>
            left={<LeftChildComponent />}
            right={<RightChildComponent />}
        </ChildComponent>
    )
}

Containment is useful because we can pass down entire components or JSX elements down as props instead of passing down props through intermediate components.

To read more on composition, feel free to refer to the React documentation on the topic.

TLDR:

Containment can be used for most use cases when we simply need to decouple a child from its immediate parent (so that we don’t have so much redundancy in passing down props within intermediate relationships). Usually, this means that children and parent components have a singular nesting pattern.

Context, on the other hand, is useful for ‘broadcasting’ our data - accessing data by many components at different nesting levels.

Resources

A Git Pair Programming Workflow WalkThrough

adelinealmanzar — Tue, 01 Mar 2022 01:51:32 +0000

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-branch push 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-name clone the remote repository to the new driver’s local machine
git fetch --all fetches all remote branches and makes those branches available locally to the new driver
git checkout personA-branch in 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 local personA-branch branch
git branch to sanity check that new driver is in the proper personA-branch branch.
git pull origin personA-branch pulls 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)
New driver can keep making code changes and adding those to the commit history by repeating steps 6 - 11
git push origin personA-branch update remote personA-branch with 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

Resources

A Git Individual Workflow WalkThrough

adelinealmanzar — Mon, 14 Feb 2022 21:06:09 +0000

Git and its workflows can be initially hard concepts to wrap our heads around.

Git is a version control system that lets us keep track of and manage code history. Github is a cloud-based hosting service that helps to manage Git repositories (repos).

Some cool things about Git are that it's based off of a branching model and it's mostly local. Github, on the other hand, is exclusively remote/cloud-based, which allows different people to view, clone, and collaborate with our code.

Flow of Data with Git and Github

Our workflows are going to follow the interaction between our machine (local changes via Git) and the hosting service (remote changes stored via Github history).
For the purposes of simplicity, from this point onwards we're going to use 'local' and 'remote' keywords to refer to our local machines and remote repositories/branches.

Data can be considered within two types:
(a) dynamic instance data, such as code files and their contents
(b) static metadata, such as our branches and commits with user information (or 'git blame' data)

At a high level we could say that our data moves from local locations to remote locations and vise versa

Walkthrough of personal workflow

Now what happens when we make changes locally and how do we do that?
After we copy the remote's repository with git clone, we are able to work within Git's branching system locally.

When we git pull we're pulling a copy of a specific branch from the remote repository to our local workspace. If there haven't been any changes to the remote repository, then when we git pull we will get an 'Already up to date' message.

user@ repo-name % git pull origin main
From github.com:adelinealmanzar/repo-name
 * branch            main       -> FETCH_HEAD
Already up to date.

We should git pull only the remote branch name that matches the local branch we are currently in.
We can check which branch we're currently located in with git branch.

user@ repo-name % git branch
* master

Imagine your master or main branch is the trunk of a tree. Whatever branches we create out of that trunk will be almost like draft branches because they will only exist in our local workspace and then eventually into our local repository, where those draft branches will be reviewed and edited.

When we git checkout -b any-new-branch-name we're creating new local branches off of the master/main root branch and we're moving to that branch.

user@ repo-name % git checkout -b any-new-branch     
Switched to a new branch 'any-new-branch'

We can do git branch again to sanity-check that we're in fact in our new branch

user@ repo-name % git branch
* any-new-branch
  master

Our new branch will end up tracking the version history of our changes via commits. But before we commit to our official remote repository history, we must stage those changes in our index. We can check which files are staged via git status. git status displays files that have (or have not) been changed in the working directory and the staged directory.

If we've made no changes to any files, running git status will tell us that we have a clean working tree

user@ repo-name % git status
On branch any-new-branch
nothing to commit, working tree clean

So lets add some code changes and then see what git status looks like.

user@ repo-name % git status
On branch any-new-branch
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   src/components/Header.js
        modified:   src/components/MainContainer.j

no changes added to commit (use "git add" and/or "git commit -a")

Any modification that we make to a file will show up under our workspace area(located after 'changes not staged for commit' in red). In order to add those changes to our index, we must run git add <file-name>.

user@ repo-name % git status
On branch any-new-branch
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    modified:   src/components/Header.js

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   src/components/MainContainer.js

git add adds new or modified files (from our workspace) to our staging area (located after 'changes to be committed' in green). git add gives us the benefit of choice in deciding which files and changes we would like to commit. Based on Github's Git Guides, commits should be logical, atomic units of change. Tech teams usually organize their commits based on whichever rule of logic their organization/company practices. An example rule may be that each commit must contain all changes made to an individual file or that each commit must bucket one specific value within a feature. Why implement logical rules for commits? A clean commit history is usually easy to read, helpful for debugging, and helpful for understanding which changes we might end up needing to revert.

To add our changes to an individual commit and create an easy-to-understand commit message, we run git commit -m "any commit message"

user@ repo-name % git commit -m "perf: cleanup/removed debugging comments"
[any-new-branch 71a72da] perf: cleanup/removed debugging comments
 1 file changed, 1 insertion(+), 1 deletion(-)

Commit messages should describe what kind of change we've made to our code. In the above example, our commit message indicates that our changes included file cleanup of removing some sudo-code that was no longer needed. The perf header indicates that the change we made was a removal. This perf header is one of several semantic-release headers and footers that we can add to our commit message to indicate the type of change we've made to our code (addition, removal, patch/fix, or breaking change). To read more on semantic headers, you can read more here.

After we've committed our changes, we can git log to view our commit history and sanity check that our commit is in the right place in history. The log commits are in order of most to least recent, so our most recent commit should be at the top, which we can see in the code below.

commit 71a72da43ca6cdd9774c8abf00a96fb3f6c6d0b9 (HEAD -> any-new-branch)
Author: Adeline Almanzar <almanzar.adeline@gmail.com>
Date:   Sun Feb 13 11:31:50 2022 -0800

    perf: cleanup/removed debugging comments

commit 84c056344662503041c6fd3d5365f805dfca08e8 (master)
Author: Adeline Almanzar <almanzar.adeline@gmail.com>
Date:   Mon Feb 7 20:38:54 2022 -0800

    third deliverable

Each commit in the log will have a commit ID, information on the author of the commit, the date & time of the commit, and the commit message.

Now that we've committed our changes and done our sanity-checking, at this point we can keep going through the changes workflow to continue committing our changes to our local repository.

Once our local repository is at a ready-enough state for our team's review and/or collaboration, we can push our changes to the remote repository with git push origin <branch-name>.

user@ repo-name % git push origin any-new-branch
Enumerating objects: 29, done.
Counting objects: 100% (29/29), done.
Delta compression using up to 8 threads
Compressing objects: 100% (28/28), done.
Writing objects: 100% (28/28), 286.05 KiB | 3.11 MiB/s, done.
Total 28 (delta 0), reused 0 (delta 0), pack-reused 0
To github.com:adelinealmanzar/repo-name.git
   84c0563..71a72da  any-new-branch -> any-new-branch

git push will send all of our local repository's commits and branches to the remote repository (in Github). When we sign into Github and visit the remote repository, we should be able to create a new pull request(PR). We can think of our pull request as a form that we submit to our team with the request to officially merge our changes to the remote branch we originally branched-off of. PRs enable us to share the purpose of our code changes in layman's terms. They also enable our team members access to review our changes and make changes themselves (stay tuned for my next blog post on collaborative workflows).

TLDR: Personal Workflow Summary

git clone repo-link && cd repo-name: make a clone/local copy of the 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 new-branch-name: 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: view our commit history to sanity check that our most recent commit is at the top of the history list
git push origin new-branch: push our local new-branch and its data to the remote space (Github)
Create pull request on Github
git branch: sanity check that current branch is still new-branch
git pull origin new-branch: pull (to our local new-branch) any changes that might have been added from the remote new-branch
(a) If making changes to the same branch, repeat steps 6-12 (b) If making changes to a different branch, repeat steps 5-12

DEV Community: adelinealmanzar

Build Your First Mobile App Using React Native and Expo

Setup our React Native App Using Expo

Start our Client Server

Code in React Native

Helpful Starter Core Components

Some Useful APIs

Additional Components

Resources

Common Git Mistake Fixes

Circumstance: Made code changes and/or staged changes before creating a new branch

Circumstance: Made code changes and/or staged changes before checking out a pre-existing branch

git stash Workflow

Circumstance: Committed in the wrong branch

Circumstance: Pulled the down the wrong branch

TLDR:

For Funsies

Resources:

React Context vs. Containment

Implementing Context

Implementing Containment

TLDR:

Resources

A Git Pair Programming Workflow WalkThrough

Data Movement

One Workstation Workflow: for Pair Programming Team Members

TLDR: One Workstation Workflow (for Pair Programming)

Resources

A Git Individual Workflow WalkThrough

Flow of Data with Git and Github

Walkthrough of personal workflow

TLDR: Personal Workflow Summary

Resources:

`git stash` Workflow