
```bash
git pull origin main --rebase
``` 
One of my favourite git commands. It retrieves the latest changes from a remote repository and rebases them onto your local branch. 

This helps to avoid creating unnecessary merge commits and ensures a cleaner and more linear commit history. It's particularly useful in team projects where multiple developers are making changes to the same codebase simultaneously, as it helps to avoid merge conflicts and maintain a consistent codebase. While there may be situations where using git merge is more appropriate, `git pull origin main --rebase` is a valuable tool for advanced users who want to manage changes in their codebase more efficiently.


Using --rebase


## Pretty Log:
My fist alias is the "pretty" alias. This alias provides a visual representation of your Git commit history, making it easier to understand and navigate. The command for the "pretty" alias is:

```bash
pretty = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit
```
When you run git pretty, you will see a graph of your commit history, with each commit represented by a colored node. The color coding makes it easy to identify the branch that a commit belongs to, as well as the author of the commit.

## Conflicts:
Another useful alias is "conflicts". This alias shows you a list of files that have conflicts in a merge or rebase operation. The command for the "conflicts" alias is:

```bash
conflicts = diff --name-only --diff-filter=U --relative
```
Running git conflicts will show you a list of files that have conflicts, making it easier to resolve the conflicts and complete your merge or rebase.

---

### Further Reading
1. [What did I work on yesterday?](/blog/what-did-i-work-on-yesterday)
2. [Faster git workflow with aliases](https://medium.com/swlh/faster-git-workflow-with-git-aliases-93d2400e9c28)

Git Helpers


## Introduction
Code review is an essential part of the development process, as it helps to ensure that code is of high quality and adheres to coding standards. However, it's important to remember that code review is also a conversation, and as such, it's important to follow some basic etiquette to ensure that the conversation is productive and respectful. Here are some tips for good code review etiquette:

## Be respectful and constructive
Code review can be a sensitive process, as it involves criticism of someone's work. It's important to remember to be respectful and constructive in your feedback. Avoid personal attacks and focus on the code itself. Offer suggestions for improvement rather than just pointing out problems.

## Be specific and clear
When providing feedback, be specific and clear about what you're suggesting. Avoid vague comments like "this could be better" or "not sure about this." Instead, provide specific examples and explanations for your suggestions. This will help the author understand your perspective and make it easier for them to make changes.

## Focus on the code, not the person
Code review is about the code, not the person who wrote it. Avoid making personal comments or attributing problems to the author's ability or skill level. Keep the focus on the code and how it can be improved.

## Keep an open mind
Code review is a two-way conversation, and it's important to keep an open mind. Be willing to consider the perspectives of others and be open to the possibility that your own suggestions may not be the best solution.

## Be timely
Code review can be a time-sensitive process, especially in fast-paced development environments. Be sure to review code in a timely manner and provide feedback promptly so that the development process can move forward efficiently.

## Follow the style guide
Most projects have a style guide that outlines conventions for things like naming conventions, indentation, and commenting. It's important to follow the style guide when reviewing code to ensure that the code is consistent and easy to read.

## Avoid nitpicking
While it's important to pay attention to details, it's also important to keep the big picture in mind. Avoid nitpicking minor issues that don't significantly impact the functionality or readability of the code.

## Don't let code review drag on
While it's important to be thorough in code review, it's also important to keep things moving. If you have extensive feedback or suggestions, consider breaking them up into smaller chunks or discussing them in person to avoid dragging out the code review process.

## Thank the author
Finally, be sure to thank the author for their work and effort. Code review can be a challenging process, and a little appreciation can go a long way.

---

_By following these tips for good code review etiquette, you can ensure that the code review process is productive, respectful, and ultimately results in better code._

Good Code Review Etiquette


## Prerequisites
- A Next.js blog. If you don't have one, you can follow the [official Next.js tutorial](https://nextjs.org/learn/basics/create-nextjs-app) to create one.
- Node.js and npm installed on your machine.

## Step 1: Install the feed package
In your Next.js project, run the following command to install the feed package:

```bash
npm install feed
```

This will add the feed package as a dependency to your project.

## Step 2: Create a function to generate the RSS feed
Next, create a file called rss.js in the root of your project and add the following code:

```javascript
const { Feed } = require('feed');

const createRSSFeed = (posts) => {
  const feed = new Feed({
    title: 'My Next.js Blog',
    description: 'A blog powered by Next.js',
    id: 'https://my-nextjs-blog.com',
    link: 'https://my-nextjs-blog.com/rss.xml',
    language: 'en',
    image: 'https://my-nextjs-blog.com/static/logo.png',
    favicon: 'https://my-nextjs-blog.com/static/favicon.ico',
    copyright: 'All rights reserved 2020, John Doe',
    updated: new Date(),
    author: {
      name: 'John Doe',
      email: 'john@doe.com',
      link: 'https://my-nextjs-blog.com/about',
    },
  });

  posts.forEach((post) => {
    feed.addItem({
      title: post.title,
      id: `https://my-nextjs-blog.com/posts/${post.slug}`,
      link: `https://my-nextjs-blog.com/posts/${post.slug}`,
      description: post.description,
      content: post.content,
      author: [
        {
          name: 'John Doe',
          email: 'john@doe.com',
          link: 'https://my-nextjs-blog.com/about',
        },
      ],
      date: new Date(post.date),
    });
  });

  return feed.rss2();
};

