For the last post in this series on React state I gave a general overview of state and discussed some of the key differences when working with state in functional components and class components. In this post, I’m going to be focusing more on some of the common code patterns that you can use when setting state across different shapes of data, including basic primitives, arrays, objects, and arrays of objects. This post will be pretty example-heavy, so in an effort to try and narrow our focus, here are some things to keep in mind about the code examples I’ll be using:

I’ll exclusively be using functional components with the 

 hook but many of the patterns are quite similar when you’re using class components so it generally isn't too difficult to translate.

Whenever I’m working with state held in objects and arrays I’ll be making immutable updates to the state by making copies of the state before making the updates. I’ll be using the ES6 spread operator to create the copies but in codebases out in the wild I'm sure it’s not uncommon to see copies being made with one of the following, older methods instead:

I'll be focusing on the different shapes of state data and the code that's responsible for setting the state but I’ll be omitting some of the other component code that would ordinarily be necessary to make things fully functional. There will be some code inside functions where you can assume the functions are being called and passed the parameters shown, and there are others where you can assume that you're operating on values that are being held in state or being passed in as props. It's all really interchangeable and just depends on how you structure your components and if you do inline functions or declare the functions on the component.

As always in programming, there are many different ways to accomplish the same things that I'll be showing you, particularly when working with state in objects and arrays. The examples I'll be using will mostly use more modern syntax and more concise code patterns.

With that out of the way, let's start out working with basic primitive values.

There are a number of different primitive value types in JavaScript, but for this article, we’ll just be focusing on strings, numbers, and booleans since these are the primary primitive types used. Primitive values are typically easiest to work with because they’re naturally immutable, which means that you can’t change a primitive value once it’s been assigned to a variable (although you can typically can reassign a variable to a new value). For our examples, let’s assume we’ve initialized the following string, number, and boolean type state variables:

 state variable is defined as an empty string because we’re using that state value as the input field’s value (what React calls a Controlled Component) so it needs to be a string in the browser, however, you’ll often need to convert input numbers from strings to numbers, particularly if you want to be able to use the number in calculations or when saving the number to a database. Common exceptions to this are phone numbers and unique IDs, which you’ll typically want as strings.

At the end of the day, whenever you want to set state, you just need to call the corresponding state-setting function with the value you want to set the state to, so for our basic primitives it's as easy as doing something like this:

If you have some additional logic that you need to perform before setting the new state value you might prefer to make your state-setting call inside of a separate function, but in many situations, like when you’re just setting state directly from user input without any client-side validation, it might be perfectly fine to just set the state from inline-functions defined directly on the element that is firing the related event. For instance:

If you wanted to handle all the logic and setting of these pieces of state from separate functions then you could do this for the event handlers instead:

In JavaScript any time you have a function that is handling an event, whether it’s an inline function or a reference to a function that exists elsewhere, the function will automatically be passed an event object that contains all the information about the type of event and where it occurred. In the inline functions above, you can see I’m referencing the event object as 

, but even in this second set of examples where we’re just referencing the functions defined elsewhere, we’re not explicitly passing the functions anything but those functions will still automatically be passed the event object. If you need to pass the function a piece of data (e.g. an ID so you know what to target and update) then you’ll probably want to use an arrow function or a pre-ES6 anonymous function:

In situations where you don't need the event object you can omit it. For instance, if you just wanted to pass in the examples above you would just delete 

While you ultimately just need to pass your state-setting function the value that you want to update a state variable to, note that you can also put JavaScript 

inside of your state-setting functions so that you can handle logic and calculate the new state directly inside of that function, which helps keep your code self-contained and concise. Here are some examples:

