Site Tools


marc:linux:git

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
marc:linux:git [2022/07/25 14:16] – [Forking] marcvmarc:linux:git [2022/08/09 09:46] (current) – [Rebasing vs Merging] marcv
Line 1055: Line 1055:
  
 ===== Fork & Clone; Another Workflow ===== ===== Fork & Clone; Another Workflow =====
 +
 +{{:marc:linux:fork_workflow.png?direct&700|}}
  
 This workflow is different from the previously discussed workflows; instead of just one centralized Github repository, __every developer has their own Github repository__ in addition to the "main" repository. Developers make changes and push to their own **forks** before making **pull requests**. This workflow is different from the previously discussed workflows; instead of just one centralized Github repository, __every developer has their own Github repository__ in addition to the "main" repository. Developers make changes and push to their own **forks** before making **pull requests**.
Line 1066: Line 1068:
 As with Pull Requests, forking is NOT a Git feature. As with Pull Requests, forking is NOT a Git feature.
  
-When we want to fork a Github repository we do NOT clone it! Instead, look for the button top right **Fork**!+When we want to fork a Github repository we do NOT clone it! Instead, look for the button top right **Fork**! {{ :marc:linux:fork.png?direct&200|}} 
 + 
 +=== Forking Workflow === 
 + 
 +{{:marc:linux:forking_workflow.png?direct&700|}} 
 + 
 + 
 +The workflow now would be: 
 +  - Fork a repository 
 +  - Clone the forked repository to your local machine 
 +  - Add upstream remote (original repository): ''**git remote add upstream url_original_remote**'' 
 +  - Work on the code (**remember feature branches**) 
 +  - Commit locally 
 +  - Push to remote (**forked repository**) 
 +  - Make a Pull Request for the maintainers 
 +  - If PR is accepted and merged into upstream main: **pull upstream** 
 + 
 +Besides forking and working on our own repository, we also would want to link to the original repository to fetch changes made by other developers on the repository: 
 + 
 +{{:marc:linux:link_upstream.png?direct&700|}} 
 + 
 +As you can see in the picture above, the remote from which I cloned the (forked) repo locally is called **origin**. As we want to merge changes made by others in the original repo, we want to link to this repository as well. It is custom to name this link **upstream** or **original**. 
 + 
 +:!: After pushing to the Forked Repo, Github will tell you if your repository differs from the original repository: 
 + 
 +{{:marc:linux:diferences_forked_repo.png?direct&700|}} 
 + 
 +We can easily make a PR or examine the differences from here! 
 + 
 +====== Git Rebase ====== 
 + 
 +Very useful as long as you know when NOT to use it! 
 + 
 +Rebasing can be used: 
 +  - as an alternative to merging branches 
 +  - as a cleanup tool 
 + 
 + 
 +===== Rebasing vs Merging =====  
 + 
 +Imagine you are working on a feature branch while a lot of other people are working on other features. While you are working on your feature branch, the remote main branch gets keeping changed with changes made by other developers. You would want to merge these changes into your local feature branch. 
 + 
 +{{:marc:linux:rebasing1.png?direct&700|}} 
 + 
 +Because of these merges, there are a lot commits which are not really functional but just merges. The same goes for the other developers. 
 + 
 +Instead of merging the changes from remote main all the time, we can //rebase// which rewrites history: 
 + 
 +{{:marc:linux:rebase2.png?direct&700|}} 
 + 
 + 
 +===== Git Rebase Basics ===== 
  
 +===== When NOT to Rebase ===== 
marc/linux/git.1658751370.txt.gz · Last modified: (external edit)

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki