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

add branching

Browse source
This commit is contained in:
Ric Harvey 2024-05-01 16:52:25 +01:00
parent 5f931df4a3
commit 3fb49cc642
Signed by: ric
GPG key ID: 7FDEB4C0C7D5CB61
1 changed files with 33 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

38
README.md
View file

@ -26,17 +26,45 @@ flowchart TD
D --> |git pull| A
```
## Sync Issues
## Commits
### Push
### Tags and Releases
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!
## Branches
In a git repository you have a **main** branch. This is where you keep the current code, normally the current working code. When you develop new features, often team members work on these in parrallel to each other and you guessed it they don't want to be dealing with loads of merge conflict issues. Luckily, theres a way to avoid this by using a feature called **branch**. This lets you take a point in time copy of the repository and work onthe code, adding, commiting and pushing files as you please, without breaking things for others. Now when you are ready to move your code into the main branch you do something called a merge, often called a merge request(MR) or pull request(PR) - (these are the same thing). What git does here is move your new files into the main branch and if there are any merge conflicts on files that already existed you'll get teh options to handle them like before. You can switch between branches using the **branch** and **checkout** commands.
Let's try and visualise this in the diagram below showing we have a main branch and two feature branches called A and B, these branches are taken at different times from the main branc. We can also see that Feature A gets merged back into the main branch. Now you'll also notice numbers next to each dot int he diagram. These are the UID's for the commits you make. These are super important because it means you can roll back to a previous version of the code by using that UID at any time!ß
```mermaid
gitGraph
commit
commit
branch feature-A
checkout feature-A
commit
commit
commit
checkout main
commit
branch feature-B
checkout feature-B
commit
commit
commit
checkout main
commit
commit
commit
merge feature-A
commit
commit
```
### HEAD
### Tags and Releases
## Forks
## Merging