Note that the examples above use a callback function, often referred to as the “updater function”, which is a function the React API gives you access to inside of the state-setting function. The argument React passes to this updater function is the previous state value for the corresponding state variable so that you can use that value to ensure that your state is getting updated correctly when the new state is calculated based on the prior state. Instead of 

 you could technically name the variables anything you want and that variable will represent the previous state value before the current state-setting call updates it. You can use the updater function anywhere you’re setting state, and you’re not required to use it when using inline state-setting functions; it’s just a best practice for components like counters and togglers where you need to rely on the state being accurate before making updates. Without the updater function, you could write something like the examples below and it will often still work just fine, but due to the asynchronous nature of how React batches state-setting calls, 

you’re susceptible to getting bugs that cause inaccurate state values when the new state value is dependent on the prior state value being accurate.

 refer directly to the variables that you defined in the 

 calls as opposed to arguments passed in by React that reflect the guaranteed updated state.

If you have more logic and calculation that needs to occur before you set state you can also add curly brackets and break the inline function onto multiple lines like below, but you’ll probably want to be cautious when doing this because it can muddy up your JSX code quickly, making your code difficult to read and less reusable:

Back before we had React Hooks, each class component had one  

 object that would hold all the necessary state properties for that component and its related components. With React Hooks 

it’s generally recommended that you separate each state property out into its own dedicated variabl

e, but if you want to you can still store multiple state properties in one object in a similar fashion to class components. For example, let’s make a User component that stores a 

Update Existing Primitive Object Value / Add New Primitive Value

Unlike when working with state in class components, when you’re updating a state object in functional components you need to manually merge updates. In addition to preserving immutability, this is why I use the spread operator in the object above; it copies over all of the existing properties of the state object and adds/overrides the additional properties that are passed to the function. When you’re setting state in class components you only need to specify the properties that are being updated.

Here’s a more reusable function that is similar to the functions above, but it allows you to dynamically make updates based on values passed into the function:

Add something to an array nested one-level down in object

You can also do something similar to the pattern above with nested objects.

When working with arrays outside of React most JavaScript developers are comfortable using built-in array methods such as 

, but the problem with using methods like these in React is that they mutate (i.e. change) the original array. so now that we’ve moved on to working with arrays and objects, which are referenced

, it’s necessary for us to ensure that we keep our state data immutable by making copies of the data before making updates to it. To achieve this we’ll be using the spread operator and array methods like 

 that create a new array instead of mutating the original. For our examples let’s work with an array of users:

All of the patterns above can be used on either arrays of primitive values or arrays of objects (arrays of pretty much anything, really, but primitives and objects are probably most common), but the examples below we'll only work with arrays of objects. Let's assume these objects store 

 properties. Since working with arrays of objects adds some complexity I’ll have each of the examples in a dedicated function.

That’s all I wanted to discuss about React state for now, but I hope, dear reader, that you gleaned something useful from this pair of posts. Thanks for reading and may your powers of React proliferate in 2021 and beyond!

Interior glass facade of the Harpa Concert Hall in Iceland. 

unsplash

States of React State (Part 2)