module.exports = createRSSFeed;
```

This function takes an array of post objects as an argument and returns an RSS feed as a string. The Feed constructor from the feed package is used to create a new feed object, and the addItem method is used to add posts to the feed. The `rss2` method is used to convert the feed to an RSS 2.0 format.

## Step 3: Create a route for the RSS feed
In your Next.js project, create a pages directory if it doesn't exist already, and add a file called `rss.js` inside it with the following code:

```javascript
import { getPosts } from '../lib/posts';
import createRSSFeed from '../rss';

const RSS = (props) => {
  const rss = createRSSFeed(props.posts);
  return {
    headers: {
      'Content-Type': 'application/rss+xml; charset=utf-8',
    },
    body: rss,
  };
};

RSS.getInitialProps = async () => {
  const posts = await getPosts();
  return { posts };
};

export default RSS;
```

This creates a Next.js page that returns the RSS feed as the response body when the `/rss.xml` route is accessed. The `getInitialProps` function is an async function that is called by Next.js to retrieve the initial data for the page. In this case, it fetches the posts from the getPosts function and passes them as props to the page component.

## Step 4: Test the RSS feed
To test the RSS feed, start the Next.js development server by running the following command in your terminal:

```bash
npm run dev
```

Then, visit [http://localhost:3000/rss.xml](http://localhost:3000/rss.xml) in your browser. You should see the RSS feed displayed in the browser. If you see any errors, make sure to debug and fix them before proceeding to the next step.

## Step 5: Deploy the RSS feed
Finally, when you are ready to deploy your Next.js blog, make sure to include the rss.js file in the pages directory in your build. This will ensure that the RSS feed is available on your live blog at the `/rss.xml` route.

That's it! You have successfully added an RSS feed to your Next.js blog using the feed npm package. You can now share the RSS feed with your readers so that they can subscribe to your blog and stay updated with your latest posts.

I hope this tutorial was helpful. Let me know if you have any questions or need further assistance.

Add RSS to your Next.js blog


## Introduction

This post is a run through of how you can work on a frontend project with Git and how you can safely store your code and collaborate with your team. This post uses git as the version control, and GitHub as our repository host — you should be familiar with both.

## Branches

| Branch | Purpose | Stability |
| --- | --- | --- |
| main | Holding branch before deployment  | Stable |
| feature-branch | This branch is being actively worked on and tested | Unstable |
| staging | “Production” environment which can be accessed by the internal team | Stable-ish |
| production | Production environment which can be fully accessed by external customers | Stable |

## How we work

Utilising various tools like PR deployments and CI we can avoid having multiple branches for multiple environments. Our way allows us to streamline our development and collaboration. Below is a diagram of a basic workflow when you come to build out a feature.

![Git Flow](../images/posts/flow.png)

## Dos

1. For your feature branch, every day (or so), you should be running `git pull --rebase main` to ensure you have the latest changes on your feature branch
2. Every new feature you work on, you should create a new branch which should be the ticket name from Linear
3. Commit messages should follow [this](https://www.conventionalcommits.org/en/v1.0.0-beta.2) convention
4. You should follow fill out the PR template with every PR that you open

## Don’ts

1. Don’t hold up work by not committing a local branch to a remote branch
2. Don’t push work directly to `main`
3. Don’t commit application secrets or passwords
4. Don’t commit large media files (compress and resize where possible)
5. Don’t work on multiple features on one branch
6. Don’t open multiple pull requests for one feature

## Helpers

1. [Git Pretty](https://dev.to/tuanluong19/pretty-git-log-2fm7) — For a better visualisation of logging commits
2. [What did I work on yesterday?](https://lifesgood.is/blog/what-did-i-work-on-yesterday) — An alias to quickly show what you worked on the day before
3. [Github Desktop](https://desktop.github.com/) — It is not a must you have to work on the terminal

Simple Git Flow

So for the last few months I’ve been having a problem with not remembering what I’ve worked on the day before. I’m putting it down to bad memory however when attending my daily stand up meetings this is becoming a problem.

### I tried a few things to jog my memory

1. At the end of the day note down what I’ve been working on.
2. Use git to look through git log and pick out my commits that I’ve pushed to the branch.

The first option was useful until I started forgetting to note stuff down, so of course this meant I was back to square one. However the second option worked really well but only if you committed useful messages like “Implemented navigation bar” and not “Fixed stuff” but lucky for me I’m pretty descriptive (🤔)… however so is everybody else on my team, so it meant slowly looking through commits and working out if they’re mine or not, which led me to a very simple idea.

A git alias that only shows commits with a specific author and since the day before:


```bash
scrum = log --since='1 day ago' --author='Joe Richardson' --oneline
```