mirror of
https://github.com/LucasVbr/first-contributions.git
synced 2026-05-14 01:31:50 +00:00
reset repo
This commit is contained in:
Roshanjossey
@@ -0,0 +1,46 @@
|
||||
# Useful Links
|
||||
|
||||
This document is dedicated to all the tips and tricks websites, blog posts, and helpful sites that make our lives easier. They are a great reference to serve all of our needs, be it a beginner or an expert. This page should act as an index of all those useful links that would help everybody who is new in the open-source domain or someone who wants to learn more.
|
||||
|
||||
## The List
|
||||
1. [Interactive tutorial to git](https://try.github.io)
|
||||
2. [Youtube: Git and GitHub for Beginners by freecodecamp](https://www.youtube.com/watch?v=RGOj5yH7evk)
|
||||
3. [git - the simple guide](http://rogerdudler.github.io/git-guide/)
|
||||
4. [On undoing, fixing, or removing commits in git](http://sethrobertson.github.io/GitFixUm/fixup.html)
|
||||
5. [Git and GitHub tutorial translated to many languages](https://github.com/Roshanjossey/first-contributions)
|
||||
6. [Merge Conflicts](https://www.git-tower.com/learn/git/ebook/en/command-line/advanced-topics/merge-conflicts)
|
||||
7. [Resolving Merge Conflicts](https://githowto.com/resolving_conflicts)
|
||||
8. [Basics of Git - The Simple Quick Start Guide](https://blog.praveen.science/basics-of-git-the-quick-start-guide/)
|
||||
9. [Git Standards followed in our way of Spotify Agile Methodology](https://blog.praveen.science/git-standards-followed-in-our-way-of-spotify-agile-methodolgy/)
|
||||
10. [Git Shortcuts](https://blog.praveen.science/git-shortcuts/)
|
||||
11. [Official Git cheat sheet in many languages](https://services.github.com/on-demand/resources/cheatsheets)
|
||||
12. [Git cheat sheet from Tower](https://www.git-tower.com/learn/cheat-sheets/git)
|
||||
13. [Common Git Problems](https://www.codementor.io/citizen428/git-tutorial-10-common-git-problems-and-how-to-fix-them-aajv0katd)
|
||||
14. [Git Rebase](https://blog.gitprime.com/git-rebase-an-illustrated-guide/)
|
||||
15. [Beginner's Guide to Rebasing and Squashing](https://github.com/servo/servo/wiki/Beginner%27s-guide-to-rebasing-and-squashing)
|
||||
16. [Git Cheatsheet that shows correlations between commands and files](http://ndpsoftware.com/git-cheatsheet.html)
|
||||
17. [How to contribute](https://opensource.guide/how-to-contribute/)
|
||||
18. [Getting started with Open Source](https://github.com/OpenSourceHelpCommunity/Getting-Started-With-Contributing-to-Open-Sources)
|
||||
19. [How to contribute](https://github.com/freeCodeCamp/how-to-contribute-to-open-source)
|
||||
20. [Atlassians Git Tutorials](https://www.atlassian.com/git)
|
||||
21. [Pull request reviews](https://help.github.com/articles/about-pull-request-reviews/)
|
||||
22. [Another Interactive tutorial for git](https://learngitbranching.js.org/)
|
||||
23. [Git commandline cheat-sheet](https://gist.github.com/davfre/8313299)
|
||||
24. [Programming Books](https://github.com/EbookFoundation/free-programming-books)
|
||||
25. [E-Book of professional tip and secrets](https://goalkicker.com/GitBook/GitProfessionalTipsSecrets.pdf)
|
||||
26. [tutorial about simple rules of become git professional](https://medium.freecodecamp.org/follow-these-simple-rules-and-youll-become-a-git-and-github-master-e1045057468f)
|
||||
27. [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
|
||||
28. [5 Useful Tips For A Better Commit Message](https://thoughtbot.com/blog/5-useful-tips-for-a-better-commit-message)
|
||||
29. [Version Control using Git](https://ourcodingclub.github.io/2017/02/27/git.html)
|
||||
30. [Version Control with Git](https://www.udacity.com/course/version-control-with-git--ud123)
|
||||
31. [Audit the Coursera course from Google](https://www.coursera.org/learn/introduction-git-github)
|
||||
32. [Using Version Control in VS Code](https://code.visualstudio.com/docs/editor/versioncontrol)
|
||||
33. [Git vs Github: What's the Difference and How to Get Started with Both](https://kinsta.com/knowledgebase/git-vs-github/)
|
||||
34. [Hello World Github guides](https://guides.github.com/activities/hello-world/)
|
||||
35. [How To Use GitHub](https://www.edureka.co/blog/how-to-use-github/)
|
||||
36. [10 Days of Git and Github](https://github.com/Asabeneh/10-days-of-git-and-github)
|
||||
37. [Keyboard shortcuts for Github](https://docs.github.com/en/get-started/using-github/keyboard-shortcuts)
|
||||
38. [Complete Git and GitHub Tutorial by Kunal Kushwaha](https://www.youtube.com/watch?v=apGV9Kg7ics&ab_channel=KunalKushwaha)
|
||||
39. [Git workflow Cheat Sheet](https://drive.google.com/uc?export=download&id=1QPRh5YmqQm4DFfitelPYlBTWC2I6tTTM)
|
||||
40. [Beginers Guide To Proper Git Workflow](https://medium.com/@anjulapaulus_84798/beginners-guide-to-proper-git-workflow-35a2d967734e)
|
||||
Keep adding more links, that you find helpful.
|
||||
@@ -0,0 +1,52 @@
|
||||
# Additional information
|
||||
|
||||
We assume that you have already finished with the basic tutorial before coming here. This document will give you some additional information about advanced Git techniques.
|
||||
|
||||
### [Amending a commit](amending-a-commit.md)
|
||||
This document provides information about how to amend a commit on the remote repository. Amending a commit is a way to modify the most recent commit you have made in your current branch. This can be helpful if you need to edit the commit message or if you forgot to include changes in the commit. You can continue to amend a commit until you push it to the remote repository.
|
||||
> Use this when you need to adjust a commit you made.
|
||||
|
||||
### [Configuring git](configuring-git.md)
|
||||
This document provides information about how to configure user details and other options in git.
|
||||
> Use this to better control your git configurations.
|
||||
|
||||
### [Keeping your fork synced with the repository](keeping-your-fork-synced-with-this-repository.md)
|
||||
This document provides information about how to keep your forked repository up-to-date with the base repository. This is important, as hopefully you and many others will contribute to the project.
|
||||
> Follow these steps if your fork doesn't have any changes in parent repository.
|
||||
|
||||
### [Moving a Commit to a different Branch](moving-a-commit-to-a-different-branch.md)
|
||||
This document provides information about how to move a Commit to another Branch.
|
||||
> Take these steps to move a commit to another branch.
|
||||
|
||||
### [Removing a File](removing-a-file.md)
|
||||
This document provides information about how to remove a file from your local repository.
|
||||
> Follow these steps to learn how to remove a file prior to a commit
|
||||
|
||||
### [Removing a branch from your repository](removing-branch-from-your-repository.md)
|
||||
This document provides information about how to delete a branch from your repository.
|
||||
> Only after your pull request gets merged, follow to next steps
|
||||
|
||||
### [Resolving Merge Conflicts](resolving-merge-conflicts.md)
|
||||
This document provides information about how to resolve merge conflicts.
|
||||
> Take these steps to resolve the annoying merge conflicts.
|
||||
|
||||
### [Reverting a commit](reverting-a-commit.md)
|
||||
This document provides information about how to revert a commit on the remote repository. It will come in handy in case you need to undo a commit that has already been pushed to Github.
|
||||
> Take these steps if you want to reverse a commit.
|
||||
|
||||
### [Squashing Commits](squashing-commits.md)
|
||||
This document provides information about how to squash commits with an interactive rebase.
|
||||
> Use this if you want to open a PR in an open source project and the reviewer asks you to squash every commit into one, with an informative commit message.
|
||||
|
||||
### [Undo-ing a local commit](undoing-a-commit.md)
|
||||
This document provides information about how to undo a commit on your local repository. This is what you need to do when you feel you've messed up your local repository and wish to reset the local repository.
|
||||
> Take these steps if you want to undo/reset a local commit.
|
||||
|
||||
### [Useful Links](Useful-links-for-further-learning.md)
|
||||
This document is dedicated to all the tips and tricks websites, blog posts, and helpful sites that make our lives easier. They are a great reference to serve all of our needs, be it a beginner or an expert. This page should act as an index of all those useful links that would help everybody who is new in the open-source domain or someone who wants to learn more.
|
||||
|
||||
### [Creating a .gitignore file](creating-a-gitignore-file.md)
|
||||
This document explains what a .gitignore file does, why to use it and how to create a .gitignore file. This file is used in almost all git projects. It helps commit only necessary files to git.
|
||||
|
||||
### [Storing Credentials](storing-credentials.md)
|
||||
This document explains how to store your credentials for repositories. This can be a security concern, so please follow the security policies of your place of work/study.
|
||||
@@ -0,0 +1,65 @@
|
||||
# Amending a Commit
|
||||
|
||||
What if you commit a change to your remote repository only to realize later that you have a typo in the commit message or you forgot to add a line in your most recent commit.
|
||||
How do you edit that? This is what this tutorial covers.
|
||||
|
||||
## Changing a recent commit message after you have pushed to Github.
|
||||
To do this without opening a file:
|
||||
* Type in the ```git commit --amend -m "followed by your new commit message"```
|
||||
* Run ```git push origin <branch-name>``` to commit the changes to the repository.
|
||||
|
||||
Note: If you type in just ```git commit --amend```, your text editor would open up prompting you to edit the commit message.
|
||||
Adding the ``-m`` flags prevents it.
|
||||
|
||||
## Modifying on a single commit
|
||||
|
||||
So, what if we forgot to make a minor change to a file like changing a single word and we have already pushed the commit to our remote repository?
|
||||
|
||||
To illustrate here is a log of my commits:
|
||||
```
|
||||
g56123f create file bot file
|
||||
a2235d updated contributor.md
|
||||
a5da0d modified bot file
|
||||
```
|
||||
Let's say I forgot to add a single word to the bot file
|
||||
|
||||
There are 2 ways to go about this. The first is to have an entirely new commit that contains the change like so:
|
||||
```
|
||||
g56123f create file botfile
|
||||
a2235d updated contributor.md
|
||||
a5da0d modified botfile
|
||||
b0ca8f added single word to botfile
|
||||
```
|
||||
The second way is to amend the a5da0d commit, add this new word and push it to Github as one commit.
|
||||
The second sounds better since it is just a minor change.
|
||||
|
||||
To achieve this, we would do the following:
|
||||
* Modify the file. In this case, I will modify the botfile to include the word I omitted previously.
|
||||
* Next, add the file to the staging area with ```git add <filename>```
|
||||
|
||||
Usually after adding files to the staging area, the next thing we do is git commit -m "our commit message" right?
|
||||
But since what we want to achieve here is to amend the previous commit, we would instead run:
|
||||
|
||||
* ```git commit --amend```
|
||||
This would then bring up the text editor and prompt you to edit the message. You can decide to leave the message as it was before or change it.
|
||||
* Exit the editor
|
||||
* Push your changes with ```git push origin <branch-name>```
|
||||
|
||||
That way, both changes would be in one single commit.
|
||||
|
||||
## Modifying commits on remote
|
||||
|
||||
If the commit that you like to amend has been already pushed to the remote, amending this commit will lead to your local history being diverged from the remote (since you basically create a new commit and replace the amended one). Since you want to change the commit on the remote, you need to overwrite the remotes history on your branch. To achieve that, follow the same procedure as described above, but use force push when pushing your commit to the remote.
|
||||
|
||||
> **Warning**
|
||||
> Force pushing to the remote will overwrite (and discard) changes on the remote and only keep your pushed commits. Changes on the remote, that other team members did in the meantime, will be overwritten as well.
|
||||
|
||||
This is how you modify the last recent commit on the remote:
|
||||
|
||||
```bash
|
||||
git add <your changed files>
|
||||
git commit --amend -m "followed by your new commit message"
|
||||
git push --force
|
||||
```
|
||||
|
||||
> Using `--force-with-lease` is a safer option instead of `--force` which avoids overwriting other people's changes on the remote branch (if you do not intend to do so).
|
||||
@@ -0,0 +1,37 @@
|
||||
# Check commit log
|
||||
|
||||
In order to check commits log for a branch, or, a file, following command can be used:
|
||||
|
||||
`git log [options] [path]`
|
||||
|
||||
The output of this command is given in reverse chronological order by default.
|
||||
|
||||
## Command output example
|
||||
```
|
||||
$ git log
|
||||
commit e3fabb30ab536bd5876461d8a749301a321e714f (HEAD -> check-commit-log-ko, upstream/main, origin/main, origin/HEAD, main)
|
||||
Author: Dan Yunheum Seol <yunheum.seol@mail.mcgill.ca>
|
||||
Date: Tue Jun 4 01:07:25 2024 -0400
|
||||
|
||||
Add dan-seol to Contributors list (#84962)
|
||||
|
||||
commit 4af4ec8a56e057ce8768af77eda528453974d0bc
|
||||
Author: Edgar Humberto Tijerina Tamez <168693312+EdgarHTT@users.noreply.github.com>
|
||||
Date: Mon Jun 3 23:06:05 2024 -0600
|
||||
|
||||
Add Edgar Tijerina to Contributors list (#84961)
|
||||
```
|
||||
|
||||
|
||||
## Command variations and options
|
||||
- In order to perform the commits reachable from a particular commit ids: <i>(In this case, `foo` and `bar`)</i><br>
|
||||
`git log foo bar `
|
||||
- It is also possible to remove the commits reachable from a given commit id by adding a `^` in front of commit id: <i>(In this case, `baz`)</i><br>
|
||||
`git log foo bar ^baz`
|
||||
- Commit log for a particular file: <br>
|
||||
`git log --all <filename>`
|
||||
- Limit number of commits in log: <i>(In this case, `5`)</i><br>
|
||||
`git log -n 5`
|
||||
|
||||
## Refer
|
||||
- [Official documentation](https://git-scm.com/docs/git-log)
|
||||
@@ -0,0 +1,76 @@
|
||||
# Configuring git
|
||||
|
||||
The first time you tried to commit using git, you might have gotten a prompt like the one below:
|
||||
|
||||
```bash
|
||||
$ git commit
|
||||
*** Please tell me who you are.
|
||||
|
||||
Run
|
||||
|
||||
git config --global user.email "you@example.com"
|
||||
git config --global user.name "Your Name"
|
||||
|
||||
to set your account's default identity.
|
||||
Omit --global to set the identity only in this repository.
|
||||
```
|
||||
|
||||
Git needs to know who you are when you create a commit. When you are working collaboratively, you should be able to see who modified what parts of the project and when, and thus, git has been designed to create commits tied to a name and an email.
|
||||
|
||||
There are multiple ways to provide the `git commit` command with your email and name, and we'll go through some of them below.
|
||||
|
||||
### Global Config
|
||||
|
||||
When you store something in the global config, it is accessible system wide in all the repositories you work on. This is the preferred way and works for most use cases.
|
||||
|
||||
To store something in the global config, you use the `config` command as follows:
|
||||
|
||||
`$ git config --global <variable name> <value>`
|
||||
|
||||
In the case of user details, we run it as follows:
|
||||
|
||||
```
|
||||
$ git config --global user.email "you@example.com"
|
||||
$ git config --global user.name "Your Name"
|
||||
```
|
||||
|
||||
### Repository Config
|
||||
|
||||
As the name says, these configurations are scoped to your current repository. If you want to commit to a particular repository, say, a work related project, with your company's email, then you could use this method.
|
||||
|
||||
To store something in the repository config, you use the `config` command by omitting the `--global` flag as follows:
|
||||
|
||||
`$ git config <variable name> <value>`
|
||||
|
||||
In the case of user details, we run it as follows:
|
||||
|
||||
```
|
||||
$ git config user.email "you@alternate.com"
|
||||
$ git config user.name "Your Name"
|
||||
```
|
||||
|
||||
### Command-line Config
|
||||
|
||||
These type of configurations are scoped to the current command only. All git commands take `-c` arguments before the action verb to set temporary configuration data.
|
||||
|
||||
To store something in the command line config, run your command as follows:
|
||||
|
||||
`$ git -c <variable-1>=<value> -c <variable-2>=<value> <command>`
|
||||
|
||||
In our example, we would run the commit command as follows:
|
||||
|
||||
`git -c user.name='Your Name' -c user.email='you@example.com' commit -m "Your commit message"`
|
||||
|
||||
### Note on Precedence
|
||||
|
||||
Among the three methods described here, the precedence order is `command-line > repository > global`. This means that, if a variable is configured in the command-line as well as globally, the command-line value would be used for the operation.
|
||||
|
||||
## Beyond User Details
|
||||
|
||||
We have dealt with only the user details till now while working with the config. However, there are several other configuration options available. Some of them are:
|
||||
|
||||
1. `core.editor` - to specify the name of the editor used for writing commit messages, etc.
|
||||
2. `commit.template` - to specify a file on the system as the initial commit template.
|
||||
3. `color.ui` - to specify a boolean value for using colors in git's output.
|
||||
|
||||
We have abstracted some details for ease of understanding. For further reading, head over to [git-scm.com](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration).
|
||||
@@ -0,0 +1,73 @@
|
||||
# .gitignore
|
||||
|
||||
The .gitignore file is a text file that tells Git which files or folders to ignore in a project.
|
||||
|
||||
A local .gitignore file is usually placed in the root directory of a project. You can also create a global .gitignore file and any entries in that file will be ignored in all of your Git repositories.
|
||||
|
||||
## Why .gitignore
|
||||
Now you may wonder why would you want git to ignore certain files and folders. Its because you don't want files like build files, cache files, other local configuration files like node modules, compilation files, temporary files IDE's create, etc to be tracked by git. It's usually used to avoid committing transient files from your working directory that aren't useful to other collaborators.
|
||||
|
||||
## Getting started
|
||||
To create a local .gitignore file, create a text file and name it .gitignore (remember to include the . at the beginning). Then edit this file as needed. Each new line should list an additional file or folder that you want Git to ignore.
|
||||
|
||||
The entries in this file can also follow a matching pattern.
|
||||
|
||||
```
|
||||
* is used as a wildcard match
|
||||
/ is used to ignore path names relative to the .gitignore file
|
||||
# is used to add comments to a .gitignore file
|
||||
|
||||
This is an example of what the .gitignore file could look like:
|
||||
|
||||
# Ignore Mac system files
|
||||
.DS_store
|
||||
|
||||
# Ignore node_modules folder
|
||||
node_modules
|
||||
|
||||
# Ignore all text files
|
||||
*.txt
|
||||
|
||||
# Ignore files related to API keys
|
||||
.env
|
||||
|
||||
# Ignore SASS config files
|
||||
.sass-cache
|
||||
|
||||
```
|
||||
To add or change your global .gitignore file, run the following command:
|
||||
|
||||
```
|
||||
git config --global core.excludesfile ~/.gitignore_global
|
||||
|
||||
```
|
||||
This will create the file ~/.gitignore_global. Now you can edit that file the same way as a local .gitignore file. All of your Git repositories will ignore the files and folders listed in the global .gitignore file.
|
||||
|
||||
## How to Untrack Files Previously Committed from New Gitignore
|
||||
|
||||
To untrack a single file, ie stop tracking the file but not delete it from the system use:
|
||||
|
||||
```
|
||||
git rm --cached filename
|
||||
```
|
||||
|
||||
To untrack every file in .gitignore:
|
||||
|
||||
First, commit any outstanding code changes, and then run:
|
||||
|
||||
```
|
||||
git rm -r --cached
|
||||
```
|
||||
|
||||
This removes any changed files from the index(staging area), then run:
|
||||
|
||||
```
|
||||
git add .
|
||||
```
|
||||
Commit it:
|
||||
|
||||
```
|
||||
git commit -m ".gitignore is now working"
|
||||
```
|
||||
|
||||
To undo ```git rm --cached filename```, use ```git add filename```
|
||||
@@ -0,0 +1,19 @@
|
||||
# Deleting a locally created Branch
|
||||
|
||||
This will be handy when you accidentally misspelled a branch name.
|
||||
|
||||
This can be done in *3* ways
|
||||
|
||||
```
|
||||
git branch -D <branch_name>
|
||||
```
|
||||
|
||||
```
|
||||
git branch --delete --force <branch_name> # Same as -D
|
||||
```
|
||||
|
||||
```
|
||||
git branch --delete <branch_name> # Error on unmerge
|
||||
```
|
||||
|
||||
-D stands for --delete --force which will delete the branch even it's not merged (force delete), but you can also use -d which stands for --delete which throws an error respective of the branch merge status...
|
||||
@@ -0,0 +1,119 @@
|
||||
# Gitflow
|
||||
|
||||
Gitflow is a branching model for Git made by Vincent Driessen. Here the discussion would be the requirements and use-cases of Gitflow.<br />
|
||||
The Gitflow workflow defines a strict branching model designed around the project release, which provides a robust framework for managing larger projects. Gitflow is ideally suited for projects that have a scheduled release cycle and for the DevOps best practice of continuous delivery. It assigns very specific roles to different branches and defines how and when they should interact. It uses individual branches for preparing, maintaining and recording releases.
|
||||
|
||||
|
||||
## Implementation
|
||||
|
||||
1. **Develop and Master Branches**: Instead of a single master branch, Git Flow uses two branches to record the history of the project. It is based on two main branches with infinite lifetime namely master and develop:
|
||||
- **Master Branch**: The master branch contains the production code and stores the official release history.
|
||||
- **Develop Branch**: The develop branch contains pre-production code and serves as an integration branch for features.
|
||||
- **Creating a Develop Branch**:<br />
|
||||
Without using the Gitflow extensions:
|
||||
```
|
||||
git branch develop
|
||||
git push -u origin develop
|
||||
```
|
||||
Using the Gitflow extensions: When using the gitflow extension library, executing `git flow init` on an existing repo will create the develop branch.
|
||||
```
|
||||
git flow init
|
||||
```
|
||||
2. **Feature Branch**: Each new feature should reside in its branch, which can be pushed to the central repository for backup/collaboration. Feature branches use the latest develop as their parent branch. When a feature is complete, it gets merged back into develop. Features should never interact directly with the master branch.
|
||||
- **Creating a Feature Branch**: <br />
|
||||
Without git-flow extensions:
|
||||
```
|
||||
git checkout develop
|
||||
git checkout -b feature_branch
|
||||
```
|
||||
With gitflow extensions:
|
||||
```
|
||||
git flow feature start feature_branch
|
||||
```
|
||||
- **Finishing a Feature Branch**: <br />
|
||||
Without git-flow extensions:
|
||||
```
|
||||
git checkout develop
|
||||
git merge feature_branch
|
||||
```
|
||||
With git-flow extensions:
|
||||
```
|
||||
git flow feature finish feature_branch
|
||||
```
|
||||
3. **Release Branch**: Once develop has acquired enough features for a release (or a predetermined release date is approaching), we fork a release branch off of develop. Creating this branch starts the next release cycle, so no new features can be added after this point—only bug fixes, documentation generation, and other release-oriented tasks should go in this branch. Release branch may branch off from develop and must merge into both master and develop. <br />
|
||||
Using a dedicated branch to prepare releases makes it possible for one team to polish the current release while another team continues working on features for the next release.
|
||||
- **Creating a Release Branch**: <br />
|
||||
Without the git-flow extensions:
|
||||
```
|
||||
git checkout develop
|
||||
git checkout develop
|
||||
git checkout -b release/0.1.0
|
||||
```
|
||||
When using the git-flow extensions:
|
||||
```
|
||||
git flow release start 0.1.0
|
||||
```
|
||||
Switched to a new branch 'release/0.1.0'
|
||||
- **Finishing a Release Branch**: <br />
|
||||
Without git-flow extensions:
|
||||
```
|
||||
git checkout master
|
||||
git merge release/0.1.0
|
||||
```
|
||||
With git-flow extensions:
|
||||
```
|
||||
git flow release finish 0.1.0
|
||||
```
|
||||
4. **Hotfix Branch**: Maintenance or “hotfix” branches are used to quickly patch production releases. Hotfix branches are necessary to act immediately upon an undesired status of master. Hotfix branches are a lot like release branches and feature branches except they’re based on master instead of develop. This is the only branch that should fork directly off of master. As soon as the fix is complete, it should be merged into both master and develop (or the current release branch), and the master branch should be tagged with an updated version number.
|
||||
- **Creating a Hotfix Branch**: <br />
|
||||
Without git-flow extensions:
|
||||
```
|
||||
git checkout master
|
||||
git checkout -b hotfix_branch
|
||||
```
|
||||
With git-flow extensions:
|
||||
```
|
||||
git flow hotfix start hotfix_branch
|
||||
```
|
||||
- **Finishing a Hotfix Branch**: <br />
|
||||
Without git-flow extensions:
|
||||
```
|
||||
git checkout master
|
||||
git merge hotfix_branch
|
||||
git checkout develop
|
||||
git merge hotfix_branch
|
||||
```
|
||||
With git-flow extensions:
|
||||
```
|
||||
git branch -D hotfix_branch
|
||||
git flow hotfix finish hotfix_branch
|
||||
```
|
||||
|
||||
|
||||
## Advantages
|
||||
|
||||
- Ensures a clean state of branches at any given moment in the life cycle of a project.
|
||||
- The naming convention of branches follows a systematic pattern making it easier to comprehend.
|
||||
- Has extensions and support on most used git tools.
|
||||
- Ideal in case of maintaining multiple versions in production.
|
||||
- Great for a release-based software workflow.
|
||||
- Offers a dedicated channel for hotfixes to production.
|
||||
|
||||
|
||||
## Disadvantages
|
||||
|
||||
- Git history becomes unreadable.
|
||||
- The master/ develop branch split is considered redundant and makes the Continuous Delivery/ Integration harder.
|
||||
- Not recommended in case of maintaining a single version in production.
|
||||
|
||||
|
||||
## Summary
|
||||
|
||||
Here we discussed the Git Flow Workflow. Git Flow is one of the many styles of Git workflows you and your team can utilize. Let’s summarize the whole workflow of Git Flow:
|
||||
1. A develop branch is created from master.
|
||||
1. Feature branches are created from develop.
|
||||
1. When a feature is complete it is merged into the develop branch.
|
||||
1. A release branch is created from develop.
|
||||
1. When the release branch is done it is merged into develop and master.
|
||||
1. If an issue in the master is detected a hotfix branch is created from master.
|
||||
1. Once the hotfix is complete it is merged to both develop and master.
|
||||
@@ -0,0 +1,104 @@
|
||||
# Installing Git Ubuntu OS
|
||||
|
||||
Git by default is likely already installed in your Ubuntu OS . You can confirm this by launching your terminal and entering following command in to your terminal:
|
||||
|
||||
```shell
|
||||
$ git --version
|
||||
```
|
||||
|
||||
If you receive output similar to the following, then Voila! you have readily installed Git on your machine.
|
||||
|
||||
```shell
|
||||
Output
|
||||
$ git version 2.34.1
|
||||
```
|
||||
|
||||
If this applies to you, proceed to [set up git](#set-up-git) below.
|
||||
|
||||
If a Git version number was not on the output as shown above, you can still install it using Ubuntu's APT default package manager.
|
||||
|
||||
Update your local package index first by using the apt package management tools. Head back to your terminal and enter the following command.
|
||||
|
||||
```shell
|
||||
$ sudo apt update
|
||||
```
|
||||
|
||||
Once this is completed, then enter the following command to install in Git:
|
||||
|
||||
```shell
|
||||
$ sudo apt install git
|
||||
```
|
||||
|
||||
You can confirm that you have installed Git correctly by running the following command and checking that you receive relevant output.
|
||||
|
||||
```shell
|
||||
$ git --version
|
||||
```
|
||||
|
||||
```shell
|
||||
Output
|
||||
$ git version 2.34.1
|
||||
```
|
||||
|
||||
With Git successfully installed, you can now proceed below by setting it up.
|
||||
|
||||
# Set up Git
|
||||
|
||||
Configuration can be achieved by using the git config command.
|
||||
Specifically, you need to provide your name and email address because Git embeds this information into each commit you do.
|
||||
You can add this information by typing:
|
||||
|
||||
Now that we are done with installing Git, let us configure it for first time use using "git config" command.
|
||||
We need to make sure your username and email address are set correctly. To set them, use the command:
|
||||
|
||||
```shell
|
||||
$ git config --global user.name "Your Name"
|
||||
$ git config --global user.email "youremail@domain.com"
|
||||
```
|
||||
|
||||
You can display all the configuration items that have been set by entering the following command in your terminal:
|
||||
|
||||
```shell
|
||||
$ git config --list
|
||||
```
|
||||
|
||||
If all config field have been set up to your need the output should look something like
|
||||
|
||||
```shell
|
||||
user.name=Your Name
|
||||
user.email=youremail@domain.com
|
||||
```
|
||||
|
||||
...
|
||||
|
||||
# Persist Git Credentials
|
||||
|
||||
By default, Git will keep asking you for your details everytime you want to push to a remote repo.
|
||||
In Git, you can configure the caching of your credentials to avoid entering your username and password repeatedly. There are a couple of methods to achieve this:
|
||||
|
||||
1. Credential caching: Git provides a credential caching system that can store your credentials in memory for a specified period. This way, you don't have to re-enter your details every time you interact with a remote repository.
|
||||
|
||||
To enable credential caching, you can use the following command:
|
||||
|
||||
```shell
|
||||
$ git config --global credential.helper cache
|
||||
```
|
||||
|
||||
By default, Git will cache your credentials for 15 minutes. You can adjust the cache timeout period by specifying the --timeout option followed by the desired number of seconds.
|
||||
|
||||
For example, to set the cache timeout to 1 hour (3600 seconds), you can use:
|
||||
|
||||
```shell
|
||||
$ git config --global credential.helper 'cache --timeout=3600'
|
||||
|
||||
```
|
||||
|
||||
2. Credential Storing: This sets Git's credential helper to "store". When using this credential helper, Git will store the credentials for a remote repository in a plain-text file on disk. This method is the simplest but least secure option for credential storage.
|
||||
|
||||
```shell
|
||||
$ git config --global crednetial.helper store
|
||||
```
|
||||
|
||||
With the store credential helper, the credentials entered for a remote repository will be stored permanently in a file located at ~/.git-credentials on Linux or macOS, or %USERPROFILE%\.git-credentials on Windows. The credentials will be stored in plain text format, which means they are readable if someone gains access to the file.
|
||||
|
||||
The advantage of using the store credential helper is that you won't be prompted for credentials every time you interact with the remote repository. However, keep in mind the security implications of storing credentials in plain text, especially if you are using a shared or public machine.
|
||||
+45
@@ -0,0 +1,45 @@
|
||||
# Keeping your fork synced with this repository
|
||||
|
||||
First, the flow for a full sync should be understood, which is important. In this schema, there are 3 different repos: my public repo on Github `github.com/firstcontributions/first-contributions.git`, your fork of the repo on GitHub `github.com/Your-Name/first-contributions/` and your local machine's repo from which you are suppose to work. This kind of cooperation is typical for open source projects and called `Triangle Workflows`.
|
||||
|
||||
<img style="float;" src="https://firstcontributions.github.io/assets/additional-material/triangle_workflow.png" alt="triangle workflow" />
|
||||
|
||||
To keep your two repos up-to-date with my public repo, we first have to fetch and merge the public repo with your local machine's repo.
|
||||
Our second move will be to push your local repo to your GitHub fork. As you've seen earlier, it's only from your fork that you can ask for a "pull request". So your GitHub fork is the last repo to be updated.
|
||||
|
||||
Now, let's see how to do it:
|
||||
|
||||
First, you must be on your main branch. To know which branch you are on, check the first line of:
|
||||
```
|
||||
git status
|
||||
```
|
||||
if you are not already on main:
|
||||
```
|
||||
git checkout main
|
||||
```
|
||||
|
||||
Then you should add my public repo to your git with `add upstream remote-url`:
|
||||
```
|
||||
git remote add upstream https://github.com/firstcontributions/first-contributions.git
|
||||
```
|
||||
This is a way of telling git that another version of this project exists in the specified url and we're calling it `upstream`. Once your git has a name let's fetch the latest version of the public repository:
|
||||
```
|
||||
git fetch upstream
|
||||
```
|
||||
|
||||
You've just fetched the latest version of my fork (`upstream` remote). Now, you need to merge the public repository into your main branch.
|
||||
```
|
||||
git rebase upstream/main
|
||||
```
|
||||
Here you're merging the public repository with your main branch. Your local machine's main branch is now up-to-date. Lastly, if you push your main branch to your fork, your GitHub fork will also have the changes:
|
||||
```
|
||||
git push origin main
|
||||
```
|
||||
Notice here you're pushing to the remote named `origin`.
|
||||
|
||||
If you want to fetch and merge the latest changes of my fork (`upstream` remote) to your local branch at same time then you can directly go for:
|
||||
```
|
||||
git pull upstream main
|
||||
```
|
||||
|
||||
So by now or at this point, all your repositories are up-to-date. Well done! You should do this, every time your GitHub repo tells you that you are a few commits behind.
|
||||
+25
@@ -0,0 +1,25 @@
|
||||
# Moving a commit to a different branch
|
||||
What if you commit a change, and then realize that you committed to a different branch?
|
||||
How can you change that? This is what this tutorial covers.
|
||||
|
||||
## Moving the latest commits to an existing branch
|
||||
To do this, type:
|
||||
|
||||
```git reset HEAD~ --soft``` - Undoes the last commit, but leaves the changes available.
|
||||
```git stash``` - Records the state of the directory.
|
||||
|
||||
```git checkout name-of-the-correct-branch``` - Switches to another branch.
|
||||
```git stash pop``` - Removes latest stashed state.
|
||||
```git add .``` - Or try adding individual files.
|
||||
```git commit -m "your message here"``` - Saves and Commits the changes.
|
||||
|
||||
Now your changes are on the correct branch
|
||||
|
||||
|
||||
### Moving the latest commits to a new Branch
|
||||
To do this, type:
|
||||
```git branch newbranch``` - Creates a new Branch. Saving all the Commits.
|
||||
```git reset --hard HEAD~#``` - Move master back by # commits. Remember, these commits will be gone from master
|
||||
```git checkout newbranch``` - Goes to the branch you created. It will have all the commits.
|
||||
|
||||
Remember: Any changes not committed will be LOST.
|
||||
@@ -0,0 +1,23 @@
|
||||
# Removing a file from Git
|
||||
|
||||
Sometimes, you may want to remove a file from Git but not delete it from your computer. You can achieve this by using the following command:
|
||||
|
||||
``git rm <file> --cached``
|
||||
|
||||
## So what happened?
|
||||
|
||||
Git will no longer keep track of changes in the removed file. As far as Git knows, it's as if you had deleted the file. If you were to locate the file in your file system, you will notice that it's still there.
|
||||
|
||||
Notice that in the example above, the flag `--cached` is used. If we didn't add this flag, Git will remove the file from not just the repo, but from your file system too.
|
||||
|
||||
If you commit the change with `git commit -m "Remove file1.js"` and pushed it to the remote repository using `git push origin master`, the remote repository will remove the file.
|
||||
|
||||
## Additional features
|
||||
|
||||
- If you want to remove more than one file, you can include them all in the same command:
|
||||
|
||||
`git rm file1.js file2.js file3.js --cached`
|
||||
|
||||
- You can use a wildcard (*) to remove similar files. For example, if you would like to remove all .txt files from your local repository:
|
||||
|
||||
`git rm *.txt --cached`
|
||||
+31
@@ -0,0 +1,31 @@
|
||||
# Remove a branch from your repository
|
||||
|
||||
If you have followed the tutorial up-to-now, our `<add-your-name>` branch has finished its purpose, it is time to delete it from your local machine's repo. This isn't necessary, but the name of this branch shows its rather special purpose. Its life can be made correspondingly short.
|
||||
|
||||
First, let's merge your `<add-your-name>` to your master, so to go to your master branch:
|
||||
```
|
||||
git checkout master
|
||||
```
|
||||
|
||||
Merge `<add-your-name>` to master:
|
||||
```
|
||||
git merge <add-your-name> master
|
||||
```
|
||||
|
||||
Remove `<add-your-name>` on your local machine's repo:
|
||||
```
|
||||
git branch -d <add-your-name>
|
||||
```
|
||||
|
||||
You have now deleted your local machine's `<add-your-name>` branch and everything looks neat and tidy.
|
||||
Though, at this point, you should still have the `<add-your-name>` branch in your GitHub fork. However, before you delete this, remember that you have sent a "Pull request" to my repo from this remote branch. So unless I've already merged it, don't delete this branch.
|
||||
|
||||
However, if I have merged your branch and you want to delete the remote branch, use:
|
||||
```
|
||||
git push origin --delete <add-your-name>
|
||||
```
|
||||
|
||||
Now, you know how to tidy your branches.
|
||||
With time, many commits will be added to my public repo. And the master branches of your local machine and of your GitHub fork won't be up-to-date. So in order to keep your repositories synchronized with mine, follow the steps below.
|
||||
|
||||
#### [Keeping your fork synced with the repository](keeping-your-fork-synced-with-this-repository.md)
|
||||
@@ -0,0 +1,18 @@
|
||||
# Reset a branch
|
||||
|
||||
```reset``` is the command which can be used when we want to reset the repository with respect to a commit or a branch. A reset, as the name suggests, discards everything on the base(current) branch and makes it exactly same as the branch with which we chose to reset the base branch (calling it as origin branch). This essentially means, that we will have a copy of the origin branch with the name of base branch.<br/>
|
||||
However, the question is, why don't we just delete the base branch and checkout a new branch with the name of base branch from origin branch. Technically, it will have the same effect as resetting but in some industrial situations we do not have the access to delete a branch, or we can not delete a branch as it will hamper/disrupt a CI/CD pipeline or maybe an ongoing workflow. Hence, to avoid such situations which can lead to downtimes, we suggest using `git reset` whenever we want to reset a particular branch.
|
||||
|
||||
## The Command
|
||||
|
||||
Its very easy to execute a git reset for branch.
|
||||
```
|
||||
git reset <base_branch> <origin_branch>
|
||||
```
|
||||
|
||||
An example could be:
|
||||
```
|
||||
git reset stage master --hard
|
||||
```
|
||||
The above command will reset the `stage` branch with `master` and therefore make `stage` exactly same as `master`.
|
||||
You must be wondering about why `--hard` flag is used? This is to ignore all the changes which are or will be staged before/after the reset.
|
||||
@@ -0,0 +1,20 @@
|
||||
# Reset a commit
|
||||
|
||||
```reset``` is the command which can be used when we want to move the repository back to a previous commit, discarding any changes made after that commit.<br/>
|
||||
The main difference between resetting and reverting a commit is that git reset ```unstages a file and bring our changes back to the working directory```
|
||||
and git revert ```removes the commits from the remote repository```. <br/>
|
||||
|
||||
```git reset``` can be achieved using following commands:
|
||||
- The following command will give summary of all the commits using following two parameters:
|
||||
|
||||
- The first seven characters of the commit hash - this is what we need to refer to in our **reset** command.
|
||||
- the commit message
|
||||
|
||||
```
|
||||
git log --oneline
|
||||
```
|
||||
|
||||
|
||||
- One can reset repository back to the specific commit using following command: <br />
|
||||
```git reset commithash```
|
||||
where commithash being the first 7 characters of the commit hash we found in the log
|
||||
@@ -0,0 +1,35 @@
|
||||
# What is a merge conflict?
|
||||
|
||||
When you try to merge another branch into your current working branch, you are taking changes from another context and combining them with your current working files.
|
||||
If two people have changed the same lines in the same file, or if one person decided to delete it while the other person decided to modify it, Git cannot identify which is the correct version. Git will then mark the file as having a conflict - which you'll have to resolve before you can continue your work.
|
||||
|
||||
# How to resolve a merge conflict?
|
||||
|
||||
When faced with a merge conflict, git will mark the problematic area in the file by enclosing it in “<<<<<<<< HEAD” and “>>>>>>>>>>[other branch name]”
|
||||
|
||||
The contents after the first marker originate from your current working branch. After the angle brackets, Git tells us where (from which branch) the changes came from. A line with "=======" separates the two conflicting changes.
|
||||
Our job is now to clean up these lines: when we're done, the file should look exactly as we want it to look. It is advisable to consult the teammate who wrote the conflicting changes to decide which version should be final. It could be either one of yours - or maybe a mixture between the two.
|
||||
|
||||
e.g. :
|
||||
```
|
||||
<<<<<<< HEAD:mergetest
|
||||
This is my third line
|
||||
=======
|
||||
This is a fourth line I am adding
|
||||
>>>>>>> 4e2b407f501b68f8588aa645acafffa0224b9b78:mergetest
|
||||
```
|
||||
|
||||
`<<<<<<<`: Indicates the start of the lines that had a merge conflict. The first set of lines are the lines from the file that you were trying to merge the changes into.
|
||||
`=======`: Indicates the break point used for comparison. Breaks up changes that user has committed (above) to changes coming from merge (below) to visually see the differences.
|
||||
`>>>>>>>`: Indicates the end of the lines that had a merge conflict.
|
||||
|
||||
You resolve a conflict by editing the file and then manually merging the parts of the file that git had trouble merging. This may mean discarding either your changes or someone else's or going ahead with a mix of the two. You will also need to delete the '<<<<<<<', '=======', and '>>>>>>>' in the file.
|
||||
|
||||
|
||||
Once you have resolved the conflict do a `git add`. Do not forget to run the tests, as you have to make sure that you have resolved the conflict.
|
||||
|
||||
You can also download different plugins depending on the IDE you are using for an easier way to resolve merge conflicts.
|
||||
|
||||
|
||||
# How to undo a merge?
|
||||
If you want to undo a merge then you can do `git merge —abort`
|
||||
@@ -0,0 +1,41 @@
|
||||
# Revert a commit
|
||||
|
||||
To revert a commit simply means to create a brand new commit that undoes all
|
||||
the changes made in a previous one. It is like doing a ```CTRL + Z ``` on git.
|
||||
|
||||
Reversion is made easier in git because every commit you push to your remote repository has a unique alphanumeric key known as SHA(Secure Hash Algorithm) tied to it.
|
||||
So this means you can revert any commit as long as you have the SHA.
|
||||
But then, you have to be careful to reverse orderly so as not to mess your repository up.
|
||||
|
||||
|
||||
To pick out the SHA of the specific commit we want to undo, a log of all the commits we have made so far would come in handy.
|
||||
To get this, we would run the command:
|
||||
```git log --oneline ```
|
||||
Running the ```git log``` command alone would also give us the SHAs (in long form)
|
||||
However using the ```--oneline ``` flag tells git that we want it displayed in a concise (one line) manner for easy read.
|
||||
|
||||
The first 7 characters displayed when you run this command is called the abbreviated commit hash.
|
||||
|
||||
For example, here is what I get when I run ```git log --oneline ``` on this repository:
|
||||
```
|
||||
389004d added spacing in title
|
||||
c1b9fc1 Merge branch 'master' into tutorials
|
||||
77eaafd added tutorial for reverting a commit
|
||||
```
|
||||
|
||||
So this shows that with ```git log --oneline```, we can fetch a list of all the commits made on the repository together with the first 7 characters of its SHA.
|
||||
|
||||
Now, Let's assume I want to undo my commit of "added spacing in title", here are the steps I would take:
|
||||
|
||||
* Copy the SHA of the commit which, in this case is ```389004d```
|
||||
* Then, run the command ```git revert 389004d```
|
||||
|
||||
This would pop open my text editor and prompt me to edit the commit message.
|
||||
You can decide to leave the commit message as the default git message which starts with the word `Revert`
|
||||
or you can also decide to customize the message to your liking.
|
||||
|
||||
* Next, I will save and close the text editor.
|
||||
* Return to the command line.
|
||||
* Run ```git push origin <branch-name>``` to push the reverted changes to Github.
|
||||
|
||||
And that is it, the change would be undone. In this case, my repository would be reverted to how it looked like in ```c1b9fc1```
|
||||
@@ -0,0 +1,86 @@
|
||||
# What is squashing?
|
||||
|
||||
In git, squashing refers to rewriting the history of your commits, so you end up with one commit with a description of the changes done.
|
||||
It's usually done in open source projects because a lot of the history of a branch in open source projects is only relevant to the developer who created it, and this provides a simpler way to describe the changes made and also revert them if needed.
|
||||
|
||||
# How do you squash commits?
|
||||
|
||||
First, perform a git log to review the commits you would like to merge in your current branch.
|
||||
|
||||
```
|
||||
git log
|
||||
```
|
||||
|
||||
You should see a series of your commits like so:
|
||||
|
||||
```
|
||||
commit blablabla
|
||||
Author: omguhh
|
||||
Date: 10/10/20
|
||||
Commit message 1
|
||||
|
||||
commit blablabla2
|
||||
Author: omguhh
|
||||
Date: 10/10/20
|
||||
Commit message 2
|
||||
```
|
||||
|
||||
So now that you see the commits you wish to merge to one, we can move along into doing that with ```git rebase```. Assuming you're already familiar with ```git rebase```, we can starting squashing commits in the interactive mode of git rebase that you can activate like so:
|
||||
|
||||
```
|
||||
git rebase -i
|
||||
```
|
||||
|
||||
Now, with interactive rebasing you can specify the starting and end point of how far back you want to go with commits like so:
|
||||
|
||||
```
|
||||
git rebase -i HEAD~2
|
||||
```
|
||||
|
||||
Running this command will show you something like the following:
|
||||
|
||||
```
|
||||
pick blablabla Changing test01.txt file
|
||||
pick blablabla2 Adding dummy01.txt file
|
||||
|
||||
#
|
||||
# Commands:
|
||||
# p, pick = use commit
|
||||
# r, reword = use commit, but edit the commit message
|
||||
# e, edit = use commit, but stop for amending
|
||||
# s, squash = use commit, but meld into previous commit
|
||||
# f, fixup = like "squash", but discard this commit's log message
|
||||
# x, exec = run command (the rest of the line) using shell
|
||||
#
|
||||
# These lines can be re-ordered; they are executed from top to bottom.
|
||||
#
|
||||
# If you remove a line here THAT COMMIT WILL BE LOST.
|
||||
#
|
||||
# However, if you remove everything, the rebase will be aborted.
|
||||
#
|
||||
# Note that empty commits are commented out
|
||||
```
|
||||
|
||||
So if you want to squash ```blablabla2``` into ```blablablabla```, you would change the following :
|
||||
|
||||
```
|
||||
pick blablabla Changing test01.txt file
|
||||
squash blablabla2 Adding dummy01.txt file
|
||||
|
||||
```
|
||||
|
||||
If all goes well, you'd get a result that looks like this:
|
||||
|
||||
```
|
||||
# This is a combination of 2 commits.
|
||||
# The first commit's message is:
|
||||
commit message 1
|
||||
|
||||
# This is the 2nd commit message:
|
||||
|
||||
commit message 2
|
||||
```
|
||||
|
||||
That you can freely change before you decide to exit the editor to save these changes.
|
||||
|
||||
Running git log again should show you the commit message you entered before exiting the screen with the commits combined into one.
|
||||
@@ -0,0 +1,137 @@
|
||||
# Stashing
|
||||
|
||||
What if you are working on a big code and suddenly you need to switch the branch from which you are currently working on to some other branch. Since the code, is not complete, and without any tests, you probably don't want to commit it. But you cannot move to the other branch without committing the changes, Git won't let you break this flow. What do we do then? How do we prevent an unnecessary commit, while being able to jump branches? This is what this tutorial covers.
|
||||
|
||||
## Stashing your work
|
||||
|
||||
Let's assume you are working on a project's branch where you have changed some files. Now if you run ```git status``` you can see your changes in the files.
|
||||
|
||||
```
|
||||
$ git status
|
||||
# On branch master
|
||||
# Changes to be committed:
|
||||
# (use "git reset HEAD <file>..." to unstage)
|
||||
#
|
||||
# modified: index.html
|
||||
#
|
||||
# Changes not staged for commit:
|
||||
# (use "git add <file>..." to update what will be committed)
|
||||
#
|
||||
# modified: lib/simplegit.rb
|
||||
#
|
||||
```
|
||||
|
||||
Now you want to switch your branch, but don't want to commit the changes yet; so you would stash the changes.
|
||||
To push a new stash on to your stack, run ```git stash```:
|
||||
|
||||
```
|
||||
$ git stash
|
||||
Saved working directory and index state \
|
||||
"WIP on master: 049d078 added the index file"
|
||||
HEAD is now at 049d078 added the index file
|
||||
(To restore them type "git stash apply")
|
||||
```
|
||||
|
||||
Now your working directory is clean, use ```git status``` :
|
||||
|
||||
```
|
||||
$ git status
|
||||
# On branch master
|
||||
nothing to commit, working directory clean
|
||||
```
|
||||
|
||||
Now you can switch to any branch and do your work; your stashed changes are stored in form of a stack. To see which stashes you have stored in the stack you can use ```git stash list```:
|
||||
|
||||
```
|
||||
$ git stash list
|
||||
stash@{0}: WIP on master: 049d078 added the index file
|
||||
stash@{1}: WIP on master: c264051 Revert "added file_size"
|
||||
stash@{2}: WIP on master: 21d80a5 added number to log
|
||||
```
|
||||
|
||||
In case you want to re-apply the changes you just stashed, you can use the command ```git stash apply```. By using this command you can reapply the most recent stashed file. In order to reapply any other file, you can specify it by naming it like: ```git stash apply <stash-name>```, in place of ```<stash-name>``` write the name of the stash you need to reapply.
|
||||
|
||||
```
|
||||
$ git stash apply
|
||||
# On branch master
|
||||
# Changes not staged for commit:
|
||||
# (use "git add <file>..." to update what will be committed)
|
||||
#
|
||||
# modified: index.html
|
||||
# modified: lib/simplegit.rb
|
||||
#
|
||||
```
|
||||
|
||||
You can see that git re-modifies the file that you uncommitted when you saved the stash. In this case, you had a clean working directory when you tried to apply the stash, and you tried to apply it on the same branch you saved it from; but having a clean working directory and applying it on the same branch aren’t necessary to successfully apply a stash. You can save a stash on one branch, switch to another branch later, and re-apply the changes in the new branch. You can also have modified and uncommitted files in your working directory when you apply a stash, git gives merge conflicts if anything no longer applies cleanly.
|
||||
|
||||
The changes made to your files are reapplied, but the file you staged was not restaged. To do so you need to run the command ```git stash apply``` with a ```--index``` to tell the command to reapply the staged changes. If you have run that instead, you would have returned to your original position:
|
||||
|
||||
```
|
||||
$ git stash apply --index
|
||||
# On branch master
|
||||
# Changes to be committed:
|
||||
# (use "git reset HEAD <file>..." to unstage)
|
||||
#
|
||||
# modified: index.html
|
||||
#
|
||||
# Changes not staged for commit:
|
||||
# (use "git add <file>..." to update what will be committed)
|
||||
#
|
||||
# modified: lib/simplegit.rb
|
||||
#
|
||||
```
|
||||
|
||||
The apply command only applies the stashed work, but you still have that on your stack. In order to remove it, you can run ```git stash drop``` with the name of the stash to remove.
|
||||
|
||||
```
|
||||
$ git stash list
|
||||
stash@{0}: WIP on master: 049d078 added the index file
|
||||
stash@{1}: WIP on master: c264051 Revert "added file_size"
|
||||
stash@{2}: WIP on master: 21d80a5 added number to log
|
||||
$ git stash drop stash@{0}
|
||||
Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43)
|
||||
```
|
||||
|
||||
You can use ```git stash pop``` to un-stash the last changes drop it from your stash's stack.
|
||||
|
||||
## Un-applying a Stash
|
||||
|
||||
In some cases you want to apply stashed changes, do some work, but un-apply the changes that originally came from the stash. Git does not provide command like ```git unapply```, but it is possible to achieve this effect by simply retrieving the patch associated with a stash and applying it in reverse:
|
||||
|
||||
```$ git stash show -p stash@{0} | git apply -R```
|
||||
|
||||
Again if you don't specify a stash, Git assumes the most recent stash:
|
||||
|
||||
```$ git stash show -p | git apply -R```
|
||||
|
||||
You may want to create an alias and effectively add a ```stash-unapply``` command to your Git. For example:
|
||||
|
||||
```
|
||||
$ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
|
||||
$ git stash apply
|
||||
$ #... work work work
|
||||
$ git stash-unapply
|
||||
```
|
||||
|
||||
## Creating a Branch from Stash
|
||||
|
||||
If you stash some work, leave it there for a while, and continue on the branch from which you stashed the work, you may have a problem reapplying the work. If the apply tries to modify a file that you’ve since modified, you’ll get a merge conflict and will have to resolve it. If you want an easier way to test the stashed changes again, you can run ```git stash branch```, which creates a new branch for you, checks out the commit you were on when you stashed your work, reapplies your work there, and then drops the stash if it applies successfully:
|
||||
|
||||
```
|
||||
$ git stash branch testchanges
|
||||
Switched to a new branch "testchanges"
|
||||
# On branch testchanges
|
||||
# Changes to be committed:
|
||||
# (use "git reset HEAD <file>..." to unstage)
|
||||
#
|
||||
# modified: index.html
|
||||
#
|
||||
# Changes not staged for commit:
|
||||
# (use "git add <file>..." to update what will be committed)
|
||||
#
|
||||
# modified: lib/simplegit.rb
|
||||
#
|
||||
Dropped refs/stash@{0} (f0dfc4d5dc332d1cee34a634182e168c4efc3359)
|
||||
```
|
||||
|
||||
This is a nice shortcut to recover stashed work easily and work on it in a new branch.
|
||||
@@ -0,0 +1,48 @@
|
||||
# Storing Credentials
|
||||
|
||||
You might have complained about this before - entering your username and password each time you access the repository can be a hassle and can interrupt your workflow if it takes too long. But it doesn't need to be that way.
|
||||
|
||||
We will be covering one of the methods available to us - [git credential cache](https://git-scm.com/docs/git-credential-cache).
|
||||
|
||||
**Note:** Please follow the security policies of your place of work/study.
|
||||
|
||||
## Caching
|
||||
|
||||
We can use git credential cache to store our username and password.
|
||||
|
||||
**Attention:** This method saves the credentials in *plaintext* on your PC's disk. Everyone on your computer can access it, e.g. malicious NPM modules.
|
||||
|
||||
### Global Credential Cache
|
||||
|
||||
If we wish to, we can store the credentials for every repository we are working with using one simple command:
|
||||
|
||||
```
|
||||
$ git config --global credential.helper cache
|
||||
```
|
||||
|
||||
**Reminder:** Please follow the security policies of your place of work/study.
|
||||
|
||||
### Repository Credential Cache
|
||||
|
||||
We can store the credentials for the repository we are working with using one simple command, similar to before:
|
||||
|
||||
```
|
||||
$ git config credential.helper cache
|
||||
```
|
||||
|
||||
**Reminder:** Please follow the security policies of your place of work/study.
|
||||
|
||||
### Cache Timeout
|
||||
|
||||
If we do not specify a length of time to store our credentials, they can potentially be stored forever. However, we can determine how long they will be kept in memory using this command:
|
||||
|
||||
```
|
||||
git config credential.helper 'cache --timeout=<timeout>'
|
||||
```
|
||||
|
||||
Using the helper, the credentials will never touch the disk and will be erased after the specified timeout. The default value is 900 seconds (15 minutes).
|
||||
|
||||
#### References
|
||||
[Stack Overflow](https://stackoverflow.com/questions/35942754/how-can-i-save-username-and-password-in-git)
|
||||
|
||||
### [Additional Material](additional-material.md)
|
||||
@@ -0,0 +1,55 @@
|
||||
# Undo local commits
|
||||
|
||||
To undo a local commit, all you need to do is
|
||||
```
|
||||
git reset
|
||||
```
|
||||
This command will reset your staging area to your most recent commit, but the changes you made to your working directory will not change. So, you can still re-commit again what you've changed.
|
||||
Or, if you only want to remove one file from your previous commit. Then, you can do the command below
|
||||
```
|
||||
git reset <file>
|
||||
```
|
||||
The command will remove only the specified file from the staging area, but changes made on the file will still remain.
|
||||
|
||||
Example of ```git reset``` usage
|
||||
```
|
||||
# Make changes in index.php and tutorial.php
|
||||
# Add files into the staging area
|
||||
$ git add .
|
||||
# Remembered both files need to be committed separately
|
||||
# Unstage tutorial.php
|
||||
$ git reset tutorial.php
|
||||
# Commit index.php first
|
||||
$ git commit -m "Changed index.php"
|
||||
# Commit tutorial.php now
|
||||
$ git add tutorial.php
|
||||
$ git commit -m "Changed tutorial.php"
|
||||
```
|
||||
|
||||
Let's say if you have messed up your local repository and you just want to reset it to your last commit.
|
||||
Then, you can run the command below.
|
||||
```
|
||||
git reset --hard
|
||||
```
|
||||
The command will not only reset your staging area, but also revert all your changes on the files to your last commit.
|
||||
The mode ```--hard``` tells Git to undo all the changes in the working directory too.
|
||||
You should only run this when you are really sure of throwing your whole local development out.
|
||||
|
||||
Example of ```git reset --hard``` usage
|
||||
```
|
||||
# Decided to start a crazy experiment
|
||||
# Create a new file 'crazy.php' and add some code to it
|
||||
# Commit crazy.php
|
||||
$ git add crazy.php
|
||||
$ git commit -m "Started a crazy dev"
|
||||
# Edit crazy.php file again and changed a lot of other files
|
||||
# Commit all tracked files
|
||||
$ git add .
|
||||
$ git commit -m "Continued dev"
|
||||
# Tested and things went out of hand
|
||||
# Decided to remove the whole things
|
||||
$ git reset --hard HEAD~2
|
||||
```
|
||||
The ```git reset --hard HEAD~2``` moves the current branch backward by 2 commit points at the same time reverting all changes you have made and remove the 2 snapshots we have just created from project history.
|
||||
|
||||
P.s. Never perform ```git reset --hard``` if you've already pushed your commits to a shared repository as it will cause problems to everyone on that repository.
|
||||
@@ -0,0 +1,53 @@
|
||||
# WHY USING BRANCHES DURING CONTRIBUTING
|
||||
|
||||
## What are branches.
|
||||
|
||||
Branches are simply pointers to a commit.
|
||||
|
||||
When you branch out, git is essentially making a new state of your current code, upon which you can work, without affecting the important main state of the code (which is in master branch).
|
||||
|
||||
When you are happy with your experiments, and want to merge you experiments in main code, you run git merge
|
||||
<branch name> master.
|
||||
This will tell git, to add in all changes from your experiment branch into master.
|
||||
|
||||
This way, while working in an open source project with a number of contributors, it becomes easy to merge the best suited code without altering the main code or master branch.
|
||||
|
||||
## How it works?
|
||||
|
||||
A branch represents an independent line of development. Branches serve as an abstraction for the edit/stage/commit process. You can think of them as a way to request a brand new working directory, staging area, and project history. New commits are recorded in the history for the current branch, which results in a fork in the history of the project.
|
||||
|
||||
The git branch command lets you create, list, rename, and delete branches. It doesn’t let you switch between branches or put a forked history back together again. For this reason, git branch is tightly integrated with the git checkout and git merge commands.
|
||||
|
||||
## Why to use branches?
|
||||
|
||||
If the question "Why do we use branching in version control like git?" still persists in your mind, here's a quick explanation:
|
||||
|
||||
Let's take a simple example to understand the branching strategy. A production car needs a paint job before its launch. Prior to its official sale, it was decided that the car would come in 'olive green' color as default. But some of the members in the manufacturing team decided to showcase the car in 'red' color. Hence an ambiguous situation arises and to avoid this problem branching was introduced.The red color paint job is like a branch to the master repository 'Car'. Pushing this branch will suggest the red color. If merged with the master repository the car will get the red color otherwise it will continue with olive green. Merging a contributors branch to the master repo of the organization depends on the project head.
|
||||
|
||||
## Example
|
||||
|
||||
Alice is working on Feature A and Bob is working on Feature B. Alice is halfway done with Feature A and has made a few commits in alice. However, Feature A is quite hard to implement so Alice decides that she should rather work on Feature C and makes a few commits onto alice. Bob finished Feature B and decides that he would like to tackle Feature A and so pulls alice into bob.
|
||||
|
||||
After Bob finishes Feature A he would like to merge bob into master. However, bob now contains Feature A, Feature B and parts of Feature C, but Feature C is not ready to be merged! It's easy to see that a workflow like this can lead to many confusing merge conflicts.
|
||||
|
||||
The trick is that instead of having personal branches one should have feature branches. Alice should have a branch for Feature A and Feature C and Bob should have a branch for Feature B and Feature A. That way they both can work on different features without tramping on each other's toes.
|
||||
|
||||
## How to create branches?
|
||||
|
||||
#### Create a branch
|
||||
|
||||
```
|
||||
git branch AnyBranchName
|
||||
```
|
||||
|
||||
A new branch will be created named AnyBranchName and all the file changes in this branch will not be affected in the main branch.
|
||||
For detailed explanation refer [How to create branch](https://www.atlassian.com/git/tutorials/using-branches)
|
||||
|
||||
#### Delete the branch
|
||||
|
||||
```
|
||||
git branch -d AnyBranchName
|
||||
```
|
||||
|
||||
Branch name AnyBranchName will be deleted from the git repository.
|
||||
Refer to [Removing branch from your repository](https://github.com/jashnimje/first-contributions/blob/7dcae72208e4b42fcf834b4f189fa8ee78238077/additional-material/git_workflow_scenarios/removing-branch-from-your-repository.md)
|
||||
Reference in New Issue
Block a user