Git Learning · Normal Workflow Make and view changes made, then stage and commit them. So you have a Git repository and everything is all setup. What now? Generally, it is not going to be much different than working with any other source control system. The only real difference should be the staging process. The workflow will generally go something like this: modify files see what you’ve changed stage the changes you want to commit commit your staged changes rinse, repeat That is the most complex case. modify files commit your changes repeat Easy peasy. the simple case The first thing we’re going to do is modify some files. $ git clone $ cd simplegit For this first example we’ll modify the README file to add ourselves as an author on the project. First, we simply edit the file. A prompt for a commit message will open in our editor (the $EDITOR environment variable or ‘core.editor’ git config variable - by default it uses ‘vim’) that looks like this: using the staging area
Branches vs. Streams Today I watched a subversion webinar where the presenter from a popular hosting/services company described three general branching strategies: unstable trunk, stable trunk, and agile. After seeing their "solution" for managing agile development with branches, I thought "I agree with the goal but what a complete merge mess using branches! Streams are significantly more natural and just plain easier." I'll explain by comparing to AccuRev's implementation of streams..."Agile" Branching Quick review... Now to the point... At various milestones, the release branches are merged into both trunk and ongoing task branches to keep them up-to-date. Agile StreamingQuick review... a stream represents a single configuration of source code. Now to the point... unlike using branches, streams don't require massive merging all over the place. If you promote a single task (i.e. bunch-o-files) to Integration, the other 3 task streams -automatically- have visibility to the newer versions! In summary....
Aspect-oriented programming Programming paradigm AOP includes programming methods and tools that support the modularization of concerns at the level of the source code, while aspect-oriented software development refers to a whole engineering discipline. History[edit] Gregor Kiczales and colleagues at Xerox PARC developed the explicit concept of AOP and followed this with the AspectJ AOP extension to Java. The examples in this article use AspectJ. The Microsoft Transaction Server is considered to be the first major application of AOP followed by Enterprise JavaBeans.[3][4] Motivation and basic concepts[edit] Typically, an aspect is scattered or tangled as code, making it harder to understand and maintain. For example, consider a banking application with a conceptually very simple method for transferring an amount from one account to another:[5] A version with all those new concerns could look somewhat like this: Now consider what would happen if we suddenly need to change the security considerations for the application.
tortoisegit - Porting TortoiseSVN to TortoiseGit Git Version of TortoiseSVN. It is a port of TortoiseSVN for Git. TortoiseGit supports you by regular tasks, such as committing, showing logs, diffing two versions, creating branches and tags, creating patches and so on (see our Screenshots or documentation). You're welcome to contribute to this project (help on coding, documentation, Translation, testing preview releases or helping other users on the mailing lists is really appreciated). If you upgraded to TortoiseGit 1.8.8.0 and TortoisePLink reports "missing MSVCR110.dll", go to TortoiseGit settings, Network and select "TortoiseGitPLink.exe" as ssh client (which is located in the TortoiseGit\bin directory; issue #2156 ). There seems to be a bug in the MFC library, so please make sure you have the latest service pack installed. The latest and recommended release of TortoiseGit is: 1.8.8.0, see ReleaseNotes for details. Download TortoiseGit System prerequisites and installation howto Get a full list of screenshots. Context menu Commit Dialog
What a Branch Is To really understand the way Git does branching, we need to take a step back and examine how Git stores its data. As you may remember from Chapter 1, Git doesn’t store data as a series of changesets or deltas, but instead as a series of snapshots. When you commit in Git, Git stores a commit object that contains a pointer to the snapshot of the content you staged, the author and message metadata, and zero or more pointers to the commit or commits that were the direct parents of this commit: zero parents for the first commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches. To visualize this, let’s assume that you have a directory containing three files, and you stage them all and commit. Staging the files checksums each one (the SHA-1 hash we mentioned in Chapter 1), stores that version of the file in the Git repository (Git refers to them as blobs), and adds that checksum to the staging area: Figure 3-1. Figure 3-2.
Distributed revision control with Mercurial Recherche et téléchargement de fichiers sur Github Github est un service formidable où les gens stockent leurs codes sources et leurs projets... Mais c'est aussi une mine d'or de fichiers en tout genre. Certains utilisateurs de Github font d'ailleurs preuve de négligence et synchronisent même parfois des fichiers contenant des mots de passe en clair ou des infos plus ou moins confidentielles. Pour effectuer ce genre de recherches sur Github, il existe un petit script python qui permet tout simplement de récupérer sur votre ordinateur, les fichiers qui vous intéressent. Par exemple, en tapant : . vous récupérerez tous les historiques bash qui trainent. . vous récupérerez tous les htpasswd qui trainent . vous récupérez des boites mails qui trainent . et des logins/passwords de connexions à des bases de données. Je ne passe pas tout en revue. Pour installer ghrabber, il faut faire un petit : sudo easy_install pip sudo pip install beautifulsoup requests Puis téléchargez ghrabber ici. Vous avez aimé cet article ?
Git Basics So, what is Git in a nutshell? This is an important section to absorb, because if you understand what Git is and the fundamentals of how it works, then using Git effectively will probably be much easier for you. As you learn Git, try to clear your mind of the things you may know about other VCSs, such as Subversion and Perforce; doing so will help you avoid subtle confusion when using the tool. Git stores and thinks about information much differently than these other systems, even though the user interface is fairly similar; understanding those differences will help prevent you from becoming confused while using it. Snapshots, Not Differences The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data. Figure 1-4. Git doesn’t think of or store its data this way. Figure 1-5. This is an important distinction between Git and nearly all other VCSs. Nearly Every Operation Is Local Git Has Integrity Git Generally Only Adds Data
Migrer d'un serveur git à un autre Dans une entreprise, ça bouge beaucoup, et en général, le code suit le mouvement… Si vous voulez migrer du code d’un serveur git à un autre, alors il y a une méthode toute simple : utiliser le script ci-dessous. C’est tout simple, il suffit de copier / coller le script dans un fichier et de le lancer en ligne de commande. Il faudra toutefois, avant les réjouissances, paramétrer quelques variables d’environnement, en tapant simplement (et par exemple) : GIT_SERVER_FROM=git@github.cedrik.frGIT_SERVER_TO=git@gitlab.digitas.frREPO_PREFIX=:myproject/REPOS= »core module1 module2″ Cela migrera : les projets : core + module1 + module2à partir de : git@github.cedrik.fr:myproject/Vers : git@gitlab.digitas.fr:myproject/ Et voilà ! [Ce script a été vu pour la première fois sur TechRevolutions.fr] Vous aimez cet article ? Partage