Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
128 changes: 69 additions & 59 deletions book/09-git-and-other-scms/sections/client-tfs.asc
Original file line number Diff line number Diff line change
Expand Up @@ -152,21 +152,31 @@ $ git config set --local core.autocrlf=false
Lo siguiente obvio que querrás hacer es trabajar en el proyecto.
TFVC y TFS tienen varias características que pueden agregar complejidad a su flujo de trabajo:

parche-29
. Las ramas de características que no están representadas en TFVC agregan un poco de complejidad.
Esto tiene que ver con las * muy * diferentes formas en que TFVC y Git representan las ramas.
. Tenga en cuenta que TFVC permite a los usuarios "verificar" los archivos del servidor, bloqueándolos para que nadie más pueda editarlos.
Obviamente, esto no le impedirá editarlos en su repositorio local, pero podría interferir cuando llegue el momento de enviar sus cambios al servidor TFVC.
. TFS tiene el concepto de comprobaciones "compuertas", donde un ciclo de prueba de compilación TFS debe completarse satisfactoriamente antes de permitir el registro.
Utiliza la función `` shelve '' en TFVC, que no cubrimos en detalle aquí.
Puede falsificar esto de forma manual con git-tf, y git-tfs proporciona el comando `checkintool` que es sensible a la puerta.
=======
. Las ramas de características que no están representadas en TFVC agregan un poco de complejidad.
Esto tiene que ver con las * muy * diferentes formas en que TFVC y Git representan ramas.
. Tenga en cuenta que TFVC permite a los usuarios "verificar" los archivos del servidor, bloqueándolos para que nadie más pueda editarlos.
Obviamente, esto no le impedirá editarlos en su repositorio local, pero podría interferir cuando llegue el momento de enviar sus cambios al servidor TFVC.
. TFS has the concept of ``gated'' checkins, where a TFS build-test cycle has to complete successfully before the checkin is allowed.
This uses the ``shelve'' function in TFVC, which we don't cover in detail here.
You can fake this in a manual fashion with git-tf, and git-tfs provides the `checkintool` command which is gate-aware.
. TFS tiene el concepto de comprobaciones "compuertas", donde un ciclo de prueba de compilación TFS debe completarse satisfactoriamente antes de permitir el registro.
Utiliza la función `` shelve '' en TFVC, que no cubrimos en detalle aquí.
Puede falsificar esto de forma manual con git-tf, y git-tfs proporciona el comando `checkintool` que es sensible a la puerta.
Master

In the interest of brevity, what we'll cover here is the happy path, which sidesteps or avoids most of these issues.
En aras de la brevedad, lo que trataremos aquí es el camino feliz, qué pasos laterales o evita la mayoría de estos problemas.

===== Workflow: `git-tf`
===== Flujo de trabajo del: `git-tf`


Let's say you've done some work, made a couple of Git commits on `master`, and you're ready to share your progress on the TFVC server.
Here's our Git repository:
Digamos que has hecho algo de trabajo, has hecho un par de confirmaciones de Git en `master` y estás listo para compartir tu progreso en el servidor de TFVC.
Aquí está nuestro repositorio de Git:

[source,console]
----
Expand All @@ -180,8 +190,8 @@ $ git log --oneline --graph --decorate --all
Team Project Creation Wizard
----

We want to take the snapshot that's in the `4178a82` commit and push it up to the TFVC server.
First things first: let's see if any of our teammates did anything since we last connected:
Queremos tomar la instantánea que está en la confirmación `4178a82` y subirla al servidor TFVC.
Lo primero es lo primero: veamos si alguno de nuestros compañeros de equipo hizo algo desde la última vez que nos conectamos:

[source,console]
----
Expand All @@ -203,17 +213,17 @@ $ git log --oneline --graph --decorate --all
Team Project Creation Wizard
----

