ric/git-guide
1
0
Fork 0
mirror of https://gitlab.com/ric_harvey/git-guide.git synced 2024-11-27 13:24:03 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

fix a few bits

Browse source
This commit is contained in:
Ric Harvey 2024-05-01 17:08:10 +01:00
parent 816ed6228c
commit fe52e461d7
Signed by: ric
GPG key ID: 7FDEB4C0C7D5CB61
1 changed files with 5 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
README.md
View file

@ -28,7 +28,11 @@ flowchart TD
## Sync Issues
When working with other developers you're all going to be cloning and pulling the code fromt he rmeote repository to start with and then committing and pushing your changes back. Now this is where it can get messy. Let's say theres a file called **header.html** in your repository and you and another developer change that file and push it back to remote repository. This could end up in whats known as a **merge conflict**. Basically you have both created a different version of the file from the initial clone so what happens now? Which one should be the one stored. Well this is where git is really clever. It accept the first persons commit and push without issues, the second person however will be notified of the conflict and be presented with some options. They will be asked to review the file locally and will be given a version of **header.html** that contains a diff showing both users contributions. You can then resolve this conflict by creating a merged version of both of your files or accept their changes or your changes only. We'll cover these in more details later, but for not a good way to minimise this happening to you is to frequently run ```git pull``` in your working directory to keep up to date with others work, however, whilst this works for small teams later gteams will want to consider something more robust so they don't keep tripping over each other. This is where branches come in!
When working with other developers you're all going to be cloning and pulling the code fromt he rmeote repository to start with and then committing and pushing your changes back. Now this is where it can get messy. Let's say theres a file called **header.html** in your repository and you and another developer change that file and push it back to remote repository. This could end up in whats known as a **merge conflict**. Basically you have both created a different version of the file from the initial clone so what happens now? Which one should be the one stored. Well this is where git is really clever. It accept the first persons commit and push without issues, the second person however will be notified of the conflict and be presented with some options. They will be asked to review the file locally and will be given a version of **header.html** that contains a diff showing both users contributions. You can then resolve this conflict by creating a merged version of both of your files or accept their changes or your changes only.
The way to read the merge conflict is to look in the file(s) affected and look for the merge markers **<<<<<<<**, **=======** and **>>>>>>>** which highlights the conflicting sections. You decide which changes to keep, remove or modify and save the file.
A good way to minimise this happening to you is to frequently run ```git pull``` in your working directory to keep up to date with others work, however, whilst this works for small teams larger teams will want to consider something more robust so they don't keep tripping over each other. This is where branches come in!
## Branches
@ -86,8 +90,6 @@ gitGraph
## Forks
## Merging
## Getting Setup
## Advanced Setup (Highly Recommended)