| Oct | NOV | Dec |
| 21 | ||
| 2019 | 2020 | 2021 |
COLLECTED BY
Collection: Save Page Now
master. We want to work on another branch, so we can make a pull request and make changes safely. To get started, create a branch off of master. Name it however you'd like - but we recommend naming branches based on the function or feature that will be the focus of this branch. One person may have several branches, and one branch may have several people collaborate on it - branches are for a purpose, not a person. Wherever you currently "are" (wherever HEAD is pointing, or whatever branch you're currently "checked out" to) will be the parent of the branch you create. That means you can create branches from other branches, tags, or any commit! But, the most typical workflow is to create a branch from master - which represents the most current production code.
git add [file].
Once you've saved and staged the changes, you're ready to make the commit with git commit -m "descriptive commit message".
git push. If you're pushing from a branch for the first time that you've created locally, you may need to give Git some more information. git push -u origin [branch-name] tells Git to push the current branch, and create a branch on the remote that matches it with the same name - and also, create a relationship with that branch, so that git push will be enough information in the future.
By default, git push only pushes the branch that you're currently checked out to.
Sometimes, if there has been a new commit on the branch on the remote, you may be blocked from pushing. Don't worry! Start with a simple git pull to incorporate the changes on the remote into your own local branch, resolve any conflicts or finish the merge from the remote into the local branch, and then try the push again.
master, or the branch that the feature branch was created from, and the feature branch. This way, like branches, pull requests are scoped around a specific function or addition of work, rather than the person making the changes or amount of time the changes will take.
Pull requests are the powerhouse of GitHub. Integrated tests can automatically run on pull requests, giving you immediate feedback on your code. Peers can give detailed code reviews, letting you know if there are changes to make, or if it's ready to go.
Make sure you start your pull requests off with the right information. Put yourself in the shoes of your teammates, or even of your future self. Include information about what this change relates to, what prompted it, what is already done, what is left to do, and any specific asks for help or reviews. Include links to relevant work or conversations. Pull request templates can help make this process easy by automating the starting content of the body of pull requests.
master branch). Then, master will be updated with your changes, and your pull request will be closed. Don't forget to delete your branch! You won't need it anymore. Remember, branches are lightweight and cheap, and you should create a new one when you need it based on the most recent commit on the master branch.
If you choose not to merge the pull request, you can also close pull requests with unmerged changes.
github/training-kit repository, and a great starting place for the fundamentals on the command line.
Some of the most important and most used commands that you'll find there are:
●git clone [url]: Clone (download) a repository that already exists on GitHub, including all of the files, branches, and commits.
●git status: Always a good idea, this command shows you what branch you're on, what files are in the working or staging directory, and any other important information.
●git branch: This shows the existing branches in your local repository. You can also use git branch [banch-name] to create a branch from your current location, or git branch --all to see all branches, both the local ones on your machine, and the remote tracking branches stored from the last git pullorgit fetch from the remote.
●git checkout [branch-name]: Switches to the specified branch and updates the working directory.
●git add [file]: Snapshots the file in preparation for versioning, adding it to the staging area.
●git commit -m "descriptive message": Records file snapshots permanently in version history.
●git pull: Updates your current local working branch with all new commits from the corresponding remote branch on GitHub. git pull is a combination of git fetch and git merge.
●git push: Uploads all local branch commits to the remote.
●git log: Browse and inspect the evolution of project files.
●git remote -v: Show the associated remote repositories and their stored name, like origin.