Looks like someone else is working, too, and now we have divergent history.
This is where Git shines, but we have two choices of how to proceed:
Parece que alguien más está trabajando, también, y ahora tenemos una historia divergente.
Aquí es donde brilla el Git, pero tenemos dos opciones de cómo proceder:

. Making a merge commit feels natural as a Git user (after all, that's what `git pull` does), and git-tf can do this for you with a simple `git tf pull`.
Be aware, however, that TFVC doesn't think this way, and if you push merge commits your history will start to look different on both sides, which can be confusing.
However, if you plan on submitting all of your changes as one changeset, this is probably the easiest choice.
. Rebasing makes our commit history linear, which means we have the option of converting each of our Git commits into a TFVC changeset.
Since this leaves the most options open, we recommend you do it this way; git-tf even makes it easy for you with `git tf pull --rebase`.
. Hacer una confirmación de fusión se siente natural como un usuario de Git (después de todo, eso es lo que hace `git pull`), y git-tf puede hacer esto por ti con un simple` git tf pull`.
Tenga en cuenta, sin embargo, que TFVC no piensa de esta manera, y si empuja la fusión se compromete su historia comenzará a verse diferente en ambos lados, lo que puede ser confuso.
Sin embargo, si planea enviar todos sus cambios como un solo conjunto de cambios, esta es probablemente la opción más fácil.
. Rebasing hace que nuestro historial de compromisos sea lineal, lo que significa que tenemos la opción de convertir cada una de nuestras confirmaciones de Git en un conjunto de cambios de TFVC.
Como esto deja la mayoría de las opciones abiertas, le recomendamos que lo haga de esta manera; git-tf incluso te lo facilita con `git tf pull --rebase`.

The choice is yours.
For this example, we'll be rebasing:
La decisión es tuya:
Para este ejemplo, vamos a rebasar:

[source,console]
----
Expand All @@ -232,9 +242,9 @@ $ git log --oneline --graph --decorate --all
Team Project Creation Wizard
----

Now we're ready to make a checkin to the TFVC server.
Git-tf gives you the choice of making a single changeset that represents all the changes since the last one (`--shallow`, which is the default) and creating a new changeset for each Git commit (`--deep`).
For this example, we'll just create one changeset:
Ahora estamos listos para hacer una comprobación en el servidor de TFVC.
Git-tf le da la opción de hacer un único conjunto de cambios que represente todos los cambios desde el último (`--shallow`, que es el predeterminado) y crear un nuevo conjunto de cambios para cada confirmación de Git (` --deep`).
Para este ejemplo, crearemos un solo conjunto de cambios:

[source,console]
----
Expand All @@ -255,23 +265,23 @@ $ git log --oneline --graph --decorate --all
Team Project Creation Wizard
----

There's a new `TFS_C35348` tag, indicating that TFVC is storing the exact same snapshot as the `5a0e25e` commit.
It's important to note that not every Git commit needs to have an exact counterpart in TFVC; the `6eb3eb5` commit, for example, doesn't exist anywhere on the server.
Hay una nueva etiqueta `TFS_C35348`, que indica que TFVC está almacenando la misma instantánea exacta que la confirmación` 5a0e25e`.
Es importante tener en cuenta que no todas las confirmaciones del Git deben tener una contraparte exacta en TFVC; el compromiso `6eb3eb5`, por ejemplo, no existe en ninguna parte del servidor.

That's the main workflow.
There are a couple of other considerations you'll want to keep in mind:
Ese es el flujo de trabajo principal.
Hay un par de otras consideraciones que querrás tener en cuenta:

* There is no branching.
Git-tf can only create Git repositories from one TFVC branch at a time.
* Collaborate using either TFVC or Git, but not both.
Different git-tf clones of the same TFVC repository may have different commit SHA-1 hashes, which will cause no end of headaches.
* If your team's workflow includes collaborating in Git and syncing periodically with TFVC, only connect to TFVC with one of the Git repositories.
* No hay ramificación.
Git-tf solo puede crear repositorios Git de una rama TFVC a la vez.
* Colabora con TFVC o Git, pero no con ambos.
Los diferentes clones de git-tf del mismo repositorio de TFVC pueden tener diferentes hash de confirmación de SHA-1, lo que provocará innumerables dolores de cabeza.
* Si el flujo de trabajo de su equipo incluye la colaboración en Git y la sincronización periódica con TFVC, solo conéctese a TFVC con uno de los repositorios de Git.


===== Workflow: `git-tfs`
===== Flujo de trabajo: `git-tfs`

Let's walk through the same scenario using git-tfs.
Here are the new commits we've made to the `master` branch in our Git repository:
Veamos el mismo escenario usando git-tfs.
Aquí están las nuevas confirmaciones que hemos realizado en la rama `master` en nuestro repositorio de Git:

[source,powershell]
----
Expand All @@ -285,7 +295,7 @@ PS> git log --oneline --graph --all --decorate
* b75da1a New project
----

Now let's see if anyone else has done work while we were hacking away:
Ahora veamos si alguien más ha hecho un trabajo mientras estábamos hackeando:

[source,powershell]
----
Expand All @@ -303,14 +313,14 @@ PS> git log --all --oneline --graph --decorate
* b75da1a New project
----

Yes, it turns out our coworker has added a new TFVC changeset, which shows up as the new `aea74a0` commit, and the `tfs/default` remote branch has moved.
Sí, resulta que nuestro compañero de trabajo ha agregado un nuevo conjunto de cambios de TFVC, que se muestra como el nuevo compromiso `aea74a0`, y la rama remota` tfs / default` se ha movido.

As with git-tf, we have two fundamental options for how to resolve this divergent history:
Al igual que con git-tf, tenemos dos opciones fundamentales sobre cómo resolver esta historia divergente:

. Rebase to preserve a linear history.
. Merge to preserve what actually happened.
. Rebase para preservar una historia lineal.
. Fusiona para preservar lo que realmente sucedió.

In this case, we're going to do a ``deep'' checkin, where every Git commit becomes a TFVC changeset, so we want to rebase.
En este caso, haremos un checkin '' profundo '', donde cada confirmación del Git se convierte en un conjunto de cambios de TFVC, por lo que queremos volver a establecer la base.

[source,powershell]
----
Expand All @@ -329,8 +339,8 @@ PS> git log --all --oneline --graph --decorate
* b75da1a New project
----

Now we're ready to complete our contribution by checking in our code to the TFVC server.
We'll use the `rcheckin` command here to create a TFVC changeset for each Git commit in the path from HEAD to the first `tfs` remote branch found (the `checkin` command would only create one changeset, sort of like squashing Git commits).
Ahora estamos listos para completar nuestra contribución al registrar nuestro código en el servidor TFVC.
Usaremos el comando `rcheckin` aquí para crear un conjunto de cambios TFVC para cada commit de Git en la ruta de HEAD a la primera rama remota` tfs` encontrada (el comando `checkin` solo crearía un conjunto de cambios, más o menos como aplastar a Git se compromete).

[source,powershell]
----
Expand Down Expand Up @@ -359,28 +369,28 @@ PS> git log --all --oneline --graph --decorate
* b75da1a New project
----

Notice how after every successful checkin to the TFVC server, git-tfs is rebasing the remaining work onto what it just did.
That's because it's adding the `git-tfs-id` field to the bottom of the commit messages, which changes the SHA-1 hashes.
This is exactly as designed, and there's nothing to worry about, but you should be aware that it's happening, especially if you're sharing Git commits with others.
Observe cómo después de cada registro exitoso en el servidor TFVC, git-tfs vuelve a basar el trabajo restante en lo que acaba de hacer.
Esto se debe a que está agregando el campo `git-tfs-id` al final de los mensajes de confirmación, lo que cambia los valores hash SHA-1.
Esto es exactamente como se diseñó, y no hay nada de qué preocuparse, pero debe saber que está sucediendo, especialmente si comparte Git commits con otros.

TFS has many features that integrate with its version control system, such as work items, designated reviewers, gated checkins, and so on.
It can be cumbersome to work with these features using only a command-line tool, but fortunately git-tfs lets you launch a graphical checkin tool very easily:
TFS tiene muchas características que se integran con su sistema de control de versiones, como elementos de trabajo, revisores designados, registros bloqueados, etc.
Puede ser engorroso trabajar con estas características usando solo una herramienta de línea de comandos, pero afortunadamente git-tfs le permite iniciar una herramienta gráfica de registro muy fácilmente:

[source,powershell]
----
PS> git tfs checkintool
PS> git tfs ct
----

It looks a bit like this:
Se parece un poco a esto:

.The git-tfs checkin tool.
.La herramienta de registro de git-tfs.
image::images/git-tfs-ct.png[The git-tfs checkin tool.]

This will look familiar to TFS users, as it's the same dialog that's launched from within Visual Studio.
Esto resultará familiar para los usuarios de TFS, ya que es el mismo diálogo que se inicia desde Visual Studio.

Git-tfs also lets you control TFVC branches from your Git repository.
As an example, let's create one:
Git-tfs también le permite controlar ramas de TFVC desde su repositorio de Git.
Como ejemplo, creemos uno:

[source,powershell]
----
Expand All @@ -399,14 +409,14 @@ PS> git log --oneline --graph --decorate --all
* b75da1a New project
----

Creating a branch in TFVC means adding a changeset where that branch now exists, and this is projected as a Git commit.
Note also that git-tfs *created* the `tfs/featureBee` remote branch, but `HEAD` is still pointing to `master`.
If you want to work on the newly-minted branch, you'll want to base your new commits on the `1d54865` commit, perhaps by creating a topic branch from that commit.
Crear una rama en TFVC significa agregar un conjunto de cambios donde esa rama ahora existe, y esto se proyecta como una confirmación de Git.
Tenga en cuenta también que git-tfs *created* la rama remota `tfs / featureBee`, pero` HEAD` todavía apunta a `master`.
Si desea trabajar en la rama recién acuñada, querrá basar sus nuevas confirmaciones en la confirmación `1d54865`, tal vez creando una rama de tema a partir de esa confirmación.


===== Git and TFS Summary
===== Resumen de Git y TFS

Git-tf and Git-tfs are both great tools for interfacing with a TFVC server.
They allow you to use the power of Git locally, avoid constantly having to round-trip to the central TFVC server, and make your life as a developer much easier, without forcing your entire team to migrate to Git.
If you're working on Windows (which is likely if your team is using TFS), you'll probably want to use git-tfs, since it's feature set is more complete, but if you're working on another platform, you'll be using git-tf, which is more limited.
As with most of the tools in this chapter, you should choose one of these version-control systems to be canonical, and use the other one in a subordinate fashion – either Git or TFVC should be the center of collaboration, but not both.
Git-tf y Git-tfs son excelentes herramientas para interactuar con un servidor TFVC.
Le permiten usar el poder de Git localmente, evitar tener que realizar un viaje de ida y vuelta al servidor central de TFVC, y hacer que su vida como desarrollador sea mucho más fácil, sin forzar a todo su equipo a migrar a Git.
Si está trabajando en Windows (lo cual es probable si su equipo está usando TFS), probablemente quiera usar git-tfs, ya que su conjunto de características es más completo, pero si está trabajando en otra plataforma, ' Estaré usando git-tf, que es más limitado.
Al igual que con la mayoría de las herramientas de este capítulo, debe elegir uno de estos sistemas de control de versiones para que sea canónico y usar el otro de forma subordinada: Git o TFVC deberían ser el centro de colaboración, pero no ambos.