1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Umstieg auf Git…
  6. Thema

Die Frage die nach dem Artikel bleibt...

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Re: Die Frage die nach dem Artikel bleibt...

    Autor: Steffo 17.03.21 - 13:00

    dummzeuch schrieb:
    --------------------------------------------------------------------------------
    > Ich denke da an Software-Releases, deren
    > Sourcecode nur in seinem lokalen Repository liegt, weil er verschusselt
    > hat, es in das zentrale Repository zu übertragen. Es kommt ja sogar jetzt
    > schon vor, dass Sourcecode wochenlang nicht im Repository landet. (Und
    > komme mir keiner mit "Dann braucht Ihr halt eine Schulung dafür.", das
    > haben wir schon durch.)

    Software-Releases werden über den Build-Server gemacht und durch keine lokale Maschine!
    Wenn ihr das lokal macht, dann stimmt der Prozess schon mal nicht.

    Und wenn Source Code wochenlang nicht im Repository landet, dann kann schlimmstenfalls Arbeit von Wochen verloren gehen. Jeder sollte sich angewöhnen mehrmals am Tag zu pushen. Wenn das jeder im eigenen Branch macht, dann kann da nichts kaputt gehen.

  2. Re: Die Frage die nach dem Artikel bleibt...

    Autor: Trollversteher 17.03.21 - 13:06

    >Weil Subversion, Clearcase, Perforce usw. scheiße sind?

    Sagt wer?
    Der King-of-the-command-shell wird sicher nur mit Git glücklich, aber die armen Entwickler, die damit täglich arbeiten müssen, fragt dabei offenbar keiner...

  3. Re: Die Frage die nach dem Artikel bleibt...

    Autor: Trollversteher 17.03.21 - 13:09

    >Musste lachen. Ist halt wahr. Als nächstes zweifelt noch jemand an, dass der Himmel blau ist :D

    Ach bitte, das kommt doch immer auf den konkreten Anwendungsfall an. Ich werde mich, glaube ich, nie wirklich an die Philosophie hinter Git gewöhnen - für mich als Entwickler soll so ein Tool möglichst unauffällig, intuitiv bedienbar sein und keine zusätzliche Zeit und Nerven kosten. Und das alles hatte ich mit SVN, aber Git verursacht regelmässig Verzweiflung und Wutausbrüche bei mir.

  4. Re: Die Frage die nach dem Artikel bleibt...

    Autor: Trollversteher 17.03.21 - 13:13

    >Die Vorteile bzw. Nachteile die GIT mit sich bringt, sollten wohl bekannt sein. Eine kurze Recherche sollte da genügen. Wir sind vor fünf Jahren auch auf Git(self hosted) gewechselt und dieses Jahr auf GitLab. Ein zurück auf SVN ist unvorstellbar. Denke es geht jedem so, der erst einmal die Flexibilität der Branches und den dezentral Ansatz von GIT kennengelernt hat.

    Nö, mir geht es genau umgekehrt - ich will einfach nur flüssig arbeiten können statt zu friggeln und zu fluchen. Ich würde liebend gerne zu SVN zurückkehren. Der Kollege der das System pflegt sieht das sicher anders undn hat sicher auch seine Gründe dafür, aber ich als "einfache Entwickler" wünsche mir SVN zurück.

  5. Re: Die Frage die nach dem Artikel bleibt...

    Autor: mnementh 17.03.21 - 13:18

    Steffo schrieb:
    --------------------------------------------------------------------------------
    > dummzeuch schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Ich denke da an Software-Releases, deren
    > > Sourcecode nur in seinem lokalen Repository liegt, weil er verschusselt
    > > hat, es in das zentrale Repository zu übertragen. Es kommt ja sogar
    > jetzt
    > > schon vor, dass Sourcecode wochenlang nicht im Repository landet. (Und
    > > komme mir keiner mit "Dann braucht Ihr halt eine Schulung dafür.", das
    > > haben wir schon durch.)
    >
    > Software-Releases werden über den Build-Server gemacht und durch keine
    > lokale Maschine!
    > Wenn ihr das lokal macht, dann stimmt der Prozess schon mal nicht.
    >
    > Und wenn Source Code wochenlang nicht im Repository landet, dann kann
    > schlimmstenfalls Arbeit von Wochen verloren gehen. Jeder sollte sich
    > angewöhnen mehrmals am Tag zu pushen. Wenn das jeder im eigenen Branch
    > macht, dann kann da nichts kaputt gehen.
    Ein eigener Branch der nie synchronisiert wird ist exakt das gleiche, wie seine Änderungen lokal auf dem eigenen Rechner zu haben. Wenn man einen Branch hat, nur um einen Branch zu haben ist das sowieso blöd. Aber definitiv sollten sie regelmäßig synchronisieren, ansonsten verlagert man die Konflikte nur irgendwann in die Zukunft.

  6. Re: Die Frage die nach dem Artikel bleibt...

    Autor: Steffo 17.03.21 - 14:22

    mnementh schrieb:
    --------------------------------------------------------------------------------
    > Ein eigener Branch der nie synchronisiert wird ist exakt das gleiche, wie
    > seine Änderungen lokal auf dem eigenen Rechner zu haben. Wenn man einen
    > Branch hat, nur um einen Branch zu haben ist das sowieso blöd. Aber
    > definitiv sollten sie regelmäßig synchronisieren, ansonsten verlagert man
    > die Konflikte nur irgendwann in die Zukunft.

    Das Thema Konflikte ist ein Thema für sich. Ich meinte, dass bei einem lokalen Datenverlust Arbeit von Wochen verloren gehen kann, wenn man wochenlang nicht pusht (git) bzw. committed (svn).

    Btw: Einen eigenen Branch sollte man immer(!) haben, wenn man etwas Neues angeht. Sei es Feature, Bugfixes oder Refactoring. Es gibt nichts schlimmeres als dass ein Build oder Test nicht durchläuft, weil ein Kollege meint, er müsste direkt auf dem develop oder master-Branch arbeiten.

  7. Re: Die Frage die nach dem Artikel bleibt...

    Autor: dummzeuch 17.03.21 - 14:49

    Steffo schrieb:
    --------------------------------------------------------------------------------
    > dummzeuch schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Ich denke da an Software-Releases, deren
    > > Sourcecode nur in seinem lokalen Repository liegt, weil er verschusselt
    > > hat, es in das zentrale Repository zu übertragen. Es kommt ja sogar
    > jetzt
    > > schon vor, dass Sourcecode wochenlang nicht im Repository landet. (Und
    > > komme mir keiner mit "Dann braucht Ihr halt eine Schulung dafür.", das
    > > haben wir schon durch.)
    >
    > Software-Releases werden über den Build-Server gemacht und durch keine
    > lokale Maschine!

    Sagt wer?

    > Wenn ihr das lokal macht, dann stimmt der Prozess schon mal nicht.

    Einen Build-Server gibt es nicht, und "der Prozess" stimmt auch an diversen anderen Stellen nicht. Aber durch einen Umstieg auf git würde es noch schlimmer werden.

    > Und wenn Source Code wochenlang nicht im Repository landet, dann kann
    > schlimmstenfalls Arbeit von Wochen verloren gehen. Jeder sollte sich
    > angewöhnen mehrmals am Tag zu pushen. Wenn das jeder im eigenen Branch
    > macht, dann kann da nichts kaputt gehen.

    [Loriot]Ach?[/Loriot]
    >> (Und komme mir keiner mit "Dann braucht Ihr halt eine Schulung dafür.", das
    >> haben wir schon durch.)

  8. Re: Die Frage die nach dem Artikel bleibt...

    Autor: mnementh 17.03.21 - 15:19

    Steffo schrieb:
    --------------------------------------------------------------------------------
    > mnementh schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Ein eigener Branch der nie synchronisiert wird ist exakt das gleiche,
    > wie
    > > seine Änderungen lokal auf dem eigenen Rechner zu haben. Wenn man einen
    > > Branch hat, nur um einen Branch zu haben ist das sowieso blöd. Aber
    > > definitiv sollten sie regelmäßig synchronisieren, ansonsten verlagert
    > man
    > > die Konflikte nur irgendwann in die Zukunft.
    >
    > Das Thema Konflikte ist ein Thema für sich. Ich meinte, dass bei einem
    > lokalen Datenverlust Arbeit von Wochen verloren gehen kann, wenn man
    > wochenlang nicht pusht (git) bzw. committed (svn).
    >
    Sicher, aber das ist erfahrungsgemäß selten ein Problem. Konflikte wenn nach Wochen separater Arbeit jemand seinen Kram mergen will, das ist ein Problem.

    > Btw: Einen eigenen Branch sollte man immer(!) haben, wenn man etwas Neues
    > angeht. Sei es Feature, Bugfixes oder Refactoring. Es gibt nichts
    > schlimmeres als dass ein Build oder Test nicht durchläuft, weil ein Kollege
    > meint, er müsste direkt auf dem develop oder master-Branch arbeiten.
    Nee, es gibt nichts Schlimmeres als Leute die Regeln aufstellen wie man sollte immer alles in einem eigenen Branch tun. Der develop-branch (ob man den nun master oder main oder was auch immer nennt) darf ruhig ab und zu mal kaputtgehen. Zum einen sollten Release-Versionen nicht von dem develop-branch direkt kommen, sondern nach einem Feature-Freeze (entweder auf dem main-Branch oder einem eigenen für das Release).

    Das andere ist, dass man als Entwickler halt zerbrochene Tests oder nicht kompilierenden Kram auch sofort fixen sollte, bevor man das nächste angeht. Ein Continuuous Integration System hilft dabei indem es entsprechend nervt mit Meldungen. Aber viele nutzen einen eigenen Branch als billige Ausrede kaputte Tests oder so mit rumzuschleppen, weil 'es tut ja nichts zur Sache, ist ja nur mein Branch'. Üblicherweise macht man Continuuous Integration auch nicht auf den Tausenden Branches die Leute spontan anlegen, so dass man von der Seite nicht genervt wird. Und so hat man eine gute Ausrede für kaputten Code. Und wenn man das zu schlimm kaputt gemacht hat auf develop, kann man das immer noch reverten, dazu hat man ja schließlich ein Versionskontrollsystem.

    Meiner Erfahrung entspricht halt, dass die wilde Brancherei als Ausrede genutzt wird für schlechten Stil. Und man das nutzt um effektive Teamarbeit zu vermeiden. Wenn man einen Branch anlegt, dann sollte man wissen wofür.

  9. Re: Die Frage die nach dem Artikel bleibt...

    Autor: Steffo 17.03.21 - 16:08

    mnementh schrieb:
    --------------------------------------------------------------------------------
    > > Das Thema Konflikte ist ein Thema für sich. Ich meinte, dass bei einem
    > > lokalen Datenverlust Arbeit von Wochen verloren gehen kann, wenn man
    > > wochenlang nicht pusht (git) bzw. committed (svn).
    > >
    > Sicher, aber das ist erfahrungsgemäß selten ein Problem. Konflikte wenn
    > nach Wochen separater Arbeit jemand seinen Kram mergen will, das ist ein
    > Problem.

    Oft genug, sodass das irgendeinem Kollegen mindestens zwei mal im Jahr passiert. - Und das schon bei einem kleinen Team.
    Ich weiß auch nicht, was das Problem sein soll regelmäßig Branches zu synchronisieren. Man soll ein Problem, nicht durch ein anderes lösen (direkt auf develop entwickeln).

    > Meiner Erfahrung entspricht halt, dass die wilde Brancherei als Ausrede
    > genutzt wird für schlechten Stil. Und man das nutzt um effektive Teamarbeit
    > zu vermeiden. Wenn man einen Branch anlegt, dann sollte man wissen wofür.

    Du vermischt schon wieder Dinge. Schlechter Stil und Branches sind zwei verschiedene Dinge.
    Ich habe nicht nur einmal erlebt, dass Commits in develop, andere Entwickler unnötig aufgehalten haben. - Unnötig, weil durch Branches vermeidbar.
    Es gibt nicht umsonst das Git Flow Modell. Google mal, falls dir das nichts sagt. - Alles andere ist einfach nicht mehr zeitgemäß, sorry.

  10. Re: Die Frage die nach dem Artikel bleibt...

    Autor: Steffo 17.03.21 - 16:13

    dummzeuch schrieb:
    --------------------------------------------------------------------------------
    > Steffo schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > dummzeuch schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Ich denke da an Software-Releases, deren
    > > > Sourcecode nur in seinem lokalen Repository liegt, weil er
    > verschusselt
    > > > hat, es in das zentrale Repository zu übertragen. Es kommt ja sogar
    > > jetzt
    > > > schon vor, dass Sourcecode wochenlang nicht im Repository landet. (Und
    > > > komme mir keiner mit "Dann braucht Ihr halt eine Schulung dafür.", das
    > > > haben wir schon durch.)
    > >
    > > Software-Releases werden über den Build-Server gemacht und durch keine
    > > lokale Maschine!
    >
    > Sagt wer?

    Sagt die Vernunft. Es gibt nichts schlimmeres als Builds, die von irgendwelchen lokalen Rechnern abhängen.
    Wie kannst du sicher sein, dass
    - alles commited und auf dem Server gepusht wurde?
    - alle Tests durchgelaufen sind?
    - der Build und die Tests auf einer definierten Umgebung laufen und nicht auf irgendeiner Umgebung eines Entwicklers, der beliebig bei sich rumpfuschen kann?

    Was glaubst du, hat man das alles erfunden?

    Ganz ehrlich: Da rollt es mir die Zehennägel hoch, wenn ich sehe, wie manche entwickeln.

  11. Re: Die Frage die nach dem Artikel bleibt...

    Autor: mnementh 17.03.21 - 16:31

    Steffo schrieb:
    --------------------------------------------------------------------------------
    > mnementh schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > > Das Thema Konflikte ist ein Thema für sich. Ich meinte, dass bei einem
    > > > lokalen Datenverlust Arbeit von Wochen verloren gehen kann, wenn man
    > > > wochenlang nicht pusht (git) bzw. committed (svn).
    > > >
    > > Sicher, aber das ist erfahrungsgemäß selten ein Problem. Konflikte wenn
    > > nach Wochen separater Arbeit jemand seinen Kram mergen will, das ist ein
    > > Problem.
    >
    > Oft genug, sodass das irgendeinem Kollegen mindestens zwei mal im Jahr
    > passiert. - Und das schon bei einem kleinen Team.
    > Ich weiß auch nicht, was das Problem sein soll regelmäßig Branches zu
    > synchronisieren. Man soll ein Problem, nicht durch ein anderes lösen
    > (direkt auf develop entwickeln).
    >
    > > Meiner Erfahrung entspricht halt, dass die wilde Brancherei als Ausrede
    > > genutzt wird für schlechten Stil. Und man das nutzt um effektive
    > Teamarbeit
    > > zu vermeiden. Wenn man einen Branch anlegt, dann sollte man wissen
    > wofür.
    >
    > Du vermischt schon wieder Dinge. Schlechter Stil und Branches sind zwei
    > verschiedene Dinge.
    > Ich habe nicht nur einmal erlebt, dass Commits in develop, andere
    > Entwickler unnötig aufgehalten haben. - Unnötig, weil durch Branches
    > vermeidbar.
    > Es gibt nicht umsonst das Git Flow Modell. Google mal, falls dir das nichts
    > sagt. - Alles andere ist einfach nicht mehr zeitgemäß, sorry.
    Ich kannte das nicht, danke. Aber nun Google ich das:
    https://www.atlassian.com/de/git/tutorials/comparing-workflows/gitflow-workflow

    Und gleich zu Anfang steht da:
    > Stattdessen werden verschiedenen Branches sehr spezifische Rollen zugewiesen, und es wird genau festgelegt, wann und wie die Interaktion erfolgen soll.
    Ich schrieb zuvor:
    > Ich erwarte dass die Leute wissen wozu sie einen Branch aufmachen, wann er endet und ob es zurück in den Hauptzweig gemergt werden soll oder separat bleibt (gepflegte Legacy-Version beispielsweise).
    https://forum.golem.de/kommentare/software-entwicklung/umstieg-auf-git-reibungslos-die-versionsverwaltung-wechseln/die-frage-die-nach-dem-artikel-bleibt.../142252,5892379,5893346,read.html#msg-5893346

    Du dagegen sagst blind, dass nichts auf den Zweig direkt committet werden soll. Das sind unterschiedliche Aussagen.

    Schauen wir mal weiter. Da ist dieses Schaubild für git-flow. Darin sieht man deutlich violette Kullern für Commits auf dem Develop-Zweig, ohne dass zuvor einer der grünen Feature-Branch-Zweige gemergt wurde.

    Grob überflogen sieht git-flow nach einer sinnvollen Arbeitsweise aus. Kann natürlich sein, dass es im Detail nicht passt oder nicht zu jedem Projekt. Aber so weit ich das überblicke ist git-flow nicht das gleiche wie Deine dogmatische Verkündung, dass alle Arbeit auf branches stattfindet.

    EDIT: Ich habe auch den Artikel gefunden, der anscheinend die Grundlage von git-flow ist:
    https://nvie.com/posts/a-successful-git-branching-model/

    Erneut auch hier im Schaubild sind direkte Commits auf develop (in gelb) zu sehen:
    https://nvie.com/img/git-model@2x.png



    1 mal bearbeitet, zuletzt am 17.03.21 16:38 durch mnementh.

  12. Re: Die Frage die nach dem Artikel bleibt...

    Autor: Steffo 17.03.21 - 16:44

    mnementh schrieb:
    --------------------------------------------------------------------------------
    > Grob überflogen sieht git-flow nach einer sinnvollen Arbeitsweise aus. Kann
    > natürlich sein, dass es im Detail nicht passt oder nicht zu jedem Projekt.
    > Aber so weit ich das überblicke ist git-flow nicht das gleiche wie Deine
    > dogmatische Verkündung, dass alle Arbeit auf branches stattfindet.

    Mein Vorschlag ist zugegebenermaßen etwas strenger, aber in meiner vorletzten Firma, wurde diese Regel eingeführt, weil zum Teil mehrmals am Tag(!) im develop irgendetwas kaputt ging und wir waren gerade mal ~10 Entwickler.

    Diesen Fall hatte ich ebenfalls bei meiner letzten und auch in der jetzigen Firma in einem noch kleinerem Team erlebt, obwohl man sich darauf geeinigt hat, das nicht zu tun. Aber sobald man undiszipliniert wird, passiert das doch ganz schnell.



    1 mal bearbeitet, zuletzt am 17.03.21 16:53 durch Steffo.

  13. Re: Die Frage die nach dem Artikel bleibt...

    Autor: karazon 17.03.21 - 18:47

    Ich weiß jetzt nicht was du genau mit "direkten Commits" meinst, aber bei Git Flow wird niemals direkt auf develop gearbeitet. Alles wird auf eigenen Feature/Bugfix/Release-Branches erledigt. Zusammengeführt werden sollte das dann mittels eines Pull-Requests - so kann dann auch eine sinnvolle Code Review stattfinden.
    Man kann natürlich für alles Ausnahmefälle konstruieren, aber mir kam noch kein System unter mit dem sich angenehmer, störungsfreier und paralleler entwickeln ließe, als mit Git Flow♥️

  14. Re: Die Frage die nach dem Artikel bleibt...

    Autor: BLi8819 17.03.21 - 20:04

    Weil?

  15. Re: Die Frage die nach dem Artikel bleibt...

    Autor: BLi8819 17.03.21 - 20:12

    > Die Tools, zumindest die, die ich mir angesehen habe, sind deutlich schlechter als TortoiseSVN,
    Schon TortoiseGit versucht?
    Ansonsten ist Git doch in jeder bekannteren IDE sehr gut integriert, anders als SVN.

    > Ich denke da an Software-Releases, deren Sourcecode nur in seinem lokalen Repository liegt, weil er verschusselt hat, es in das zentrale Repository zu übertragen.
    Äm, Dummheit kann keine Software der Welt ausgleichen. Aber das sollte im Prozess doch auffallen, wenn eine erledigte Task nicht getestet werden kann, weil kein Code eingecheckt wurde.



    1 mal bearbeitet, zuletzt am 17.03.21 20:13 durch BLi8819.

  16. Re: Die Frage die nach dem Artikel bleibt...

    Autor: Trollversteher 18.03.21 - 08:05

    >Weil?

    Bei Git einfach *nichts* einfach und *alles* kompliziert, unintuitiv und umständlich geht? Und man sich sehr viel einfacher als bei SVN mal schnell eben mit einem unbedachten Klick (oder Shell Kommando) die Arbeit von Stunden kaputt machen kann um dann weitere wertvolle Zeit darein zu investieren, wie man das System wieder so ans laufen bekommt, dass man beim nächsten Push auf den Server nicht auch noch allen anderen Kollegen das Leben schwer macht? Mergen mit Git ist ein Albtraum. Ich hatte bei den letzten malen das Gefühl, Git würfelt einfach, welche geänderte Codezeile es für aktueller hält.

    Wie gesagt: Das hat sicher alles seine Gründe, eine Sourcecodeverwaltung, die auch offline mit lokalen Repositories arbeitet ist sicher komplexer als eine, die nur *ein* aktives Repository kennt, und sicher ist Git auch sehr viel mächstiger als Kommandozeilentool also über Scripts zu steuern und zu pflegen - aber als "einfacher" Entwickler, der einfach nur schnell und unkompliziert Morgens den aktuellen Stand vom Server holen und während des Tages seinen Stand einchecken möchte, und hin und wieder mal auf einem Branch arbeitet, war mir SVN sehr viel lieber, denn war für *mich* (dem CM mag das anders gegangen sein) immer sehr viel simpler, sicherer und pfelegeleichter zu bedienen und hat mich keine zusätzliche Arbeitszeit gekostet, ganz im Gegensatz zu Git.

  17. Re: Die Frage die nach dem Artikel bleibt...

    Autor: Steffo 18.03.21 - 09:24

    Trollversteher schrieb:
    --------------------------------------------------------------------------------
    > ... dass man beim
    > nächsten Push auf den Server nicht auch noch allen anderen Kollegen das
    > Leben schwer macht?

    Vielleicht einfach auf deinem eigenen Branch arbeiten?

    Zum Rest: Einfach mal 1 h mit git auseinandersetzen.

    SVN mag einfacher sein, aber dafür auch eingeschränkter.

  18. Re: Die Frage die nach dem Artikel bleibt...

    Autor: Trollversteher 18.03.21 - 09:50

    >Vielleicht einfach auf deinem eigenen Branch arbeiten?

    Direkt auf dem Master arbeitet bei uns niemand, wir haben eben Story-spezifische Branches auf denen je nach Situation mal 2-4 Kollegen gleichzeitig arbeiten, die noch weiter zu branchen wäre allerdings Overkill.
    Zudem: Auch der muss irgendwann wieder zurück gemerged werden. Und Ich und mergen mit Git stehen auf dem Kriegsfuß.

    >Zum Rest: Einfach mal 1 h mit git auseinandersetzen.

    Nö, das reicht nicht, ich weiß nicht wieviele Stunden ich schon mit Problemsuche auf Stack Overflow, Tutorials & Co verbracht habe, weil Git mal wieder nicht wollte wie ich, aber ich stoße immer wieder auf neue Hindernisse. Mit SVN hatte ich *nie* solche Probleme.

    >SVN mag einfacher sein, aber dafür auch eingeschränkter.

    Sag ich ja, ich erkenne ja durchaus an, dass Git sehr viel mächtiger ist als SVN, aber
    ich als "dummer Entwickler", der einfach nur arbeiten möchte und seine Arbeitszeit lieber in die Entwicklung als in den Kampf mit sperrigen Tools steckt, war mit dem "easy-to-use" SVN deutlich glücklicher.

  19. Re: Die Frage die nach dem Artikel bleibt...

    Autor: taifun850 20.03.21 - 08:06

    Er hat halt einfach Recht.

  20. Re: Die Frage die nach dem Artikel bleibt...

    Autor: lvds 21.03.21 - 14:31

    Das Mergen mit git wird doch eigentlich immer nur dann zum Problem, wenn der Branch zu lange asynchron verlief oder keine "zentralen" Absprachen über abhängige Änderungen getätigt wurden. Mit Hilfe von fetchs ist das weg driften dann lokal sichtbar und der zukünftige Ärger vorprogrammiert.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Mathematiker in der iGaming Branche (w/m/d)
    Gamomat Development GmbH, Berlin
  2. Data Center Operations Manager (m/w/d)
    GRAMMER AG, Ursensollen bei Amberg
  3. Berufseinstieg SAP-Berater*in (m/w/d)
    Lufthansa Industry Solutions AS GmbH, Hamburg, Frankfurt, Wetzlar, Köln, Stuttgart
  4. Wissenschaftlich-technische Mitarbeiterin / Wissenschaftlich-technischer Mitarbeiter (m/w/d) ... (m/w/d)
    Bundesanstalt für Straßenwesen, Bergisch Gladbach

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 208,48€ (Bestpreis!)
  2. 109€ und 99€ bei Newsletter-Anmeldung (Bestpreis!)
  3. (u. a. DeepCool Matrexx 55 V3 ADD-RGB WH für 42,99€ + 6,99€ Versand statt 78,35€ im...
  4. 139,90€ + 5,99€ Versand bei Vorkasse (Vergleichspreis 226,40€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Halbleiterproduktion: TSMC will klimaneutral werden
Halbleiterproduktion
TSMC will klimaneutral werden

Der Chiphersteller TSMC hat angekündigt, bis 2050 seine Emissionen auf "Netto-Null" zu senken - setzt dabei aber auch auf fragwürdige Kompensationsprojekte.
Von Hanno Böck

  1. Halbleiterfertigung Intel soll mehr 3-nm-Buchungen als Apple haben
  2. Halbleiterfertigung Was TSMC in den nächsten Monaten vorhat
  3. Halbleiterfertigung AMDs Epyc produzieren sich bei TSMC selbst

Leserumfrage: Wie wünschst du dir Golem.de?
Leserumfrage
Wie wünschst du dir Golem.de?

Ob du täglich mehrmals Golem.de liest oder ab und zu: Wir sind an deiner Meinung interessiert! Hilf uns, Golem.de noch besser zu machen - die Umfrage dauert weniger als 10 Minuten.

  1. TECH TALKS Kann Europa Chips?
  2. TECH TALKS Drohnen, Daten und Deep Learning in der Landwirtschaft
  3. In eigener Sache Englisch lernen mit Golem.de und Gymglish

Elite 3 und Studio Buds im Test: Jabra deklassiert doppelt so teure Beats-Stöpsel
Elite 3 und Studio Buds im Test
Jabra deklassiert doppelt so teure Beats-Stöpsel

Können 80 Euro teure Bluetooth-Hörstöpsel Konkurrenten für 150 Euro schlagen? Wir haben die Probe aufs Exempel gemacht.
Ein Test von Ingo Pakalski

  1. Jabra Elite 7 Pro Besonders kleine ANC-Stöpsel mit sehr langer Akkulaufzeit
  2. Elite 3 Airpods-Konkurrenz von Jabra für 80 Euro