Git is a distributed version control system, created by Linus Torvalds, and used worldwide by many software developers for a large number of well known software projects.
In this presentation, I explain the fundamentals of the Git software and some of its internal workings and related terminology. The target audience is individuals who have used Git before in a limited capacity and want expand their knowledge of the software to improve their daily use of it. The presentation could also be useful for those with knowledge of Git and a desire to improve their understanding of some of the more technically elements.
Git is a distributed version control system designed and developed by Linus Torvalds for Linux kernel development. It allows for distributed workflows where developers have full control over their local copy of the codebase. Git uses a three-tree model with the workspace, staging area, and local repository to track changes to files. Common Git commands allow users to initialize repositories, add and commit files, create and switch between branches, merge code from different branches, and collaborate remotely through fetching, pulling and pushing changes.
The document shows how to create a subdirectory in a Git repository by generating a blob object for a new file "d.txt", adding it to the index, and writing the updated index contents to a new tree object. This represents the contents of the repository as a set of blob and tree objects that can be retrieved and assembled to reconstruct the file contents and directory structure.
Git, the widely popular version control tool that just about everyone who works on the web seems to use, is powerful, scalable, flexible. . .and difficult to learn. If you’ve used Git for any amount of time, you’ve probably gotten yourself into some confusing, frustrating, or downright terrifying situations. But don’t panic. You are not alone. Katie Sylor-Miller explains how to avoid getting into Git messes in the first place, demonstrating how the fundamental structures in Git actually work under the hood and sharing best practices, workflows, and tools that will keep your commits in order and reduce the panic caused by merge conflicts. Katie then shows you how to leverage Git’s powerful features to save yourself when everything seems to go wrong.
A Beginner's Guide to Git and GitHub, CLI version.
What is Git?
What is Github
Basic commands
Difference between Central and Distributed Version Controlling System
Git is a distributed version control system, created by Linus Torvalds, and used worldwide by many software developers for a large number of well known software projects.
In this presentation, I explain the fundamentals of the Git software and some of its internal workings and related terminology. The target audience is individuals who have used Git before in a limited capacity and want expand their knowledge of the software to improve their daily use of it. The presentation could also be useful for those with knowledge of Git and a desire to improve their understanding of some of the more technically elements.
Git is a distributed version control system designed and developed by Linus Torvalds for Linux kernel development. It allows for distributed workflows where developers have full control over their local copy of the codebase. Git uses a three-tree model with the workspace, staging area, and local repository to track changes to files. Common Git commands allow users to initialize repositories, add and commit files, create and switch between branches, merge code from different branches, and collaborate remotely through fetching, pulling and pushing changes.
The document shows how to create a subdirectory in a Git repository by generating a blob object for a new file "d.txt", adding it to the index, and writing the updated index contents to a new tree object. This represents the contents of the repository as a set of blob and tree objects that can be retrieved and assembled to reconstruct the file contents and directory structure.
Git, the widely popular version control tool that just about everyone who works on the web seems to use, is powerful, scalable, flexible. . .and difficult to learn. If you’ve used Git for any amount of time, you’ve probably gotten yourself into some confusing, frustrating, or downright terrifying situations. But don’t panic. You are not alone. Katie Sylor-Miller explains how to avoid getting into Git messes in the first place, demonstrating how the fundamental structures in Git actually work under the hood and sharing best practices, workflows, and tools that will keep your commits in order and reduce the panic caused by merge conflicts. Katie then shows you how to leverage Git’s powerful features to save yourself when everything seems to go wrong.
A Beginner's Guide to Git and GitHub, CLI version.
What is Git?
What is Github
Basic commands
Difference between Central and Distributed Version Controlling System
This document provides an overview of Git version control system commands and concepts for beginners. It covers installing Git, initializing and cloning repositories, tracking changes with add, commit and push, branching and merging, resolving conflicts, and more. Key points include that Git is a distributed version control system that stores snapshots rather than file changes, and commands like status, diff, log, branch, merge and rebase to manage code history and integrate changes.
A Git Workflow is a recipe or recommendation for how to use Git to accomplish work in a consistent and productive manner. Git workflows encourage users to leverage Git effectively and consistently.
Check out this highlight training from the Automat-IT University trainers.
This document provides an introduction to using Git. Some key points:
- Git is a distributed version control system that is different from CVS/SVN in that nearly every operation is local and Git stores snapshots of files rather than differences.
- The basics of using Git involve recording changes by checking status, adding files, committing changes, and working with remotes like origin.
- Additional topics covered include undoing changes, working with others through branching and merging, tagging versions, and using tools like interactive mode and stashing.
Diapositivas de la charla dada por la gente de uno21.com.ar (@luke_ar y @matitanio) en la UP, el día 21/08/2012. Próximamente en otras universidades :)
The document provides an overview of common Git commands organized into categories like init/clone, add/commit, branch, log, diff/blame, undo/revert, merge/rebase, remote operations and more. It also includes explanations of concepts like the three main areas in Git (working directory, staging area, HEAD), and tips like using fetch instead of pull and following a forking workflow. The document is intended to teach attendees the essentials of using Git through explaining commands and best practices.
GIT is a distributed version control system that allows for collaboration by keeping track of changes made to source code over time. It keeps snapshots of files and allows users to work offline or disconnected from servers. Unlike centralized systems, GIT considers data as snapshots of files rather than file-based changes, and each user has a full copy of the repository. Users can commit changes to their local repository and then push them to remote repositories. Common commands include add, commit, push, pull, branch, merge, and status.
This document provides an overview of using Git like a pro. It begins with introducing the author and stating goals of increasing Git understanding, solving cumbersome situations, producing cleaner Git history, and having fun. It then covers key Git concepts like objects, references, branches, HEAD, merging vs rebasing, interactive rebasing, rerere, and how to use reset, reflog, and bisect commands to troubleshoot issues. The document emphasizes hands-on learning through examples and encourages experimenting in the provided Gitlab repository.
Excerpt from slides used in undergraduate software engineering lectures.
Our favorite git tricks, git commands and utilities that make working with git easier.
Updated June 2015.
This document provides an overview of version control systems and demonstrates how to use the version control system Git. It begins by explaining why version control is useful, especially for software projects. It then demonstrates the basic commands and workflows for initializing a Git repository, tracking files, committing changes, and pushing commits to a remote repository like GitHub. The document also covers branching, merging, resolving conflicts, and undoing changes. It provides explanations for various Git commands like add, commit, status, log, diff, reset, checkout, revert, fetch and more.
Do you know the basics of Git but wonder what all the hype is about? Do you want the ultimate control over your Git history? This tutorial will walk you through the basics of committing changes before diving into the more advanced and "dangerous" Git commands.
Git is an open source, distributed version control system used to track many different projects. You can use it to manage anything from a personal notes directory to a multi-programmer project.
This tutorial provides a short walk through of basic git commands and the Git philosophy to project management. Then we’ll dive into an exploration of the more advanced and “dangerous” Git commands. Watch as we rewrite our repository history, track bugs down to a specific commit, and untangle commits into an LKML-worthy patchset.
Git is a distributed version control system created by Linus Torvalds in 2005. It allows for non-linear development through features like branching and distributed collaboration. Git tracks content and file changes rather than file differences. The basic Git workflow involves initializing a repository, making changes to files, staging files, and committing changes with log messages. Files and changes can be shared between collaborators by adding remote repositories and pushing/pulling changes. Branches allow parallel development while merges integrate that work.
A Git tutorial for rookies that covers most aspects of basic Git usage for a medium sized project.
This was originally a semestral lecture given at the TU Wien for the course "Software Engineering and Project Management"
The document discusses the three main states that code can be in with Git: unmodified, staged, and committed. It explains how to use commands like git add, git commit, git status, and git diff to transition code between these states and view changes. It also covers branching, merging, rebasing and rewriting history with commands like git branch, git merge, git rebase and git reset.
The document provides good practices for using Git, including forking repositories, cloning, adding remote repositories, fetching from remotes, committing changes locally, rebasing, and pushing changes to remote repositories. It also discusses the differences between rebasing and pulling from a remote when integrating changes.
Git 101 Presentation
The presentation introduces Git version control system including:
[1] An overview of version control systems and the basics of Git such as snapshots, local operations, and three main states of files.
[2] A comparison of features between Git and SVN such as distributed development and branching workflows.
[3] Instructions on setting up Git locally and with GitHub, and basic commands for creating and managing repositories, branches, commits, and merges.
This document provides an introduction to Git and GitHub. It begins with an overview of source control and the history of version control systems like SVN and CVS. It then discusses key concepts of Git like its three-tree architecture, branches and merging, and undoing changes. The document concludes with an introduction to GitHub, how to clone and collaborate on repositories, and some tips on reducing merge conflicts.
This document provides an overview of version control systems including Mercurial and Git. It describes the basic commands and workflows for these distributed version control systems. Key features covered include initializing repositories, cloning, committing, branching, merging, resolving conflicts and using remote repositories over HTTP or SSH. The document also lists configuration files and public hosting services for these tools.
After talking to several Drupal followers during our last meetup, I realised quite a few people still don't employ version control.
I strongly consider this best practice when building a site, and thought it would be a good opportunity to go over its importance and how you can make it work for you.
Git offers several advantages:
• It's super fast
• It's easy.
• And no you don't need to be familiar with Command Line code (there are several great GUI's out there).
GIT Version Control works by keeping track of all successive changes you make to a site.
The biggest advantage of this is easily undoing any mistakes you might make along the way.
It's a great feeling to know Version Control has your back that you can roll back if something goes catastrophically wrong.
It's also a big bonus in collaborative development.
As soon as more than one person works on a project things get a lot more complicated.
What happens when 2 edits effect the same file? How do you know what's new, what's old and what's changed?
No worries, simply merge the variations and let GIT deal with the rest.
GIT is not just for the developers of this world but can be a life saver for themers, site maintainers and the like.
Most people will admit they should use it, but either don't know how or believe it's hard to integrate.
The reality is that it's actually pretty simple and once you start integrating GIT into your workflow you'll ask yourself "Why the hell did I keep using ftp" - I know I did.
FTP is so yesterday, its slow, it's cumbersome to use and it's a very manual method.
Switch to GIT, start using GIT, and never look back.
This document provides an overview of Git and GitHub for code versioning and sharing. It discusses key Git concepts like branches, commits, and merges. It also demonstrates how to perform basic Git commands from the command line interface. GitHub is presented as a tool for easy collaboration on Git projects through features like forking and pull requests. Overall the document serves as an introduction to using Git and GitHub for researchers and code sharing.
This document provides an overview of various Git commands, workflows, and best practices. It covers the basics of initializing repositories, committing, branching, merging, tagging, undoing changes, and working with remotes. It also summarizes several common Git workflows including centralized, feature branching, Gitflow, and forking models. Best practices around aliases, ignoring files, log formatting, and branching strategies are also outlined.
- Git stores snapshots of files and file trees in commits rather than tracking differences between file versions. This allows it to be very efficient and perform well on large projects.
- Git is highly local - all operations can be performed offline and it stores its data locally rather than relying on remote servers like many other version control systems.
- Git has strong integrity checks built-in to ensure data integrity and detect unintended changes to files.
This document provides an overview of Git version control system commands and concepts for beginners. It covers installing Git, initializing and cloning repositories, tracking changes with add, commit and push, branching and merging, resolving conflicts, and more. Key points include that Git is a distributed version control system that stores snapshots rather than file changes, and commands like status, diff, log, branch, merge and rebase to manage code history and integrate changes.
A Git Workflow is a recipe or recommendation for how to use Git to accomplish work in a consistent and productive manner. Git workflows encourage users to leverage Git effectively and consistently.
Check out this highlight training from the Automat-IT University trainers.
This document provides an introduction to using Git. Some key points:
- Git is a distributed version control system that is different from CVS/SVN in that nearly every operation is local and Git stores snapshots of files rather than differences.
- The basics of using Git involve recording changes by checking status, adding files, committing changes, and working with remotes like origin.
- Additional topics covered include undoing changes, working with others through branching and merging, tagging versions, and using tools like interactive mode and stashing.
Diapositivas de la charla dada por la gente de uno21.com.ar (@luke_ar y @matitanio) en la UP, el día 21/08/2012. Próximamente en otras universidades :)
The document provides an overview of common Git commands organized into categories like init/clone, add/commit, branch, log, diff/blame, undo/revert, merge/rebase, remote operations and more. It also includes explanations of concepts like the three main areas in Git (working directory, staging area, HEAD), and tips like using fetch instead of pull and following a forking workflow. The document is intended to teach attendees the essentials of using Git through explaining commands and best practices.
GIT is a distributed version control system that allows for collaboration by keeping track of changes made to source code over time. It keeps snapshots of files and allows users to work offline or disconnected from servers. Unlike centralized systems, GIT considers data as snapshots of files rather than file-based changes, and each user has a full copy of the repository. Users can commit changes to their local repository and then push them to remote repositories. Common commands include add, commit, push, pull, branch, merge, and status.
This document provides an overview of using Git like a pro. It begins with introducing the author and stating goals of increasing Git understanding, solving cumbersome situations, producing cleaner Git history, and having fun. It then covers key Git concepts like objects, references, branches, HEAD, merging vs rebasing, interactive rebasing, rerere, and how to use reset, reflog, and bisect commands to troubleshoot issues. The document emphasizes hands-on learning through examples and encourages experimenting in the provided Gitlab repository.
Excerpt from slides used in undergraduate software engineering lectures.
Our favorite git tricks, git commands and utilities that make working with git easier.
Updated June 2015.
This document provides an overview of version control systems and demonstrates how to use the version control system Git. It begins by explaining why version control is useful, especially for software projects. It then demonstrates the basic commands and workflows for initializing a Git repository, tracking files, committing changes, and pushing commits to a remote repository like GitHub. The document also covers branching, merging, resolving conflicts, and undoing changes. It provides explanations for various Git commands like add, commit, status, log, diff, reset, checkout, revert, fetch and more.
Do you know the basics of Git but wonder what all the hype is about? Do you want the ultimate control over your Git history? This tutorial will walk you through the basics of committing changes before diving into the more advanced and "dangerous" Git commands.
Git is an open source, distributed version control system used to track many different projects. You can use it to manage anything from a personal notes directory to a multi-programmer project.
This tutorial provides a short walk through of basic git commands and the Git philosophy to project management. Then we’ll dive into an exploration of the more advanced and “dangerous” Git commands. Watch as we rewrite our repository history, track bugs down to a specific commit, and untangle commits into an LKML-worthy patchset.
Git is a distributed version control system created by Linus Torvalds in 2005. It allows for non-linear development through features like branching and distributed collaboration. Git tracks content and file changes rather than file differences. The basic Git workflow involves initializing a repository, making changes to files, staging files, and committing changes with log messages. Files and changes can be shared between collaborators by adding remote repositories and pushing/pulling changes. Branches allow parallel development while merges integrate that work.
A Git tutorial for rookies that covers most aspects of basic Git usage for a medium sized project.
This was originally a semestral lecture given at the TU Wien for the course "Software Engineering and Project Management"
The document discusses the three main states that code can be in with Git: unmodified, staged, and committed. It explains how to use commands like git add, git commit, git status, and git diff to transition code between these states and view changes. It also covers branching, merging, rebasing and rewriting history with commands like git branch, git merge, git rebase and git reset.
The document provides good practices for using Git, including forking repositories, cloning, adding remote repositories, fetching from remotes, committing changes locally, rebasing, and pushing changes to remote repositories. It also discusses the differences between rebasing and pulling from a remote when integrating changes.
Git 101 Presentation
The presentation introduces Git version control system including:
[1] An overview of version control systems and the basics of Git such as snapshots, local operations, and three main states of files.
[2] A comparison of features between Git and SVN such as distributed development and branching workflows.
[3] Instructions on setting up Git locally and with GitHub, and basic commands for creating and managing repositories, branches, commits, and merges.
This document provides an introduction to Git and GitHub. It begins with an overview of source control and the history of version control systems like SVN and CVS. It then discusses key concepts of Git like its three-tree architecture, branches and merging, and undoing changes. The document concludes with an introduction to GitHub, how to clone and collaborate on repositories, and some tips on reducing merge conflicts.
This document provides an overview of version control systems including Mercurial and Git. It describes the basic commands and workflows for these distributed version control systems. Key features covered include initializing repositories, cloning, committing, branching, merging, resolving conflicts and using remote repositories over HTTP or SSH. The document also lists configuration files and public hosting services for these tools.
After talking to several Drupal followers during our last meetup, I realised quite a few people still don't employ version control.
I strongly consider this best practice when building a site, and thought it would be a good opportunity to go over its importance and how you can make it work for you.
Git offers several advantages:
• It's super fast
• It's easy.
• And no you don't need to be familiar with Command Line code (there are several great GUI's out there).
GIT Version Control works by keeping track of all successive changes you make to a site.
The biggest advantage of this is easily undoing any mistakes you might make along the way.
It's a great feeling to know Version Control has your back that you can roll back if something goes catastrophically wrong.
It's also a big bonus in collaborative development.
As soon as more than one person works on a project things get a lot more complicated.
What happens when 2 edits effect the same file? How do you know what's new, what's old and what's changed?
No worries, simply merge the variations and let GIT deal with the rest.
GIT is not just for the developers of this world but can be a life saver for themers, site maintainers and the like.
Most people will admit they should use it, but either don't know how or believe it's hard to integrate.
The reality is that it's actually pretty simple and once you start integrating GIT into your workflow you'll ask yourself "Why the hell did I keep using ftp" - I know I did.
FTP is so yesterday, its slow, it's cumbersome to use and it's a very manual method.
Switch to GIT, start using GIT, and never look back.
This document provides an overview of Git and GitHub for code versioning and sharing. It discusses key Git concepts like branches, commits, and merges. It also demonstrates how to perform basic Git commands from the command line interface. GitHub is presented as a tool for easy collaboration on Git projects through features like forking and pull requests. Overall the document serves as an introduction to using Git and GitHub for researchers and code sharing.
This document provides an overview of various Git commands, workflows, and best practices. It covers the basics of initializing repositories, committing, branching, merging, tagging, undoing changes, and working with remotes. It also summarizes several common Git workflows including centralized, feature branching, Gitflow, and forking models. Best practices around aliases, ignoring files, log formatting, and branching strategies are also outlined.
- Git stores snapshots of files and file trees in commits rather than tracking differences between file versions. This allows it to be very efficient and perform well on large projects.
- Git is highly local - all operations can be performed offline and it stores its data locally rather than relying on remote servers like many other version control systems.
- Git has strong integrity checks built-in to ensure data integrity and detect unintended changes to files.
This document provides an overview of Git and its basic commands for beginners. It covers installing Git, creating repositories on Bitbucket and GitHub, tracking changes with commands like add, commit, push, pull, and resolving merge conflicts. It also discusses branching, tagging, reverting changes, and ignoring files. Key concepts explained include distributed version control, staging changes, commit histories, and setting up aliases and submodules.
This document provides an overview of various Git commands and concepts covered in an intermediate Git course, including:
1. Stashing changes, viewing commit logs, checking the HEAD pointer, viewing differences between files and the repository, removing and ignoring files, and undoing changes.
2. Commands for branching like creating, deleting, renaming branches and checking out branches.
3. Merging branches and resolving conflicts that can occur during merges. Strategies discussed for reducing conflicts include keeping commits focused and small, merging often, and tracking changes to the master branch.
This document provides an overview of Git and Git Flow for version control. It defines key Git concepts like version control systems, distributed version control, and the benefits of Git over centralized systems. It also explains the branches and workflow in Git Flow, including features, releases, hotfixes and using branches to independently develop features before merging into develop or master. The document concludes with some advanced Git techniques like bisecting to find broken commits, cherry-picking commits, using .gitignore files, and blame to identify who last changed a file.
The document provides an introduction and overview of Git. It begins with an introduction of the presenter and then asks poll questions to gauge who is and isn't using source code management systems. It then proceeds to explain what Git is, why it's useful, how to configure and set up a Git repository, how to add and commit changes, create and switch branches, undo changes, and work with remote repositories and resolve conflicts.
Version control systems (VCS) like Git allow software teams to track changes to source code over time. Git is a distributed VCS that provides local repositories for each developer and allows easy branching and merging. Developers can commit changes to the local repository and push them to the remote repository to share code with the team.
This document provides an introduction to using Git. It covers getting Git, creating repositories, staging and committing files, branching, merging, and pushing and pulling changes. The presenter provides exercises for attendees to practice the basic Git commands and workflows. They discuss normal repositories, bare repositories, cloning repositories, viewing logs and commits, configuring user information, amending commits, removing files, branching, merging, pushing changes to a remote repository, and pulling changes from remote.
This document provides a summary of Git in 10 minutes. It begins with an overview and breakdown of the content which includes explanations of what Git is, how it works, the GitHub flow, frequently used commands, confusions around undoing changes, and useful links. The body then delves into each section providing more details on Distributed version control, local vs remote operations, the GitHub flow process, example commands for undoing changes, and resources for additional learning.
Git is a distributed version control system that allows developers to work independently and asynchronously on features or bug fixes through branches. Branches allow developers to commit changes frequently without disrupting the main codebase. If a branch is ready, a developer can merge the branch back into the main branch. Git also uses a commit and diff system to track changes at a file level, making it easy to revert changes or roll back to previous versions if needed. The distributed nature of Git provides advantages over centralized systems like SVN by allowing independent repositories and easy conflict resolution during merges.
The document provides an overview of the basics of using Git for distributed version control. It discusses that Git allows for a fully functional local repository with remote repositories syncing changes. It outlines configuring Git and a basic workflow of cloning a repository, making changes, adding/committing files, and pushing changes. It also summarizes key Git commands like add, commit, branching, merging, resolving conflicts, and rebasing.
Git allows for local operations and easy recovery from mistakes. It tracks files in three main states: unmodified, staged for commit, and committed. Users can view file histories, differences between versions, and roll back changes. Branches enable parallel development and merging changes. Remote repositories allow sharing and collaboration through fetch, pull, and push operations.
Git is a distributed version control system that allows developers to work on codebases simultaneously and merge changes easily. It uses a local repository that can be synced to remote repositories hosted on services like GitHub. Developers clone repositories, make changes on branches, commit locally, and push updates to the remote. Git addresses issues like file locking and enables features like easy merging and reverting changes. Stashing is used to temporarily store uncommitted changes when switching branches. GUI clients and documentation on sites like GitHub help users learn and use Git's powerful capabilities for collaboration.
This document provides an overview of Git and Gitflow. It explains that Git is a distributed version control system (DVCS) that allows tracking changes to files, committing changes locally and to remote repositories, and reverting changes. It also describes the basic Git commands for initializing and cloning repositories, making commits, branching, merging, and resolving conflicts. Finally, it introduces Gitflow workflow which defines main and supporting branches to support parallel development and releases in a project.
Git is a distributed version control system that allows users to track changes to files and collaborate with others. It maintains a database of snapshots of files and allows users to commit changes, compare changes between versions, and collaborate through a remote server. Some key aspects of Git include its use of snapshots rather than file differences, its local operations that add data, and its three stages of files - the working directory, staging area, and Git directory.
This document discusses Git tips and best practices, including:
- Git is a distributed version control system designed for speed, integrity and distributed workflows. It stores snapshots of project files rather than file differences.
- Merging incorporates changes from one branch into another but leaves an extra merge commit, while rebasing replays changes to a new base and cleans up history.
- A successful Git branching model uses main branches like master and develop, and supporting branches like features, releases and hotfixes to integrate work.
This document provides an introduction and overview of Git and GitHub. It discusses version control systems and the differences between centralized and distributed version control. Key Git concepts and commands are explained such as configuring Git, creating repositories, adding and committing files, branches, pulling and pushing changes. GitHub is introduced as a platform for hosting Git repositories and collaborating on projects. The document provides instructions for adding collaborators to a GitHub repository.
Git is a version control system for tracking changes in computer files and coordinating work on those files among multiple people.
This PPT describes most used commands.
Git is a free and open source distributed version control system that allows for easy branching and merging. It was created by Linus Torvalds in 2005 to manage development of the Linux kernel. Git allows developers to work independently on their own branches and then merge changes together later. Common Git commands include git add to stage files, git commit to commit changes locally, and git push to publish commits to a remote repository. More advanced commands include git branch to create and switch branches, and git merge to integrate branch changes.
This document is a cheat sheet for the Git commands covered in Mosh Hamedani's Ultimate Git Mastery course. It includes sections on creating snapshots, browsing history, branching and merging, collaboration using Git and GitHub, and rewriting history. The cheat sheet provides descriptions and examples for essential Git commands.
Similar to Pro git - grasping it conceptually (20)
Skybuffer SAM4U tool for SAP license adoptionTatiana Kojar
Manage and optimize your license adoption and consumption with SAM4U, an SAP free customer software asset management tool.
SAM4U, an SAP complimentary software asset management tool for customers, delivers a detailed and well-structured overview of license inventory and usage with a user-friendly interface. We offer a hosted, cost-effective, and performance-optimized SAM4U setup in the Skybuffer Cloud environment. You retain ownership of the system and data, while we manage the ABAP 7.58 infrastructure, ensuring fixed Total Cost of Ownership (TCO) and exceptional services through the SAP Fiori interface.
GraphRAG for Life Science to increase LLM accuracyTomaz Bratanic
GraphRAG for life science domain, where you retriever information from biomedical knowledge graphs using LLMs to increase the accuracy and performance of generated answers
In the rapidly evolving landscape of technologies, XML continues to play a vital role in structuring, storing, and transporting data across diverse systems. The recent advancements in artificial intelligence (AI) present new methodologies for enhancing XML development workflows, introducing efficiency, automation, and intelligent capabilities. This presentation will outline the scope and perspective of utilizing AI in XML development. The potential benefits and the possible pitfalls will be highlighted, providing a balanced view of the subject.
We will explore the capabilities of AI in understanding XML markup languages and autonomously creating structured XML content. Additionally, we will examine the capacity of AI to enrich plain text with appropriate XML markup. Practical examples and methodological guidelines will be provided to elucidate how AI can be effectively prompted to interpret and generate accurate XML markup.
Further emphasis will be placed on the role of AI in developing XSLT, or schemas such as XSD and Schematron. We will address the techniques and strategies adopted to create prompts for generating code, explaining code, or refactoring the code, and the results achieved.
The discussion will extend to how AI can be used to transform XML content. In particular, the focus will be on the use of AI XPath extension functions in XSLT, Schematron, Schematron Quick Fixes, or for XML content refactoring.
The presentation aims to deliver a comprehensive overview of AI usage in XML development, providing attendees with the necessary knowledge to make informed decisions. Whether you’re at the early stages of adopting AI or considering integrating it in advanced XML development, this presentation will cover all levels of expertise.
By highlighting the potential advantages and challenges of integrating AI with XML development tools and languages, the presentation seeks to inspire thoughtful conversation around the future of XML development. We’ll not only delve into the technical aspects of AI-powered XML development but also discuss practical implications and possible future directions.
How to Interpret Trends in the Kalyan Rajdhani Mix Chart.pdfChart Kalyan
A Mix Chart displays historical data of numbers in a graphical or tabular form. The Kalyan Rajdhani Mix Chart specifically shows the results of a sequence of numbers over different periods.
Trusted Execution Environment for Decentralized Process MiningLucaBarbaro3
Presentation of the paper "Trusted Execution Environment for Decentralized Process Mining" given during the CAiSE 2024 Conference in Cyprus on June 7, 2024.
Monitoring and Managing Anomaly Detection on OpenShift.pdfTosin Akinosho
Monitoring and Managing Anomaly Detection on OpenShift
Overview
Dive into the world of anomaly detection on edge devices with our comprehensive hands-on tutorial. This SlideShare presentation will guide you through the entire process, from data collection and model training to edge deployment and real-time monitoring. Perfect for those looking to implement robust anomaly detection systems on resource-constrained IoT/edge devices.
Key Topics Covered
1. Introduction to Anomaly Detection
- Understand the fundamentals of anomaly detection and its importance in identifying unusual behavior or failures in systems.
2. Understanding Edge (IoT)
- Learn about edge computing and IoT, and how they enable real-time data processing and decision-making at the source.
3. What is ArgoCD?
- Discover ArgoCD, a declarative, GitOps continuous delivery tool for Kubernetes, and its role in deploying applications on edge devices.
4. Deployment Using ArgoCD for Edge Devices
- Step-by-step guide on deploying anomaly detection models on edge devices using ArgoCD.
5. Introduction to Apache Kafka and S3
- Explore Apache Kafka for real-time data streaming and Amazon S3 for scalable storage solutions.
6. Viewing Kafka Messages in the Data Lake
- Learn how to view and analyze Kafka messages stored in a data lake for better insights.
7. What is Prometheus?
- Get to know Prometheus, an open-source monitoring and alerting toolkit, and its application in monitoring edge devices.
8. Monitoring Application Metrics with Prometheus
- Detailed instructions on setting up Prometheus to monitor the performance and health of your anomaly detection system.
9. What is Camel K?
- Introduction to Camel K, a lightweight integration framework built on Apache Camel, designed for Kubernetes.
10. Configuring Camel K Integrations for Data Pipelines
- Learn how to configure Camel K for seamless data pipeline integrations in your anomaly detection workflow.
11. What is a Jupyter Notebook?
- Overview of Jupyter Notebooks, an open-source web application for creating and sharing documents with live code, equations, visualizations, and narrative text.
12. Jupyter Notebooks with Code Examples
- Hands-on examples and code snippets in Jupyter Notebooks to help you implement and test anomaly detection models.
Building Production Ready Search Pipelines with Spark and MilvusZilliz
Spark is the widely used ETL tool for processing, indexing and ingesting data to serving stack for search. Milvus is the production-ready open-source vector database. In this talk we will show how to use Spark to process unstructured data to extract vector representations, and push the vectors to Milvus vector database for search serving.
Programming Foundation Models with DSPy - Meetup SlidesZilliz
Prompting language models is hard, while programming language models is easy. In this talk, I will discuss the state-of-the-art framework DSPy for programming foundation models with its powerful optimizers and runtime constraint system.
HCL Notes and Domino License Cost Reduction in the World of DLAUpanagenda
Webinar Recording: https://www.panagenda.com/webinars/hcl-notes-and-domino-license-cost-reduction-in-the-world-of-dlau/
The introduction of DLAU and the CCB & CCX licensing model caused quite a stir in the HCL community. As a Notes and Domino customer, you may have faced challenges with unexpected user counts and license costs. You probably have questions on how this new licensing approach works and how to benefit from it. Most importantly, you likely have budget constraints and want to save money where possible. Don’t worry, we can help with all of this!
We’ll show you how to fix common misconfigurations that cause higher-than-expected user counts, and how to identify accounts which you can deactivate to save money. There are also frequent patterns that can cause unnecessary cost, like using a person document instead of a mail-in for shared mailboxes. We’ll provide examples and solutions for those as well. And naturally we’ll explain the new licensing model.
Join HCL Ambassador Marc Thomas in this webinar with a special guest appearance from Franz Walder. It will give you the tools and know-how to stay on top of what is going on with Domino licensing. You will be able lower your cost through an optimized configuration and keep it low going forward.
These topics will be covered
- Reducing license cost by finding and fixing misconfigurations and superfluous accounts
- How do CCB and CCX licenses really work?
- Understanding the DLAU tool and how to best utilize it
- Tips for common problem areas, like team mailboxes, functional/test users, etc
- Practical examples and best practices to implement right away
Main news related to the CCS TSI 2023 (2023/1695)Jakub Marek
An English 🇬🇧 translation of a presentation to the speech I gave about the main changes brought by CCS TSI 2023 at the biggest Czech conference on Communications and signalling systems on Railways, which was held in Clarion Hotel Olomouc from 7th to 9th November 2023 (konferenceszt.cz). Attended by around 500 participants and 200 on-line followers.
The original Czech 🇨🇿 version of the presentation can be found here: https://www.slideshare.net/slideshow/hlavni-novinky-souvisejici-s-ccs-tsi-2023-2023-1695/269688092 .
The videorecording (in Czech) from the presentation is available here: https://youtu.be/WzjJWm4IyPk?si=SImb06tuXGb30BEH .
Taking AI to the Next Level in Manufacturing.pdfssuserfac0301
Read Taking AI to the Next Level in Manufacturing to gain insights on AI adoption in the manufacturing industry, such as:
1. How quickly AI is being implemented in manufacturing.
2. Which barriers stand in the way of AI adoption.
3. How data quality and governance form the backbone of AI.
4. Organizational processes and structures that may inhibit effective AI adoption.
6. Ideas and approaches to help build your organization's AI strategy.
TrustArc Webinar - 2024 Global Privacy SurveyTrustArc
How does your privacy program stack up against your peers? What challenges are privacy teams tackling and prioritizing in 2024?
In the fifth annual Global Privacy Benchmarks Survey, we asked over 1,800 global privacy professionals and business executives to share their perspectives on the current state of privacy inside and outside of their organizations. This year’s report focused on emerging areas of importance for privacy and compliance professionals, including considerations and implications of Artificial Intelligence (AI) technologies, building brand trust, and different approaches for achieving higher privacy competence scores.
See how organizational priorities and strategic approaches to data security and privacy are evolving around the globe.
This webinar will review:
- The top 10 privacy insights from the fifth annual Global Privacy Benchmarks Survey
- The top challenges for privacy leaders, practitioners, and organizations in 2024
- Key themes to consider in developing and maintaining your privacy program
5th LF Energy Power Grid Model Meet-up SlidesDanBrown980551
5th Power Grid Model Meet-up
It is with great pleasure that we extend to you an invitation to the 5th Power Grid Model Meet-up, scheduled for 6th June 2024. This event will adopt a hybrid format, allowing participants to join us either through an online Mircosoft Teams session or in person at TU/e located at Den Dolech 2, Eindhoven, Netherlands. The meet-up will be hosted by Eindhoven University of Technology (TU/e), a research university specializing in engineering science & technology.
Power Grid Model
The global energy transition is placing new and unprecedented demands on Distribution System Operators (DSOs). Alongside upgrades to grid capacity, processes such as digitization, capacity optimization, and congestion management are becoming vital for delivering reliable services.
Power Grid Model is an open source project from Linux Foundation Energy and provides a calculation engine that is increasingly essential for DSOs. It offers a standards-based foundation enabling real-time power systems analysis, simulations of electrical power grids, and sophisticated what-if analysis. In addition, it enables in-depth studies and analysis of the electrical power grid’s behavior and performance. This comprehensive model incorporates essential factors such as power generation capacity, electrical losses, voltage levels, power flows, and system stability.
Power Grid Model is currently being applied in a wide variety of use cases, including grid planning, expansion, reliability, and congestion studies. It can also help in analyzing the impact of renewable energy integration, assessing the effects of disturbances or faults, and developing strategies for grid control and optimization.
What to expect
For the upcoming meetup we are organizing, we have an exciting lineup of activities planned:
-Insightful presentations covering two practical applications of the Power Grid Model.
-An update on the latest advancements in Power Grid -Model technology during the first and second quarters of 2024.
-An interactive brainstorming session to discuss and propose new feature requests.
-An opportunity to connect with fellow Power Grid Model enthusiasts and users.
Ivanti’s Patch Tuesday breakdown goes beyond patching your applications and brings you the intelligence and guidance needed to prioritize where to focus your attention first. Catch early analysis on our Ivanti blog, then join industry expert Chris Goettl for the Patch Tuesday Webinar Event. There we’ll do a deep dive into each of the bulletins and give guidance on the risks associated with the newly-identified vulnerabilities.
Unlock the Future of Search with MongoDB Atlas_ Vector Search Unleashed.pdfMalak Abu Hammad
Discover how MongoDB Atlas and vector search technology can revolutionize your application's search capabilities. This comprehensive presentation covers:
* What is Vector Search?
* Importance and benefits of vector search
* Practical use cases across various industries
* Step-by-step implementation guide
* Live demos with code snippets
* Enhancing LLM capabilities with vector search
* Best practices and optimization strategies
Perfect for developers, AI enthusiasts, and tech leaders. Learn how to leverage MongoDB Atlas to deliver highly relevant, context-aware search results, transforming your data retrieval process. Stay ahead in tech innovation and maximize the potential of your applications.
#MongoDB #VectorSearch #AI #SemanticSearch #TechInnovation #DataScience #LLM #MachineLearning #SearchTechnology
Letter and Document Automation for Bonterra Impact Management (fka Social Sol...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on automated letter generation for Bonterra Impact Management using Google Workspace or Microsoft 365.
Interested in deploying letter generation automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
Letter and Document Automation for Bonterra Impact Management (fka Social Sol...
Pro git - grasping it conceptually
1. Pro Git
Grasping it Conceptually
by Kim Seungwon
(seungzzang@gmail.com)
http://git-scm.com/
2. Grasping Git Conceptually - Part 1
Git Basics
● Git initial settings
● File Status Lifecycle
● Ignoring files
● Recording the changes to the Repo
● Viewing Commit History
● Basic Undoing and Remote Repo Commands
Git Branching
● What a Branch is
● Basic Branching and Merging
● Branch Commands
● Branching Workflows
● Remote Branches
● Rebasing
Git Server
● Protocol
● Building it
● Anonymous Read Access
● Access Control, Hosted Git
3. Grasping Git Conceptually - Part 2
Distributed Git
● Distributed Workflows
○ Centralized Workflows
○ Integration-Manager Workflow
○ Dictator and Lieutenants Workflow
● Contributing to a Project
○ Commit Guidelines
○ Private Small Team
○ Private Managed Team
○ Public Projects
● Maintaining a Project
○ Combining Works - Commands
○ Combining Works - Workflows
○ Cherry Picking
○ Tagging, Maintainer Public Key
○ Building Version Number and Source Tarball
Git Really Useful Tools
● Revision Selection
● Interactive Staging
● Stashing
● Rewriting History - Interactive Rebasing
● Debugging with Git - blame
● Debugging with Git - bisect
● Submodule
● Subtree
● Git and Subversion
4. Git Basics - The Way Git Stores History
Git initial settings
● /etc/gitconfig, --system
● ~/.gitconfig, --global
● .git/config, per repository
$ git config --global user.name "seungzzang"
$ git config --global user.email seungzzang@gmail.com
Thw Way Git Stores History : Snapshots, Not Differences
5. $ vim benchmarks.rb
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: README
# modified: benchmarks.rb
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
#
# modified: benchmarks.rb
#
Git Basics - File Status / Committed, Modified and Staged
6. Git Basics - Ignoring Files
Ignoring Files - .gitignore
● .gitignore
# a comment - this is ignored
# no .a files
*.a
# but do track lib.a, even though you're ignoring .a files above
!lib.a
# only ignore the root TODO file, not subdir/TODO
/TODO
# ignore all files in the build/ directory
build/
# ignore doc/notes.txt, but not doc/server/arch.txt
doc/*.txt
# ignore all .txt files in the doc/ directory
doc/**/*.txt : Git since version 1.8.2.
Viewing your staged and unstaged changes
● git diff, git diff --staged
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: README
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
#
# modified: benchmarks.rb
#
$ git diff
diff --git a/benchmarks.rb b/benchmarks.rb ...
$ git diff --cached
diff --git a/README b/README ...
7. Git Basics - Recording Changes to the Repo.
Committing changes
● git commit
● git commit -v (put the diff in the editor)
● git commit -m '...'
Skipping the Staging Area
● git commit -a -m 'Add new benchmarks'
Removing Files
● rm : Changes not staged for commit
● git rm : Changes to be commit
● git rm --cached readme.txt (remove it from staging area, don't track any
more)
Moving Files
● git mv file_from file_to
$ git mv README.txt README
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# renamed: README.txt -> README
#
$ mv README.txt README
$ git rm README.txt
$ git add README
8. git log
git log -p -2
git log --stat
git log --pretty=oneline
git log --pretty=format:"%h - %an, %ar : %s"
git log --pretty=format:"%h %s" --graph
git log --pretty="%h - %s" --author=gitster --since="2008-10-01" --before="2008-11-01" --no-merges -- t/
-p Show the patch introduced with each commit.
--word-diff Show the patch in a word diff format.
--stat Show statistics for files modified in each commit.
--shortstat Display only the changed/insertions/deletions line from the --stat command.
--name-only Show the list of files modified after the commit information.
--name-status Show the list of files affected with added/modified/deleted information as well.
--abbrev-commit Show only the first few characters of the SHA-1 checksum instead of all 40.
--relative-date Display the date in a relative format (for example, “2 weeks ago”) instead of
using the full date format.
--graph Display an ASCII graph of the branch and merge history beside the log output.
--pretty Show commits in an alternate format. Options include oneline, short, full,
fuller, and format (where you specify your own format).
--oneline A convenience option short for `--pretty=oneline --abbrev-commit`
git log -7 --pretty=format:"%h %s" --graph
git log -7 --pretty=oneline --abbrev-commit --graph
git log -7 --oneline --graph
Git Basics - Viewing Commit History
18. Git Branching - Basic Branching and Merging
● git checkout master
● git merge iss53
Git determines the best common ancestor to use for its merge base.
● git branch -d iss53
19. Git Branching - Basic Branching and Merging
● git merge iss53
$ git merge iss53
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
$ git status
index.html: needs merge
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# unmerged: index.html
#
vi index.html
<<<<<<< HEAD:index.html
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">
please contact us at support@github.com
</div>
>>>>>>> iss53:index.html
● git add index.html
● git commit
Merge branch 'iss53'
Conflicts:
index.html
#
# It looks like you may be committing a MERGE.
# If this is not correct, please remove the file
# .git/MERGE_HEAD
# and try again.
#
20. Git Branching - Branch Commands
● git branch
iss53
* master
testing
● git branch -v
iss53 93b412c fix javascript issue
* master 7a98805 Merge branch 'iss53'
testing 782fd34 add scott to the author list in the readmes
● git branch --merged
iss53 : can be deleted
* master
● git branch --no-merged
testing : can not be deleted
$ git branch -d testing
error: The branch 'testing' is not an ancestor of your current HEAD.
If you are sure you want to delete it, run 'git branch -D testing'.
You can't delete the branch which is not referenced by any other branches.
28. ● More interesting rebase
git rebase --onto master server client
● How to do fast-forward ?
Git Branching - Rebasing
29. ● git rebase <base_branch> <topic_branch>
git rebase master server
● git checkout master
git merge server
Git Branching - Rebasing
30. ● The perils of rebasing 1
Git Branching - Rebasing
31. ● The perils of rebasing 2
Do not rebase commits that you have pushed to a public repository.
Git Branching - Rebasing
same author and message
32. Git on the Server - Protocol
● Local protocol
○ git clone /opt/git/project.git : copy or hardlink
git clone file:///opt/git/project.git : seperate process
○ git pull /home/john/project
○ A local repository is fast only if you have fast access to the data.
○ Pro: You can run a command like git pull /home/john/project
○ Con: A repository on NFS is often slower than the repository over SSH.
● SSH protocol
○ git clone ssh://user@server/project.git = git clone user@server:project.git
○ You still need SSH for your own write commands.
○ Pros
● Authenticated write access to your repository over a network
● Easy to set up
● Access over SSH is secure — all data transfer is encrypted and authenticated
● SSH is efficient, making the data as compact as possible before transferring it
○ Cons
● Can’t serve anonymous access of your repository
● Git protocol
○ Special daemon that comes packaged with Git
○ The fastest transfer protocol available
○ The lack of authentication
○ Use git:// for read-only access
● HTTP/S protocol
○ Normally, It is used for read-only access. Easy to set up.
○ Git push over HTTP is rarely used and needs any WebDAV server.
○ Not very resource intensive on your server
○ Relatively inefficient for the client
33. Git on the Server - How to Make Git Server
● Clone bare repository
○ git clone --bare my_project my_project.git
== cp -Rf my_project/.git my_project.git
● Putting the bare repository on a Server
○ scp -r my_project.git user@git.example.com:/opt/git
● git account
○ ~/.ssh/authorized_keys
● SSH public key
○ ls -alt ~/.ssh
○ ssh-keygen
○ send email with id_rsa.pub
● Setting up the server
○ make git user and .ssh directory
$ sudo adduser git && su git && mkdir .ssh
○ add SSH public keys to authorized_keys
$ cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys
○ make bare repository
$ cd /opt/git && mkdir project.git && cd project.git && git --bare init
○ someone push his repository to the server
# on Johns computer
$ cd myproject && git init && git add . && git commit -m 'initial commit'
$ git remote add origin git@gitserver:/opt/git/project.git
$ git push origin master
○ another can clone the repository
$ git clone git@gitserver:/opt/git/project.git
○ Setting up git-shell
$ sudo vim /etc/passwd -> git:x:1000:1000::/home/git:/usr/bin/git-shell
34. Git Server - Anonymous Read Acess for the Repo
● Anonymous access through HTTP
1. Run a static web server
2. The server's document root where your Git repositories
○ Apache Virtual Host Setting
○ Set the Unix user group of the /opt/git directories to www-data
3. Enable post-update hook
● GitWeb : git instaweb
35. Git Server - Access Control (Gitosis, Gitolite), Hosted Git
● Gitosis help you manage the authorized_keys file as well as implement some
simple access controls.
● Gitolite is an authorization layer on top of Git.
○ Authentication is identifying who the user is.
○ Authorization is deciding if he is allowed to do what he is attempting to.
○ Specify permissions not just by repository, but also by branch or tag names
within each repository.
● Hosted Git
○ GitHub is by far the largest open source Git hosting site.
○ charges for accounts that maintain private repositories
○ Sign up, enroll the SSH key.
○ Create Repository : name and description
○ Push up your master branch
$ git init && git add . && git commit -m 'initial commit'
$ git remote add origin git@github.com:testinguser/iphone_project.git
$ git push origin master
○ The Your Clone URL is a read/write SSH-based URL.
○ Admin page -> “Add another collaborator”
○ Fork a project in order to contribute on it.
36. Distributed Git - Centralized Workflow
● Centralized workflow
Shared repo can only do fast-forward merge.
37. Distributed Git - Integration-Manager Workflow
● Integration-Manager workflow
Each party can work at their own pace.
38. Distributed Git - Dictator and Lieutenants Workflow
● Dictator and Lieutenants workflow
1. Regular developers work on their topic branch and rebase their work on top of master. The master branch is that of the dictator.
2. Lieutenants merge the developers’ topic branches into their master branch.
3. The dictator merges the lieutenants’ master branches into the dictator’s master branch.
4. The dictator pushes their master to the reference repository so the other developers can rebase on it.
Benevolent dictator workflow
39. ● Commit Guidelines
○ whitespaces errors check - git diff --check
○ Try to make each commit a logically separate changeset.
○ Try to make your changes digestible.
○ one commit per issue
○ Use the imperative present tense - Instead of "I added tests for "
use "Add tests for"
Contributing to a project - Commit Guidelines
40. ● John clones the repository, makes a change, and commits locally.
# John's Machine
$ git clone john@githost:simplegit.git
Initialized empty Git repository in /home/john/simplegit/.git/
...
$ cd simplegit/
$ vim lib/simplegit.rb
$ git commit -am 'removed invalid default value'
[master 738ee87] removed invalid default value
1 files changed, 1 insertions(+), 1 deletions(-)
● Jessica clones the repository and commits a change.
# Jessica's Machine
$ git clone jessica@githost:simplegit.git
Initialized empty Git repository in /home/jessica/simplegit/.git/
...
$ cd simplegit/
$ vim TODO
$ git commit -am 'add reset task'
[master fbff5bc] add reset task
1 files changed, 1 insertions(+), 0 deletions(-)
● Jessica pushes her work up to the server:
# Jessica's Machine
$ git push origin master
...
To jessica@githost:simplegit.git
1edee6b..fbff5bc master -> master
● John tries to push his change up, too:
# John's Machine
$ git push origin master
To john@githost:simplegit.git
! [rejected] master -> master (non-fast forward)
error: failed to push some refs to 'john@githost:simplegit.git'
Contributing to a project - Private Small Team
41. ● John has to fetch Jessica’s changes and merge them in.
$ git fetch origin
...
From john@githost:simplegit
+ 049d078...fbff5bc master -> origin/master
Contributing to a project - Private Small Team
42. ● John has to merge them into his own work before he is allowed to push:
$ git merge origin/master
Merge made by recursive.
TODO | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Contributing to a project - Private Small Team
43. ● John can push his new merged work up to the server:
$ git push origin master
...
To john@githost:simplegit.git
fbff5bc..72bbc59 master -> master
Contributing to a project - Private Small Team
44. ● In the meantime, Jessica’s created a topic branch called issue54 and done three
commits.
● Jessica wants to sync up with John, so she fetches:
# Jessica's Machine
$ git fetch origin
...
From jessica@githost:simplegit
fbff5bc..72bbc59 master -> origin/master
Contributing to a project - Private Small Team
45. ● Jessica thinks her topic branch is ready, but she wants to know what she has to
merge her work into so that she can push. She runs git log to find out:
$ git log --no-merges origin/master ^issue54
commit 738ee872852dfaa9d6634e0dea7a324040193016
Author: John Smith <jsmith@example.com>
Date: Fri May 29 16:01:27 2009 -0700
removed invalid default value
● Jessica can merge her topic work into her master branch, merge John’s work
(origin/master) into her master branch, and then push back to the server again.
$ git checkout master
Switched to branch "master"
Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
$ git merge issue54
Updating fbff5bc..4af4298
Fast forward
README | 1 +
lib/simplegit.rb | 6 +++++-
2 files changed, 6 insertions(+), 1 deletions(-)
$ git merge origin/master
Auto-merging lib/simplegit.rb
Merge made by recursive.
lib/simplegit.rb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Contributing to a project - Private Small Team
46. ● Now origin/master is reachable from Jessica’s master branch, so she should be
able to successfully push (assuming John hasn’t pushed again in the meantime):
$ git push origin master
...
To jessica@githost:simplegit.git
72bbc59..8059c15 master -> master
Contributing to a project - Private Small Team
47. ● John and Jessica are working together on one feature, while Jessica and Josie
are working on a second.
● Jessica creates a new branch for featureA and does some work on it there:
# Jessica's Machine
$ git checkout -b featureA
Switched to a new branch "featureA"
$ vim lib/simplegit.rb
$ git commit -am 'add limit to log function'
[featureA 3300904] add limit to log function
1 files changed, 1 insertions(+), 1 deletions(-)
● Jessica doesn’t have push access to the master branch — only the integrators do
— so she has to push to another branch in order to collaborate with John:
$ git push origin featureA
...
To jessica@githost:simplegit.git
* [new branch] featureA -> featureA
● While she waits for feedback from John, Jessica decides to start working on
featureB with Josie.
# Jessica's Machine
$ git fetch origin
$ git checkout -b featureB origin/master
Switched to a new branch "featureB"
● Jessica makes a couple of commits on the featureB branch:
$ vim lib/simplegit.rb
$ git commit -am 'made the ls-tree function recursive'
[featureB e5b0fdc] made the ls-tree function recursive
1 files changed, 1 insertions(+), 1 deletions(-)
$ vim lib/simplegit.rb
$ git commit -am 'add ls-files'
[featureB 8512791] add ls-files
1 files changed, 5 insertions(+), 0 deletions(-)
Contributing to a project - Private Managed Team
49. ● She’s ready to push up her work, but gets an e-mail from Josie that a branch
with some initial work on it was already pushed to the server as featureBee.
$ git fetch origin
...
From jessica@githost:simplegit
* [new branch] featureBee -> origin/featureBee
● Jessica can now merge this into the work she did with git merge:
$ git merge origin/featureBee
Auto-merging lib/simplegit.rb
Merge made by recursive.
lib/simplegit.rb | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
● She pushes the merged work in her featureB to the featureBee branch on the
server.
$ git push origin featureB:featureBee
...
To jessica@githost:simplegit.git
fba9af8..cd685d1 featureB -> featureBee
● John pushed some changes to the featureA. So she want to know what the changes
are.
$ git fetch origin
...
From jessica@githost:simplegit
3300904..aad881d featureA -> origin/featureA
● Jessica can see what has been changed with git log:
$ git log origin/featureA ^featureA
commit aad881d154acdaeb2b6b18ea0e827ed8a6d671e6
Author: John Smith <jsmith@example.com>
Date: Fri May 29 19:57:33 2009 -0700
changed log output to 30 from 25
Contributing to a project - Private Managed Team
50. ● Jessica merges John’s work into her own featureA.
$ git checkout featureA
Switched to branch "featureA"
$ git merge origin/featureA
Updating 3300904..aad881d
Fast forward
lib/simplegit.rb | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
● Jessica wants to tweak something.
$ git commit -am 'small tweak'
[featureA 774b3ed] small tweak
1 files changed, 1 insertions(+), 1 deletions(-)
$ git push origin featureA
...
To jessica@githost:simplegit.git
3300904..774b3ed featureA -> featureA
Contributing to a project - Private Managed Team
51. ● Jessica, Josie, and John inform the integrators that the featureA and featureBee
branches on the server are ready for integration into the mainline.
Contributing to a project - Private Managed Team
Jessica’s history
52. ● Multiple teams can work in parallel (without necessarily having to involve or
impede the entire team).
Contributing to a project - Private Managed Team
53. ● Fork - public small project
1. Clone the main repository.
2. Create a topic branch you're planning to contribute.
3. Do something in it.
4. Create your own writable fork of the project.
5. git push myfork featureA
6. White 'pull request' message with 'git request-pull'
$ git request-pull origin/master myfork
The following changes since commit 1edee6b1d61823a2de3b09c160d7080b8d1b3a40:
John Smith (1):
added a new function
are available in the git repository at:
git://githost/simplegit.git featureA
Jessica Smith (2):
add limit to log function
change log output to 30 from 25
lib/simplegit.rb | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
● Send Emails - public large project
○ Create the content of mail with 'git format-patch -M'
$ git format-patch -M origin/master
0001-add-limit-to-log-function.patch
0002-changed-log-output-to-30-from-25.patch
○ Send it with 'git send-email'.
Read Docuementation/SubmittingPatches for more details.
(How to set the configurations of email)
Contributing to a Pubilc Project - request-pull, format-patch
54. ● Having work themes isolated into topic branches
That makes it easier for you to rebase your work if the tip of the main
repository has moved in the meantime.
● Don't continue working on the topic branch you just pushed up.
$ git checkout -b featureB origin/master
$ (work)
$ git commit
$ git push myfork featureB
$ (email maintainer)
$ git fetch origin
Contributing to a Public Project - Topic Branches
55. ● When the maintainer no longer cleanly merges,
Rebase that branch on top of origin/master, resolve the conflicts for the
maintainer, and then resubmit your changes:
$ git checkout featureA
$ git rebase origin/master
$ git push -f myfork featureA
Contributing to a Public Project - Topic Branches
56. ● The maintainer has looked at work in featureB and likes the concept but would
like you to change an implementation detail.
$ git checkout -b featureBv2 origin/master
$ git merge --no-commit --squash featureB
$ (change implementation)
$ git commit
$ git push myfork featureBv2
Contributing to a Public Project - Topic Branches
57. ● Working in Topic Branches
$ git branch sc/ruby_client master
● Applying Patches with apply
$ git apply /tmp/patch-ruby-client.patch - "apply all or abort all"
$ git apply --check 0001-seeing-if-this-helps-the-gem.patch
● Applying a Patch with am
0001-limit-log-function.patch
From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
From: Jessica Smith <jessica@example.com>
Date: Sun, 6 Apr 2008 10:17:23 -0700
Subject: [PATCH 1/2] add limit to log function
Limit log functionality to the first 20
$ git am 0001-limit-log-function.patch
Applying: add limit to log function
$ git log --pretty=fuller -1
commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
Author: Jessica Smith <jessica@example.com>
AuthorDate: Sun Apr 6 10:17:23 2008 -0700
Commit: Scott Chacon <schacon@gmail.com>
CommitDate: Thu Apr 9 09:19:06 2009 -0700
add limit to log function
Limit log functionality to the first 20
Maintaining a Project - Combining Works - git apply, git am commands
58. ● git log contrib --not master
commit 5b6235bd297351589efc4d73316f0a68d484f118
Author: Scott Chacon <schacon@gmail.com>
Date: Fri Oct 24 09:53:59 2008 -0700
seeing if this helps the gem
commit 7482e0d16d04bea79d0dba8988cc78df655f16a0
Author: Scott Chacon <schacon@gmail.com>
Date: Mon Oct 22 19:38:36 2008 -0700
updated the gemspec to hopefully work better
● You should carefully use the command - 'git diff'.
$ git diff master - If master is a direct ancestor of your topic branch, this isn’t a problem; but
if the two histories have diverged, the diff will look like you’re adding all the new stuff in
your topic branch and removing everything unique to the master branch.
$ git merge-base contrib master
36c7dba2c95e6bbb78dfa822519ecfec6e1ca649
$ git diff 36c7db
$ git diff master...contrib
Maintaining a Project - Viewing Differences between Branches
59. ● One simple workflow merges your work into your master branch.
Maintaining a Project - Combining Works - Simple Workflow
60. ● Two-phase merge cycle
Maintaining a Project - Combining Works - Two-phase Merge Cycle
61. ● Cherry Picking Workflows
$ git cherry-pick e43a6fd3e94888d76779ad79fb568ed180e5fcdf
Finished one cherry-pick.
[master]: created a0a41a9: "More friendly message when locking the index fails."
3 files changed, 17 insertions(+), 3 deletions(-)
Maintaining a Project - Combining Works - Cherry Picking
62. ● Tagging Your Releases
$ git tag -s v1.5 -m 'my signed 1.5 tag'
You need a passphrase to unlock the secret key for
user: "Scott Chacon <schacon@gmail.com>"
1024-bit DSA key, ID F721C45A, created 2009-02-09
● How to make the public key as a blob in the repository
$ gpg --list-keys
/Users/schacon/.gnupg/pubring.gpg
---------------------------------
pub 1024D/F721C45A 2009-02-09 [expires: 2010-02-09]
uid Scott Chacon <schacon@gmail.com>
sub 2048g/45D02282 2009-02-09 [expires: 2010-02-09]
Exports the key info and writes a new blob with them into Git
$ gpg -a --export F721C45A | git hash-object -w --stdin
659ef797d181633c87ec71ac3f9ba29fe5775b92
$ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92
To share this key
$git push --tags
The users can import the key by pulling the blob directly .
$ git show maintainer-pgp-pub | gpg --import
Maintaining a Project - Tagging, Maintainer Public Key
63. ● Generating a Build Number
$ git describe master
v1.6.2-rc1-20-g8c5b85c
The git describe command favors annotated tags (which are created with the -a or
-s flag).
● Preparing a Release
$ git archive master --prefix='project/' | gzip > `git describe master`.tar.gz
$ ls *.tar.gz
v1.6.2-rc1-20-g8c5b85c.tar.gz
$ git archive master --prefix='project/' --format=zip > `git describe master`.zip
● Shortlog
$ git shortlog --no-merges master --not v1.0.1
Chris Wanstrath (8):
Add support for annotated tags to Grit::Tag
Add packed-refs annotated tag support.
Add Grit::Commit#to_patch
Update version and History.txt
Remove stray `puts`
Make ls_tree ignore nils
Tom Preston-Werner (4):
fix dates in history
dynamic version method
Version bump to 1.0.2
Regenerated gemspec for version 1.0.2
Maintaining a Project - Building Version Number and Source Tarball
64. ● Git is smart enough to figure out what commit you meant to type as long as your
partial SHA-1 is at least four characters long and unambiguous.
$ git show 1c002dd4b536e7479fe34593e72e6c6c1819e53b
$ git show 1c002dd4b536e7479f
$ git show 1c002d
● git log --abbrev-commit --pretty=oneline
● git rev-parse topic1
ca82a6dff817ec66f44342007202690a93763949
● reflog - a log of where your HEAD and branch references have been for the last
few months.
$ git reflog
734713b... HEAD@{0}: commit: fixed refs handling, added gc auto, updated
d921970... HEAD@{1}: merge phedders/rdocs: Merge made by recursive.
1c002dd... HEAD@{2}: commit: added some blame and merge stuff
$ git show HEAD@{5}
● To see where your master branch was yesterday
$ git show master@{yesterday}
● To see reflog information formatted like the git log output
$ git log -g master
commit 9ddfbdf5264aa8e44cedf8f0bf09887efc35a7dd
Reflog: master@{0} (seungzzang <seungzzang@gmail.com>)
Reflog message: commit (merge): Kruskal vertexSet test
Author: seungzzang <seungzzang@gmail.com>
Date: Sat Jun 1 22:36:09 2013 +0900
Kruskal vertexSet test
● The reflog information is strictly local.
Git Tools - Revision Selection
65. ● Ancestry References
$ git log --pretty=format:'%h %s' --graph
* 734713b fixed refs handling, added gc auto, updated tests
* d921970 Merge commit 'phedders/rdocs'
|
| * 35cfb2b Some rdoc changes
* | 1c002dd added some blame and merge stuff
|/
* 1c36188 ignore *.gem
* 9b29157 add open3_detach to gemspec file list
$ git show HEAD^
commit d921970aadf03b3cf0e71becdaab3147ba71cdef
...
$ git show d921970^
commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b
...
$ git show d921970^2
commit 35cfb2b795a55793d7cc56a6cc2060b4bb732548
...
$ git show HEAD~3 = $ git show HEAD^^^
commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d
...
$ git show HEAD~3^2
Git Tools - Revision Selection
66. ● Commit Range
What work is on this branch that I haven’t yet merged into my main branch?
● To see what you’re about to push to a remote
git log origin/master..HEAD = git log origin/master..
● Multiple points
git log refA..refB
git log ^refA refB
git log refB --not refA
git log refA refB ^refC
git log refA refB --not refC
$ git log --left-right master...
experiment
< F
< E
> D
> C
$ git log master...
experiment
F
E
D
C
$ git log master..experiment
D
C
$ git log experiment..master
F
E
Git Tools - Revision Selection
68. ● Stashing takes your modified tracked files and staged changes
and saves it on a stack of unfinished changes.
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: index.html
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
#
# modified: lib/simplegit.rb
$ git stash
...
$ git status
# On branch master
nothing to commit (working directory clean)
$ git stash list
stash@{0}: WIP on master: 049d078 added the index file
stash@{1}: WIP on master: c264051... Revert "added file_size"
Git Tools - Stashing
$ git stash apply stash@{0}
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be
committed)
#
# modified: index.html
# modified: lib/simplegit.rb
#
$ git stash drop stash@{0}
$ git stash apply --index
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: index.html
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be
committed)
#
# modified: lib/simplegit.rb
69. ● Un-applying a Stash
$ git stash show -p stash@{0} | git apply -R
$ git stash show -p | git apply -R
$ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
$ git stash
...
$ git stash-unapply
● Creating a Branch from a Stash
git stash branch creates a new branch for you,
checks out the commit you were on when you stashed your work,
reapplies your work there, and then drops the stash if it applies successfully:
$ git stash branch testchanges
Switched to a new branch "testchanges"
# On branch testchanges
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: index.html
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
#
# modified: lib/simplegit.rb
#
Dropped refs/stash@{0} (f0dfc4d5dc332d1cee34a634182e168c4efc3359)
Git Tools - Stashing
70. ● One of the great things about Git is that it allows you to make decisions at the
last possible moment.
● Changing the Last Commit
○ git add or git rm ...
git commit --amend takes your current staging area and makes it the snapshot
for the new commit.
○ Amending changes the SHA-1 of the commit.
Don’t amend your last commit if you’ve already pushed it.
● Changing Multiple Commits
$ git rebase -i HEAD~3
Every commit included in the range HEAD~3..HEAD will be rewritten.
Don’t include any commit you’ve already pushed to a central server.
● Reordering Commits - reorder pick lines
Git Tools - Rewriting History
71. ● Splitting a Commit
pick f7f3f6d changed my name a bit
edit 310154e updated README formatting and added blame
pick a5f4a0d added cat-file
$ git reset HEAD^
$ git add README
$ git commit -m 'updated README formatting'
$ git add lib/simplegit.rb
$ git commit -m 'added blame'
$ git rebase --continue
$ git log -4 --pretty=format:"%h %s"
1c002dd added cat-file
9b29157 added blame
35cfb2b updated README formatting
f3cc40e changed my name a bit
● filter-branch
git filter-branch --tree-filter "rm -f *~" HEAD
● Changing E-Mail Address Globally
$ git filter-branch --commit-filter '
if [ "$GIT_AUTHOR_EMAIL" = "schacon@localhost" ];
then
GIT_AUTHOR_NAME="Scott Chacon";
GIT_AUTHOR_EMAIL="schacon@example.com";
git commit-tree "$@";
else
git commit-tree "$@";
fi' HEAD
Git Tools - Rewriting History
72. ● Blame tells when each line of the method was last edited and by whom.
$ git blame -L 12,22 simplegit.rb
^4832fe2 (Scott Chacon 2008-03-15 10:31:28 -0700 12) def show(tree = 'master')
^4832fe2 (Scott Chacon 2008-03-15 10:31:28 -0700 13) command("git show #{tree}")
^4832fe2 (Scott Chacon 2008-03-15 10:31:28 -0700 14) end
^4832fe2 (Scott Chacon 2008-03-15 10:31:28 -0700 15)
9f6560e4 (Scott Chacon 2008-03-17 21:52:20 -0700 16) def log(tree = 'master')
79eaf55d (Scott Chacon 2008-04-06 10:15:08 -0700 17) command("git log #{tree}")
9f6560e4 (Scott Chacon 2008-03-17 21:52:20 -0700 18) end
9f6560e4 (Scott Chacon 2008-03-17 21:52:20 -0700 19)
42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 20) def blame(path)
42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 21) command("git blame #{path}")
42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 22) end
^4832fe2 commit lines designate that those lines were in this file’s original
commit. That commit is when this file was first added to this project, and those
lines have been unchanged since.
● -C option makes blame to figure out where snippets of code within it originally
came from if they were copied from elsewhere.
$ git blame -C -L 141,153 GITPackUpload.m
f344f58d GITServerHandler.m (Scott 2009-01-04 141)
f344f58d GITServerHandler.m (Scott 2009-01-04 142) - (void) gatherObjectShasFromC
f344f58d GITServerHandler.m (Scott 2009-01-04 143) {
70befddd GITServerHandler.m (Scott 2009-03-22 144) //NSLog(@"GATHER COMMI
ad11ac80 GITPackUpload.m (Scott 2009-03-24 145)
ad11ac80 GITPackUpload.m (Scott 2009-03-24 146) NSString *parentSha;
ad11ac80 GITPackUpload.m (Scott 2009-03-24 147) GITCommit *commit = [g
ad11ac80 GITPackUpload.m (Scott 2009-03-24 148)
ad11ac80 GITPackUpload.m (Scott 2009-03-24 149) //NSLog(@"GATHER COMMI
ad11ac80 GITPackUpload.m (Scott 2009-03-24 150)
56ef2caf GITServerHandler.m (Scott 2009-01-05 151) if(commit) {
56ef2caf GITServerHandler.m (Scott 2009-01-05 152) [refDict setOb
56ef2caf GITServerHandler.m (Scott 2009-01-05 153)
This is really useful - You get the original commit where you copied the code over,
because that is the first time you touched those lines in this file.
Git Tools - Debugging with Git - blame
73. ● Binary Search
$ git bisect start
$ git bisect bad
$ git bisect good v1.0
Bisecting: 6 revisions left to test after this
[ecb6e1bc347ccecc5f9350d878ce677feb13d3b2] error handling on repo
$ git bisect good
Bisecting: 3 revisions left to test after this
[b047b02ea83310a70fd603dc8cd7a6cd13d15c04] secure this thing
$ git bisect bad
Bisecting: 1 revisions left to test after this
[f71ce38690acf49c1f3c9bea38e09d82a5ce6014] drop exceptions table
$ git bisect good
b047b02ea83310a70fd603dc8cd7a6cd13d15c04 is first bad commit
commit b047b02ea83310a70fd603dc8cd7a6cd13d15c04
Author: PJ Hyett <pjhyett@example.com>
Date: Tue Jan 27 14:48:32 2009 -0800
secure this thing
:040000 040000 40ee3e7821b895e52c1695092db9bdc4c61d1730
f24d3c6ebcfc639b1a3814550e62d60b8e68a8e4 M config
$ git bisect reset : finish binary search and move to HEAD.
$ git bisect start HEAD v1.0
$ git bisect run test-error.sh
Git Tools - Debugging with Git - bisect
74. ● Starting with Submodules
$ git submodule add git://github.com/chneukirchen/rack.git rack
Initialized empty Git repository in /opt/subtest/rack/.git/
...
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: .gitmodules
# new file: rack
$ cat .gitmodules
[submodule "rack"]
path = rack
url = git://github.com/chneukirchen/rack.git
$ git diff --cached rack
diff --git a/rack b/rack
new file mode 160000
index 0000000..08d709f
--- /dev/null
+++ b/rack
@@ -0,0 +1 @@
+Subproject commit 08d709f78b8c5b0fbeb7821e37fa53e69afcf433
$ git commit -m 'first commit with submodule rack'
[master 0550271] first commit with submodule rack
2 files changed, 4 insertions(+), 0 deletions(-)
create mode 100644 .gitmodules
create mode 160000 rack
Git Tools - Submodules
75. ● Cloning a Project with Submodules
$ git clone git://github.com/schacon/myproject.git
Initialized empty Git repository in /opt/myproject/.git/
...
$ cd myproject
$ ls -l
total 8
-rw-r--r-- 1 schacon admin 3 Apr 9 09:11 README
drwxr-xr-x 2 schacon admin 68 Apr 9 09:11 rack
$ ls rack/
$
$ git submodule init
Submodule 'rack' (git://github.com/chneukirchen/rack.git) registered for path 'rack'
$ git submodule update
$ git merge origin/master
Updating 0550271..85a3eee
Fast forward
rack | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
$git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: rack
$ git diff
diff --git a/rack b/rack
index 6c5e70b..08d709f 160000
--- a/rack
+++ b/rack
@@ -1 +1 @@
-Subproject commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
+Subproject commit 08d709f78b8c5b0fbeb7821e37fa53e69afcf433
Git Tools - Submodules
$ git submodule update
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (3/3), done.
...
76. ● One common problem happens when a developer makes a change locally in a
submodule but doesn’t push it to a public server.
He commit a pointer to that non-public state and push up the superproject.
When other developers try to run git submodule update,
$ git submodule update
fatal: reference isn’t a tree: 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
Unable to checkout '6c5e70b984a60b3cecd395edd5ba7575bf58e0' in submodule path 'rack'
● You do an initial submodule update , commit in that submodule directory,
and then run git submodule update again from the superproject.
Git will overwrite your changes without telling you. -> Avoid this!
● Switching from subdirectories to submodules
$ rm -Rf rack/
$ git submodule add git@github.com:schacon/rack.git rack
'rack' already exists in the index
$ git rm -r rack
$ git submodule add git@github.com:schacon/rack.git rack
Initialized empty Git repository in /opt/testsub/rack/.git/
remote: Counting objects: 3184, done.
remote: Compressing objects: 100% (1465/1465), done.
...
● If you try to switch back to a branch where those files are still in the actual
tree rather than a submodule - you get this error.
$ git checkout master
error: Untracked working tree file 'rack/AUTHORS' would be overwritten by merge.
$ mv rack /tmp/
$ git checkout master
Switched to branch "master"
when you switch back, You can either run git submodule update to reclone, or you
can move your /tmp/rack directory back.
Git Tools - Submodule Issues
77. ● Subtree deals with the subproject issue.
$ git remote add rack_remote git@github.com:schacon/rack.git
$ git fetch rack_remote
...
$ git checkout -b rack_branch rack_remote/master
Branch rack_branch set up to track remote branch refs/remotes/rack_remote/master.
Switched to a new branch "rack_branch"
To pull the rack project into the rack subdirectory of your master branch,
$ git checkout master
$ git read-tree --prefix=rack/ -u rack_branch
The read-tree reads the root tree of one branch into your current staging area
and working directory.
● Merge changes in rack_remote into rack_branch.
$ git checkout rack_branch
$ git pull
● Merge changes in rack_remote into master.
$ git checkout master
$ git merge --squash -s subtree --no-commit rack_branch
● To get a diff between rack subdirectories in master and rack_branch
$ git diff-tree -p rack_branch
To get a diff between rack subdirectories in master and rack_remote/master
$ git diff-tree -p rack_remote/master
Git Tools - Subtree
78. ● Subversion can have only a single linear history.
It’s generally best to keep your history as linear as possible by rebasing your work
although you can easily do local branching and merging.
● Working with Git-based remote versions of your projects concurrently with a
Subversion server isn’t a good idea.
git svn dcommit rewrites your local Git commit to include a unique identifier.
It means that all the SHA-1 checksums for your commits change.
If you want to push to both a Git server and a Subversion server,
you have to push ( dcommit) to the Subversion server first, because that action
changes your commit data.
● If you push to a SVN server before you do 'git svn rebase', your project state can be messy.
● Recommanded Workflows
1. git commit
2. git svn rebase
3. ( git rebase --continue )
4. git svn dcommit
or
1. git stash
2. git svn rebase
3. git stash apply
4. git commit
5. git svn dcommit
6. git stash drop
Git and Subversion
79. ● How to get svn history in order to use it in Git repo
git svn clone svn://svnRepoServer/... -T trunk -r<revision>:HEAD local-dir
● Subversion has a linear history.
So, If you’re pushing to a Subversion server via git svn, It's better for you to rebase
your work onto a single branch each time instead of merging branches together.
● Creating a New SVN Branch
git svn branch [branchname] = svn copy trunk branches/opera
● To commit into the new SVN Branch,
git branch opera remotes/opera
● To merge new SVN Branch into master,
git merge opera
This merge likely will be much easier than it would be in Subversion.
(Because Git will automatically detect the appropriate merge base for you)
● If you push the merge back to a SVN server, The merge information will be
disapper
Because of SVN characteristics.
The dcommit makes your git merge result look like you ran git merge --squash.
Git and Subversion