Skip to content

Latest commit

 

History

History
120 lines (97 loc) · 7.65 KB

temp.md

File metadata and controls

120 lines (97 loc) · 7.65 KB

NOTE: The initial part of this repo is on the hosted site. The parts below are in the process of being migrated to the hosted version.

This repo will always be a work in progress, so do make PRs to add your knowledge to it and correct any mistakes that might've been made! (TBC = To be continued)

Common mistakes and how to correct them

Conflict handling (CLI Version)

  • Conflicts only affect the developer conducting the merge, the rest of the team is unaware of the conflict. Git will mark the file as being conflicted and halt the merging process. It is then the developers' responsibility to resolve the conflict.
  • Git can automatically merge commits unless there are changes that conflict in both commit sequences.
  • Eg: If in the two branches that are trying to be merged, both have changes in the same part of the same file, Git won't be able to figure out which version to use.
  • There are different types of merge conflicts.
    • Git fails to start the merge (due to unsaved local changes, so use git stash, git commit, git reset, git checkout etc to stabilize local.)
    • Git fails the ongoing merge (Git will do its best to merge the files but will leave things for the developer to resolve manually in the conflicted files.)
  • To represent the differences, visual markers used by are: <<<<<<<, ======= and >>>>>>>.
  • Generally the content before the ======= marker is the receiving branch and the part after is the merging branch.
  • Resolving a merge conflict
    • Use git status to identify the merge issues.
    • The most direct way to resolve a merge conflict is to edit the conflicted file. Open the file in a text editor and make the necessary changes to resolve the conflict. (Eg: Add the missing lines, delete the extra lines, etc...)
    • When the developer is ready to finish the merge, all they have to do is run git add <file_name> on the conflicted file(s) to tell Git that they're resolved.
    • Then, one has to run a normal git commit -m "<commit_msg>" to generate the merge commit.
    • Git will see that the conflict has been resolved and creates a new merge commit to finalize the merge.
  • Note: Merge conflicts will only occur in the event of a 3-way merge. It’s not possible to have conflicting changes in a fast-forward merge.
  • Conflicts can occur for single files as well. They have to be handled in the same way as above.
  • git diff
    • git diff helps find differences between states of a repository/files.
    • This is useful in predicting and preventing merge conflicts.
    • This command shows the code differences between a file in the Staging Area and the edits made to that file that currently exist in the Working Tree.
    • Use git diff <file_name.ext> to view the differences of just one file.
    • To see the changes in the Staging Area use git diff --staged
    • git status and git diff should be used frequently as they give information about the current working state and what git is aware of. They allow one to see what changes have occurred since their last checkpoint and are what one can use to guide themselves to atomic commits.

Git CLIs vs GUIs

GitHub basics

  • Repos (Part 2)
    • In version control systems, repositories are accessed over a network which acts like a server and version control tool as a client. On establishing successful connection, clients store or retrieve their changes.
    • Private and public repos
    • Licenses
    • README.md
  • GitHub is not git.
    • Git is a revision control system, a tool to manage your source code history.
    • GitHub is a hosting service for Git repositories.
    • So they are not the same thing: Git is the tool, GitHub is the service for projects that use Git.
  • Forking repos
    • A fork is a copy of a repository. Forking a repository allows to freely experiment with changes without affecting the original project.
    • When a user forks a repository, all the files in the repository are automatically copied to the user’s account on GitHub and it feels like the user’s own repository. The user is then free to use this repository either for their purpose or experiment with changes in the code. Through git forking, the users can develop their own modifications to the code that belongs to someone else.
    • To make changes to the original project, make a PR.
  • PRs
    • A pull request is a method of submitting contributions to an open development project.
    • A pull request occurs when a developer asks for changes committed to an external repository to be considered for inclusion in a project’s main repository.
    • It is important to note that 'pull requests' are a workflow method, and are not a feature of the version control system itself.
  • Issues
    • Issues are a great way to keep track of tasks, enhancements, and bugs for your projects.
    • Most software projects have a bug tracker of some kind. GitHub’s tracker is called Issues, and has its own section in every repository.
    • Anyone can raise issues.
  • Starring repos
    • Save a repo for future reference.
  • Conflict Handling (GUI Version)
    • xyz
  • GitHub Desktop
    • GUI (like Atlassian BitBucket, SourceTree, etc.)
    • Used for collaboration among developers and during competitions like hackathons.
  • GitHub Student Developer's Pack
    • Free and gives TONS for features.
    • Upload valid college ID and e-mail (personal e-mail if you don't have a college-provided e-mail ID)
    • Will have to be renewed.

Open Source

Communities & meetups

Misc

Misc resources & articles for Git

NOTE: This section has been moved to the hosted version at https://harshkapadia2.github.io/git_basics/#_resources

BYE BYE! ( :

Star this repo if you liked it and don't forget to share it with your friends/coworkers!