Download to read offline
![What is Source Control?
1 public static void main(String[] args) {
2 int a = Integer.parseInt(args[0]);
3 int b = Integer.parseInt(args[1]);
4 }
1 public static void main(String[] args) {
2 int a = Integer.parseInt(args[0]);
3 int b = Integer.parseInt(args[1]);
4 }
5
6 public int add(int a, int b) {
7 return a + b;
8 }
Change 1 Change 2](https://image.slidesharecdn.com/intotosourcecontrol-231204200925-d8e7852f/85/Introduction-to-Git-Source-Control-2-320.jpg)
![Why do we have Source Control?
1 public static void main(String[] args) {
2 int a = Integer.parseInt(args[0]);
3 int b = Integer.parseInt(args[1]);
4 }
5
6 public int add(int a, int b) {
7 return a + b;
8 }
1 public static void main(String[] args) {
2 int a = Integer.parseInt(args[0]);
3 int b = Integer.parseInt(args[1]);
4 int c = a + b;
5 System.out.println(c + “”);
6 }
7
Person 1 Person 2](https://image.slidesharecdn.com/intotosourcecontrol-231204200925-d8e7852f/85/Introduction-to-Git-Source-Control-3-320.jpg)
![Cloning
1 public static void main(String[] args) {
2 int a = Integer.parseInt(args[0]);
3 int b = Integer.parseInt(args[1]);
4 }
1 public static void main(String[] args) {
2 int a = Integer.parseInt(args[0]);
3 int b = Integer.parseInt(args[1]);
4 }
5
6 public int add(int a, int b) {
7 return a + b;
8 }
clone
master (remote)
master (working)
File System](https://image.slidesharecdn.com/intotosourcecontrol-231204200925-d8e7852f/85/Introduction-to-Git-Source-Control-7-320.jpg)
More Related Content
Similar to Introduction to Git Source Control
More from John Valentino
Introduction to Git Source Control
- 1.
- 2. What is SourceControl? 1 public static void main(String[] args) { 2 int a = Integer.parseInt(args[0]); 3 int b = Integer.parseInt(args[1]); 4 } 1 public static void main(String[] args) { 2 int a = Integer.parseInt(args[0]); 3 int b = Integer.parseInt(args[1]); 4 } 5 6 public int add(int a, int b) { 7 return a + b; 8 } Change 1 Change 2
- 3. Why do wehave Source Control? 1 public static void main(String[] args) { 2 int a = Integer.parseInt(args[0]); 3 int b = Integer.parseInt(args[1]); 4 } 5 6 public int add(int a, int b) { 7 return a + b; 8 } 1 public static void main(String[] args) { 2 int a = Integer.parseInt(args[0]); 3 int b = Integer.parseInt(args[1]); 4 int c = a + b; 5 System.out.println(c + “”); 6 } 7 Person 1 Person 2
- 4. Why does conflictmatter? It resulted in branching strategies for: ● Protected the codebase ● Protected the environments ● Avoiding conflict ● Knowing what went where ● Being able to get back to a stable state All these strategies are varying degrees of wrong
- 5. Why Git? ● Itdominates the market ● Most all are conceptually similar ● It is probably what you are already using
- 6.
- 7. Cloning 1 public staticvoid main(String[] args) { 2 int a = Integer.parseInt(args[0]); 3 int b = Integer.parseInt(args[1]); 4 } 1 public static void main(String[] args) { 2 int a = Integer.parseInt(args[0]); 3 int b = Integer.parseInt(args[1]); 4 } 5 6 public int add(int a, int b) { 7 return a + b; 8 } clone master (remote) master (working) File System
- 8. Commit and Push clone master(remote) master (working) File System commit push
- 9.
- 10.
- 11.
- 12.
- 13.
- 14. Branches for codebaseprotection Purpose Severity Solutions From Developers Very Bad - Fire them, hire better - Automate standards (SCA, testing, SAST) From Other Teams Bad - Consider Pull Requests - Ban habitual offenders - Automate standards (SCA, testing, SAST) - Should this be its own component? - Should you be on the same team? From malicious actors Bad - Automate standards (SCA, testing, SAST) - Using tagging associated with releases From all developers Very Bad - DevOps
- 15. Branches for envprotection Purpose Severity Solutions From breakage Questionable - Decouple deploy from source - Test automation - Deploy automation From developers Very Bad - DevOps - Deploy automation From change Very Bad - Don’t
- 16. Branches to avoidconflict ...is always wrong
- 17. Branches to knowwhat went where ...is always unnecessary master commit a000 commit b111 commit c222 Tag: 1.0.1 Tag: 1.0.2 Tag: PROD Tag: 1.0.3 Tag: STAGE
- 18. Branches to knowthe stable state ...is always unnecessary master commit a000 commit b111 commit c222 Tag: 1.0.1 Tag: 1.0.2 Tag: PROD Tag: 1.0.3 Tag: STAGE
Editor's Notes
- #3 1.A way to keep track of incremental changes 2.Every change is a record unto itself 3.Stores that history in a central location 4.A common means of making code changes
- #4 1.Why do we have source control? 2.Because two people need to change the file around the same time 3.The result is conflict
- #5 1.I need to protect the codebase from the developers 2.I need to tie branches with environments so that I can protect them 3.We can’t have devs merging their own code, so we need them to avoid this 4.We need to use branches so that we know what goes into each environment 5.We need to be able to quickly get back into a stable state when it all goes wrong 6.Understanding why these strategies are wrong first requires knowledge about how source control works
- #7 1.An entire codebase is store at a remote location 2.Individual developers have their own local copies of that same repository 3.They push changes to that central repository, and pull changes made by other developers to it
- #8 1.When you clone, you are creating a local (working) copy from a remote location 2.On top of your local copy, is your own file system representation of that project 3.Any changes you make just remain on your file system, and don’t go into your working branch or get merged into the remote branch without explicit action
- #9 1.The only way your changes to into the working branch is via commit 2.You push your working branch into the remove branch via push
- #10 1.Master/main/mainline represents the true source 2.Each branch is a copy of the mainline at the time it is created 3.Work occurs on a branch without impacting the source branch
- #11 1.The underlying intention is to merge dev-1 back into master 2.This is best done via a Pull request, which acts like a temporary branch off of master that represents a merger of the two code bases 3.PRs can be merged automatically or require various approvals and other checks prior to be merged. 4.Another option is to either close the original branch, or leave it open
- #12 1.We have a manual approval 2.We are deleting the source branch after merger
- #15 1.Developers – The story about my first “DevOps” meeting at a new company, where it was stated “we don’t’ trust our developers” 2.Teams – This is a process, architecture, and automation problem 3.Bad actors – Very rare, but that is why tools exist. Otherwise just go back to a tagged release 4.RM in bad practice – the story
- #16 1.Env branching is generally a workaround because of a lack of automation 2.As a developer, I don’t write code that I don’t deploy. Integration and deployment is half the work. 3.The purpose of an environment is to change, so this is impossible
- #17 1.You are always just delaying the same conflict 2.Instead of dealing with them one at a time, you now have dozens and maybe even hundreds 3.This is known as anti-CI
- #18 1.Using branches to represent release is a holdover from older SCM systems like CVS and SVN 2.Tagging is your friend, because it can be used to track both what is releasable and where it was released to 3.Consider that tags are not specific to branch, but commit, which means they can be from anywhere 4.This is a key strategy when considering how to decouple coding from release
- #19 Just like last slide