React Hooks have been around for about a year now and they’re a fantastic addition to the library. For those of you new to hooks, they allow you to hold state and do things like key into lifecycle methods from within lighter-weight functional components instead of having to use class components. If you had to choose one type of component to invest your time into learning it’s probably safe to say that it’s functional components with hooks, but class components are still very relevant today since there are sure to be many apps written in classes that work perfectly well and don’t need to change, and others that will probably continue to make transitions to hooks for years to come (hooks can be incrementally adopted so it's not like you have to only use classes or hooks), so at least for the time-being, React developers should be comfortable working with both types of components. This can of course be a little burdensome for newer React developers who have to simultaneously learn the two different formats, so in this pair of blog posts I wanted to briefly go over state in React, highlight some of the differences between working with functional and class components, and also show you some of the common patterns used when setting state in React. These posts will primarily be aimed toward newer React and JavaScript developers, but they should also serve as a handy reference for anybody trying to remember how state works in each type of component and how to set state in its various forms. Note that I won’t be discussing more advanced forms of state management like React Context or Redux-like patterns, nor will I discuss component lifecycle in very much detail, but keep in mind that these are also important topics to learn when considering how to best manage React state so you should learn about them as well.

State, in programming, can refer to a number of different things, but it generally refers to the current condition, shape, or order of part of a program. In React, state is where you keep your variables and the values they hold, which React then uses to determine how to render the user interface and interact with the rest of your app. React state has an initial, default value that will typically later be updated any number of times as the user interacts with the page. Once state is updated (i.e. “set”), other components and parts of the site will react to those changes, whether that includes something like rendering new content to the page, fetching new data from an API, or updating a record being stored in a database. Before hooks were released, React state had to be stored in ES6 class components, which are great but they can often be bulky with a lot going on. Now that we have the 

 hook we can manage state in more simplified functional components and generally keep our front-end components easier to use, reuse, reason about, and test.

The syntax you use for working with state in classes and functional components is different, but many of the general principles are the same, so once you learn one it’s pretty easy to apply those principles to the other. The types of code patterns you use for setting state will apply to either form, which is nice, but to further add confusion for newer React developers, there are many different ways to set state depending on if you’re using newer ES6 syntax like the 

 or more traditional methods. The good news is that these patterns are really interchangeable between the two types of components as long as you have a tool like 

 (apps created with Create React app use Babel by default) that converts the more modern JavaScript syntax into a form that older browsers can understand.

When working with state in React it’s usually recommended that you adhere to keeping your state immutable, which means that you shouldn’t directly update state objects once they’ve been created. Immutability has a host of potential benefits but one of the primary reasons React places emphasis on it is because it helps React efficiently determine when it needs to re-render components. Primitive JavaScript values like strings, numbers, and booleans, are already immutable, but when you’re working with state that’s stored in a referenced data-structure like objects and arrays (arrays are just a type of object) you should try to ensure that you first make a copy of the data, then make modifications to that copy, and then set the new state with the modified copy. The way you go about immutably updating state often requires more care than you ordinarily would use if you were just modifying an object or array directly. All of the code examples in these blog posts will have immutable state updates, and in the next post in this series I’ll be focusing more on showing you some of the patterns you tend to see when setting state across different shapes of data that state is commonly held in. For now, I’d like to go over class and functional components and highlight some of the differences.

The following is an example of a simple class component:

 from the React library by name, but you can also just use it without explicitly importing it by adding the 

 property onto the main React import like 

In this example I have one state value called 

 and when the user types text into the input field the 

 function handles taking that value and updating the 

 state. Note that I’ve defined the state inside of the class constructor, which is a commonly used way of writing a class component, but it should be noted that you’d really only use a constructor when you need to bind class methods but you don’t want to use auto-binding ES6 arrow functions (I am using traditional binding in the example). The constructor is often used to initialize state (

) but you technically don’t need the constructor to do this as long as Babel is set up to handle compilation and add the constructor “behind-the-scenes”. This next example shows how the component above would look without a constructor:

Notice that the only things that have changed now that the constructor is gone are the state, which is now a property directly on the class (this “class property” syntax is currently in the final stages of refinement before it will formally be added to JavaScript but you can use it now because of tools like Babel), the 

 function in the constructor we use an arrow function to bind it.

When it comes to setting state in a class component you’ll typically be calling React’s 

setState(stateUpdater, [optionalCallback])

. I’ll go over the different forms of using the API shortly, but the most common way to use it is to pass it the 

 argument an object with the properties you want to update. In the following example, we’re passing it 

 state value will be updated to hold the result of what the user typed into the input field:

A common mistake to be aware of in React is that if you attempt to set state directly without using the 

 function (e.g. in a class component doing something like 

), it will still technically update the state, but since you didn’t use 

 React won’t know that anything was updated so your components won’t rerender to show updated state values and you’ll violate the principles of immutability that I mentioned earlier. The only time it’s OK to not use 

 is when initializing state with a value when the component first loads:

Another thing to be mindful of when setting state in React is that 

, so the state isn’t always guaranteed to be updated before you attempt to do something else in your code where you’re relying on the state being updated, particularly when you’re making multiple 

 calls in close succession. For instance, if you make two back-to-back calls, React might batch the first call with the second so that once the second runs, the first state call may not have updated state yet. 

More often than not you'll start out just using the first form of 

 where you pass it an object with the updated state value, but for best practices, there are a couple of different ways you can take advantage of the API to help ensure that your state has been updated before you act on it. The first way is that you can pass in a function as the first argument to 

 represents in the syntax above). React will then pass this 

 the previous state as the first parameter (you will often see this parameter referred to as “previous state”, “current state”, or just “state”, but in the context of the  they all mean the same thing: state before the current setState call has updated it). You can then calculate the new state value based on the previous state, and then you just need to ensure that this function returns an object with the new state value. A common example of employing the 

 is a counter component that keeps track of a count and uses 

 to increment the count based on the previous count:

The API also allows you to pass it an optional callback function as the second argument, and this function will run once the state has been updated:

When learning about React classes you may also see better developers than myself recommend using instead the 

 lifecycle method API instead of the callback to 

. I’ve used both approaches and honestly I'm not very familiar with the differences between the two but I did find 

 that seems to do a good job of explaining some of the nuances and edge cases where it’s more appropriate to use one over the other. As I mentioned before, when you're a newer React developer than isn't as familiar with all of the different React APIs, you can often get away with just setting the state object directly without worrying too much about if you need to use the 

, but if you ever find yourself in a place where you’re experiencing problems with your state not updating correctly even though you’ve debugged the hell out of everything and it all looks correct, then you could very well have an issue with 

 being a mischievous little asynchronous rascal.

Now that we’ve discussed working with state in class components we can move our discussion to working with functional components and the 

 hook. Before hooks were introduced, functional components were usually pretty basic components (often affectionately referred to as “dumb components”) that were unable to hold state and were only responsible for the presentation and rendering the user interface based on state passed down as props from parent components. Now that we have the 

 hook we still keep all the benefits of functional components but we can also store state in them instead of being using class components. To start using the 

 property of React, instead of explicitly importing 

 you can write a basic JavaScript function, usually in the form of a regular function declaration or an arrow function, and then you can add the 

 hook to setup your state with the name of the state variable, the name of the function that updates the corresponding variable, and the initial value for the variable. The syntax is 

const [stateValue, setStateValue] = useState(initialValue);

. This syntax can seem weird at first for newer JavaScript developers but it’s just using 

to return an array with two values from the 

 function call: the first index of the returned array is the state value while the second is the function you use to update the first value. The function from the second index is similar to the 

 function that you use with class components except now each state variable is declared from a separate 

 call and gets its own dedicated state-setting function. Since these returned values are being destructured you can name them anything you want, but the convention is to name the state-setting functions the same as the corresponding state values but prefixed with “set”. For instance, if you have a state variable named “age” then you should try to name the function “setAge”. Here’s a comparison between defining some state variables in a class versus a function:

Regardless of if you use a class component or a functional component you can track as many state variables as you want, but you should generally try to limit the amount for each component so you can keep your components smaller so that they’re easier to reason about, test, and reuse.

Here’s an example of writing the CreateUsername component from the class component examples earlier but instead with a functional component and the 

Note some of the key differences between the class and functional forms:

there’s no longer any constructor function

instead of a generic state object that holds the 

 state value as a property you just declare the 

 state value directly as its own variable

 method with just the name of the method we declare it as an arrow function expression, although you can also define it as a function declaration like 

since we’re no longer working with classes there are no references to the 

You can see that things are quite a bit cleaner with functional components, but the difference becomes even more apparent with more real-world components that have a lot more going on than this basic example.

In the previous examples, we’ve just been updating state with a basic string value but it’s important to keep in mind that when you’re updating an object, class components will 

 updates into the state object for you while with functional components you need manually merge state objects or else your results might not be what you expect:

