Do you know Git? It is a very cute and cute friend that he is pursuing. Before, when I first met him, I felt he was complicated and confused. There are people who, at first, make you mad, but when you understand that person, you can not stop loving him. And with Git too, the more I contacted him, I discovered that he is not really as hard as he thought. So, I miss him. And today, I will tell you about him. Of course, I will not say who Git is? Hihi, it's not jealousy.
1. Explain
What is a repository, branch?
- The repository: It is a repository, consisting of multiple branches, change history of files, and commit associated with each change on each branch.
- branch: branch of work, including code history and commit on branch. Branches are independent.
- There are 2 types of repository:
- local repository: is the repository at your computer.
- remote repository: is a repository at Github's server.
In case you are just a standalone project, not a fork project for further development, your remote will only include your personal github (Origin).
As shown above, the add command will move the new file from untracked to tracked. And after the add, the file can be edited, and commit will check to see if the file is edited or not. If after add, there is no editing, the new file can be pushed. Conversely, if there is an edit, the file must be added, to record the change history and then be able to push. The commit will ensure that files have been flagged for change and have been unmodified (no more changes). At the same time, commit will save a summary of the changes you made, then the files will be ready to be pushed to the remote.
2. Should merge or rebase
Merge:
- Code Enclosure (code change history)
- Merge two branches to a new commit
Fox:
- Include code and commits
- Bringing another branch commit to the current branch
- The last commit is the last commit before the rebase of the current branch.
Conclusion : If you want to keep the commit history simple, use rebase. Conversely, if you want specific commit history, explicitly use merge. However, when using rebase, the status of the files in commit 3 will be changed, which can lead to the original commit not working. The next section will help you solve this problem.
3. Do not worry when you do not see the code.
No matter how much you love someone, it will be hard to avoid the time when you two together. And with Git, sometimes I do not understand (even if it is understood too) what he did with his project, making himself whole soul. For example, when fixing conflix or rebase code, or when committing, using git reset to ignore files, ... Those times, code or find a way to break up it is not feasible (especially when it is crushed). she's gone huhu). In that situation, what should we do? Find out what.
First, be careful with git reset:
This will move the HEAD pointer to the commit location, but depending on the option, the history of the files will be or will not be left intact.
And if you miss
$ git reset --hard
and lose everything, do not worry. As long as you commit, you will definitely get the code back, since Git is really cute.First, let's review the history of work with git reflog:
$ git reflog --oneline
Next, select the history you want to return. Obtain its id, and execute the command:
$ git reset --hard <id>
So everything was back to normal. This command is really good, it's like a time machine, you can go back to any point in time, but with the condition that it was time to commit slightly.
No comments:
Post a Comment