<!-- _Almost the same as #7231:25fdbf2a0:newbs_git_best_practices.md L5_ -->
<!-- This document aims to instruct novices in the best ways to have a smooth experience in contributing to QMK. We will walk through the process of contributing to QMK, detailing some ways to make this task easier, and then later we'll break some things in order to teach you how to fix them. -->
<!-- _Same as #7231:25fdbf2a0:newbs_git_best_practices.md L9_ -->
<!-- 1. You have a GitHub account, and have [forked the qmk_firmware repository](getting_started_github.md) to your account. -->
<!-- 2. You've [set up your build environment](newbs_getting_started.md?id=environment-setup). -->
<!-- #7231:da7d49246: 2. You've set up both [your build environment](newbs_getting_started.md?id=set-up-your-environment) and [QMK](newbs_getting_started.md?id=set-up-qmk). -->
<!-- _Same as #7231:25fdbf2a0:newbs_git_using_your_master_branch.md L3_ -->
<!-- It is highly recommended for QMK development, regardless of what is being done or where, to keep your `master` branch updated, but***never*** commit to it. Instead, do all your changes in a development branch and issue pull requests from your branches when you're developing. -->
<!-- _Same as #7231:25fdbf2a0:newbs_git_using_your_master_branch.md L5_ -->
<!-- To reduce the chances of merge conflicts — instances where two or more users have edited the same part of a file concurrently — keep your `master` branch relatively up-to-date, and start any new developments by creating a new branch. -->
<!-- _Same as #7231:25fdbf2a0:newbs_git_using_your_master_branch.md L9_ -->
<!-- To keep your `master` branch updated, it is recommended to add the QMK Firmware repository ("repo") as a remote repository in git. To do this, open your Git command line interface and enter: -->
<!-- _Same as #7231:25fdbf2a0:newbs_git_using_your_master_branch.md L25_ -->
<!-- Now that this is done, you can check for updates to the repo by running `git fetch upstream`. This retrieves the branches and tags — collectively referred to as "refs" — from the QMK repo, which now has the nickname `upstream`. We can now compare the data on our fork `origin` to that held by QMK. -->
<!-- _Same as #7231:25fdbf2a0:newbs_git_using_your_master_branch.md L36_ -->
<!-- This switches you to your `master` branch, retrieves the refs from the QMK repo, downloads the current QMK `master` branch to your computer, and then uploads it to your fork. -->
<!-- _Same as #7231:25fdbf2a0:newbs_git_using_your_master_branch.md L47_ -->
<!-- This creates a new branch named `dev_branch`, checks it out, and then saves the new branch to your fork. The `--set-upstream` argument tells git to use your fork and the `dev_branch` branch every time you use `git push` or `git pull` from this branch. It only needs to be used on the first push; after that, you can safely use `git push` or `git pull`, without the rest of the arguments. -->
<!-- _Same as #7231:25fdbf2a0:newbs_git_using_your_master_branch.md L51_ -->
<!-- You can name your branch nearly anything you want, though it is recommended to name it something related to the changes you are going to make. -->
<!-- _Same as #7231:25fdbf2a0:newbs_git_using_your_master_branch.md L53_ -->
<!-- By default `git checkout -b` will base your new branch on the branch that is checked out. You can base your new branch on an existing branch that is not checked out by adding the name of the existing branch to the command: -->
<!-- _Same as #7231:25fdbf2a0:newbs_git_using_your_master_branch.md L59_ -->
<!-- Now that you have a development branch, open your text editor and make whatever changes you need to make. It is recommended to make many small commits to your branch; that way, any change that causes issues can be more easily traced and undone if needed. To make your changes, edit and save any files that need to be updated, add them to Git's*staging area*, and then commit them to your branch: -->
<!-- _Same as #7231:25fdbf2a0:newbs_git_using_your_master_branch.md L66_ -->
<!-- `git add` adds files that have been changed to Git's*staging area*, which is Git's "loading zone." This contains the changes that are going to be*committed* by `git commit`, which saves the changes to the repo. Use descriptive commit messages so you can know what was changed at a glance. -->
<!-- _Same as #7231:25fdbf2a0:newbs_git_using_your_master_branch.md L68_ -->
<!-- !> If you've changed a lot of files, but all the files are part of the same change, you can use `git add .` to add all the changed files that are in your current directory, rather than having to add each file individually. -->
<!-- _Same as #7231:25fdbf2a0:newbs_git_using_your_master_branch.md L72_ -->
<!-- The last step is to push your changes to your fork. To do this, enter `git push`. Git now publishes the current state of `dev_branch` to your fork. -->
<!-- _Same as #7231:25fdbf2a0:newbs_git_resolving_merge_conflicts.md L3_ -->
<!-- Sometimes when your work in a branch takes a long time to complete, changes that have been made by others conflict with changes you have made to your branch when you open a pull request. This is called a*merge conflict*, and is what happens when multiple people edit the same parts of the same files. -->
<!-- _Same as #7231:25fdbf2a0:newbs_git_resolving_merge_conflicts.md L9_ -->
<!-- A*rebase* is Git's way of taking changes that were applied at one point, reversing them, and then applying the same changes to another point. In the case of a merge conflict, you can rebase your branch to grab the changes that were made between when you created your branch and the present time. -->
<!-- _Same as #7231:25fdbf2a0:newbs_git_resolving_merge_conflicts.md L18_ -->
<!-- The `git rev-list` command entered here returns the number of commits that differ between the current branch and QMK's master branch. We run `git fetch` first to make sure we have the refs that represent the current state of the upstream repo. The output of the `git rev-list` command entered returns two numbers: -->
<!-- _Same as #7231:25fdbf2a0:newbs_git_resolving_merge_conflicts.md L25_ -->
<!-- The first number represents the number of commits on the current branch since it was created, and the second number is the number of commits made to `upstream/master` since the current branch was created, and thus, the changes that are not recorded in the current branch. -->
<!-- _Same as #7231:25fdbf2a0:newbs_git_resolving_merge_conflicts.md L54_ -->
<!-- This tells us that we have a merge conflict, and gives the name of the file with the conflict. Open the conflicting file in your text editor, and somewhere in the file, you'll find something like this: -->
<!-- _Same as #7231:25fdbf2a0:newbs_git_resolving_merge_conflicts.md L64_ -->
<!-- The line `<<<<<<< HEAD` marks the beginning of a merge conflict, and the `>>>>>>> Commit #1` line marks the end, with the conflicting sections separated by `=======`. The part on the `HEAD` side is from the QMK master version of the file, and the part marked with the commit message is from the current branch and commit. -->
<!-- _Same as #7231:25fdbf2a0:newbs_git_resolving_merge_conflicts.md L66_ -->
<!-- Because Git tracks*changes to files* rather than the contents of the files directly, if Git can't find the text that was in the file previous to the commit that was made, it won't know how to edit the file. Re-editing the file will solve the conflict. Make your changes, and then save the file. -->