that you keep things immutable and merge the objects without losing properties you should use the spread operator or JavaScript’s 

 (we’ll see more examples in the next blog post). Just like with the class-based 

 function, your hook-based state-setting functions also accept an 

 as the first argument, and when you’re merging objects it’s usually advisable to use that function so that you can reliably have access to the current state values

Often when developers go from working with state in classes to functional components it seems natural to jam all of your state values into a single state object, similarly to the one 

 object that you have in classes, but with hooks you generally will want create separate variables that make separate calls to 

 (remember you can have more than one state value in functional components). You can certainly emulate the state object from class components by just using a state object in your functional components, but if you do then it should really only be for state values that are directly related (e.g. address field: 

const [address, setAddress] = useState({ street: ‘’, city: ‘’, state: ‘’, zip: ‘’ });

) and you just have to remember that the onus is on you to merge the data when updating.

 there’s no second argument that accepts a callback that runs after the state has guaranteed to have been updated. That being said, you can accomplish the same thing by turning to useState’s pal, the 

 hook. Without going into very much detail, 

useEffect allows you to perform side-effects

 so that you can accomplish the same types of things that you can with a 

the more useful lifecycle methods that are specifically used with class components

 in order to emulate the behavior of a class component’s setState callback or the 

 hook accepts an array of dependencies as the last argument, and when React sees that a value in that array has changed it will rerun the corresponding 

. This means you can put a state value in this array to ensure that code within the 

 hook runs once that state is updated. For instance, in this example when the 

 state changes to either true or back to false then the 

 hook will run along with the appropriate conditional code within:

The last thing I wanted to mention about 

, and React hooks in general, is that you should only call hooks from the “top-level” of your React functions, which means that you shouldn’t use hooks inside of loops, conditionals (if/else, etc.) or nested functions, and you also shouldn’t call hooks from regular JavaScript functions, but rather only from React functional components or custom React hook functions (see 

That’s it for this post, but I hope to see you back soon for the next post where I’ll be focusing more on some of the patterns you can use when setting state across different shapes of data.

Working with State in Class Components vs. Functional Components

Triangles and circles in a firewood stack

States of React State (Part 1)

In my previous blog post I gave an introduction to Git’s Working Directory, Index and HEAD mechanisms and discussed some of the different ways you can interact with them to track, stage, commit and inspect files in a project. In this post I’m going to continue discussing how you can interact with these mechanisms, but in the context of actions that can untrack, unstage, and undo changes to files.

In the prior post I briefly discussed how the 

 command can allow you and the HEAD mechanism to travel around your project and inspect whole branches and individual commits, but checking out can also be used to undo changes to specific files:

Checkout the <filename> in the state it was in the last commit and permanently undo any changes that have been made to the <filename> since the last commit.

* The two hyphens in between checkout and the <filename> are used to indicate that the name represented by <filename> is an actual file as opposed to a branch or an available command option that can be used with `git checkout`. If <filename> doesn’t match a branch name, or match an available option, or match a filename that starts with a hyphen, then you can omit the hyphens.

Checkout <filename> in the state it was in <n> commits prior.

* If you perform this action and then stage and commit the file it will permanently undo any changes you made to <filename> after the corresponding commit you checked out.

This behaves the same as the command above but uses the <commit> instead of the HEAD to target and checkout <filename> in the state it was in at <commit>.

 to start tracking a file but you later decide that you don’t need that file then you can use the 

 command to remove the file from the Index or from both the Index and the Working Directory. 

, and while this can be a helpful way to remember what 

 does, it’s not always accurate. In fact, when you run 

 under the hood to stage the removed file from the Index so that it won’t be included in your next commit.

Permanently remove an unmodified file from the Git repository and delete it from your computer.

* By “unmodified” I mean a file that has previously been tracked and committed but hasn’t been changed since the last commit or since being added to the Index. To remove “modified” files see examples below that use the `--force` option.

Permanently remove a modified file your repository and delete it from your computer.

* As a safety precaution Git ordinarily doesn’t allow you to remove a modified file (a file that has been tracked and committed but has unsaved changes) but the `--force` option is what allows you to override this.

Unstage an unmodified file from the Index and stop tracking that file but keep the file in the Working Directory as an untracked file.

* `--cached` is what allows you to keep a file in the Working Directory after you remove it from the Index and stop tracking it.

Same as above but target a folder that contains sub-directories and files.

* This one is particularly helpful if you ever forgot to add your `node_modules` folder to your `.gitignore` file. For example, if you forget and accidentally push your `node_modules` to your remote repository you can add `node_modules` to your `.gitignore` file, run `git rm -r --cached node_modules` and then after you commit and push, `node_modules` will be removed from your remote repo and Git will no longer track it.

Unstage a modified file from the Index, stop tracking that file but keep any file modifications and keep the file in the Working Directory as an untracked file.

If you’ve introduced a new file to your project but haven’t started tracking it yet and you decide that you’ll no longer need it, you can use the 

 command to remove it from the Working Directory:

Remove the untracked <filename> from the Working Tree and permanently delete it from your computer.

Same as above but it operates on all untracked files in the current directory.

* If you want to first check to see what file would be removed you can use `git clean -n` (`-n` is a shortcut for `--dry-run`)

Same as the commands above but the addition of the `-d` option will also recursively remove all untracked sub-directories and/or any untracked files within those directories.

* Similar to the command above, you can use `git clean -nd` to see which files and sub-directories would be removed. If a sub-directory you attempt to clean has both tracked and untracked files then only the untracked files will be removed and the sub-directory will be kept in place.

One of the more flexible and multi-functional commands in Git is the 

 command. Depending on the options that you use with 

 it will operate differently in regard to how it affects the Working Directory, Index, and HEAD mechanisms, but at it’s most basic level 

 will reset/move the HEAD to the specified target state (by “specified target state” I’m referring to a commit or file). This is similar to what 

 does except reset typically also moves the associated branch reference, which prevents the HEAD from being “detached” like it is if you use 

 is a potentially dangerous command that can delete your commit history so you should not reset code that has been pushed to a shared repository because other contributers may already have added work on top of any commits that are being undone and it can be difficult to fix these complications. It’s also important to note that if you reset back to a commit that happened multiple commits ago you will lose all commits that occurred after the target commit (there is a way to recover deleted commits by using the 

 command but you can only recover them for a limited time because Git will regularly and permanently delete commits that have been orphaned and are no longer tied to active branches of development).

Unstage all modified files from the Index and move them back into the Working Directory with the modifications intact and move the HEAD and branch to the prior commit. The Index now matches the state of the prior commit.

* For all reset commands where you don’t specify a specific commit, Git will assume you want to target the HEAD, which is typically going to be the most recent commit.

Unstage a specific file from the Index with the modifications intact. This is basically the opposite of using `git add` to stage a file to the Index.

Move the HEAD and branch to the specified commit but leave the Index and Working Directory intact.

* Similar to the `git commit --amend` command, this will allow you to edit and add changes to a commit, but instead of only working on the most recent commit it will allow you first undo any commits that come after the target commit.

Move the Index, Working Directory, HEAD and branch to the prior commit. This will delete any modifications you’ve made to tracked files since the last commit (any untracked files will still exist).

Same as above but this will also delete any commits you made after the target commit.

 commands in that they all allow you to undo something, but the way revert goes about it is less destructive, and unlike 

, which can perform different actions on individual files as well as commits, revert only works on commits. 

 is less destructive because instead of deleting a commit or deleting uncommitted changes it will preserve the history that contains the changes you want to undo and then it will make a new commit with those changes undone. Because of its non-destructive nature you should use 

 when undoing any changes that have been pushed to a shared repository. Note that in order to perform a revert you must not have any modified files.

Create a new commit with the changes introduced by <commit> undone but keep <commit> and any commits that occurred after it in the history.

* Git will automatically initialize a new commit but by default it will enter VIM to allow you to enter a custom message. If you don’t care about customizing the message you can add the `--no-edit` option. Also, if you don’t want Git to automatically initialize a commit you can add the `-n` option (shorctut for` --no-commit`) and Git will apply the necessary changes from the reverted commit but will just add them to the Working Directory and Index so you can include additional updates in the next commit.

Same as above but target the <n>th most recent commit (e.g. git revert HEAD~2 will target the 3rd most recent commit).

The last command I want to discuss here is 

, which I also discussed in the prior article but I wanted to also discuss it here since it’s technically a destructive command that allows you to rewrite history and edit the most recent commit. Similarly to how you shouldn’t use the 

 command on commits that have been pushed to a shared repository, you also generally shouldn’t use  

 on shared work because the intial commit will be deleted before it adds the amended commit. If you've pushed an amended commit to a personal repo that nobody else has added work to, then after you make the amended commit you can run 

 to force git to disregard the original remote commit. Otherwise, you'll need to first run 

 to get your local repo back in sync with the remote repo before you can push the amended commit.

Edit the commit message for the prior commit. Also, if you’ve staged any new changes before running the `amend` command then those changes will also be included in the amended commit.

git commit --amend -m “<your revised commit message>”

Interacting With Git’s Working Directory, Index and HEAD Mechanisms to Undo 

The Three Trees of Git (Part 2)

When you first start using Git it's pretty easy to build up the habit of using commands like 

 to track and save updates to our projects, but at the same time it's very easy to gloss over the mechanisms that Git uses to execute these commands, and to conflate the different options that modify how these and other common commands work. Without gaining a better understanding of how Git is going about it’s business it becomes difficult to build confidence and take advantage of all of the more advanced and nitty-gritty things that you can do to mangage your Git-tracked projects (and boy howdy is there a lot you can do!). 

The main mechanisms that form the foundation of managing Git version control are the Working Directory (aka Working Tree, Worktree), the Index (aka Staging Area, Staging Index, Directory Cache, Cache) and the HEAD (aka Commit Tree). These mechanisms, which can also be thought of as collections of project files and the state of those files, are often referred to as “The Three Trees” of Git. In this article I’ll be giving brief overviews of these mechanisms and discussing the difference between some of the more frequently used commands that you can use to track, add, commit and inspect your project files.

Even very inexperienced users of Git will probably be familiar with the word “commit” since its the mechanism used to save snapshots of a project at different points along the project’s evolution. But the other two trees, while important, are easier to overlook since they’re just intermediary steps that you take along the path to making the commits that ultimately represent the different states of our projects that we end up showing to the world. The first of these mechanisms that you typically interact with, whether you know it or not, is the Working Directory, which represents the current state of your project that you’re working on and all of the files that the project is comprised of (i.e. in Git parlance, the files you have “

” in your code editor). The files in the Working Directory can be further broken down into additional states referred to as either “untracked” or “tracked”. Tracked files can in turn be further broken down into either “modified” or “unmodified” states. If you initialize Git for a project that already contains some files, or add new files to a project that has already been Git-initialized, those files are considered untracked, which means that Git is sort of aware of their existence but it’s not currently keeping track of updates that you make to these files. In order to take the first step in properly managing a project with Git you must tell Git which files to keep track of, which you can do with the 

 command (an exception to this is if you clone an existing Git project then all of the files from the cloned repository are automatically going to start being tracked for you)

Interacting With Git’s Working Directory, Index and HEAD Mechanisms to Track, Stage, Commit and Inspect Files

Filter by Tags:

Posts:

States of React State (Part 2)

States of React State (Part 1)

The Three Trees of Git (Part 2)

The Three Trees of Git (Part 1)

The Elegance of the Modulo Operator

Learn Enough Styled Components to be Dangerously Fabulous