Làm thế nào để bạn thực thi hành vi git, bao gồm cả cục bộ (đặc biệt là trên Windows)?


13

Tôi đang quan tâm đến việc chuyển cửa hàng .NET này từ svn sang git và đã xác định được một số vấn đề phụ trợ mà tôi muốn có giải pháp trước khi chúng tôi chuyển đổi.

Điều tôi đặc biệt hỏi trong câu hỏi này là thực thi kết thúc dòng. Theo mặc định, git cho các cài đặt windows với 'checkout crlf, commit lf', sẽ không hoạt động đối với một loạt các nguồn (theo như tôi biết) chỉ bao gồm các kết thúc crlf.

Tôi không biết rằng tôi tin tưởng một cách mù quáng bất kỳ nhà phát triển nào đã định cấu hình chính xác hướng dẫn này ngay cả khi được chỉ định, vì vậy tôi đang xem xét một (hoặc cả hai) điều sau đây nhưng tò mò liệu có ai ở đây đã đi một con đường khác không.

  • Một hook pre-commit kiểm tra bất kỳ kết thúc dòng lf nào (hoặc có thể là tất cả các kết thúc dòng lf) và từ chối trong sự kiện đó.
  • Một tập lệnh cài đặt được phân phối cho các nhà phát triển cấu hình toàn cầu với 'nguyên trạng, nguyên trạng'.

PS Trong khi viết điều này, tôi nhận ra rằng việc chuyển đổi ban đầu từ svn sang git có thể cam kết theo cách mặc định và miễn là mọi người bị mắc kẹt vào mặc định cũng sẽ khá liền mạch. Đã từng là một nhà phát triển sử dụng git trong một cửa hàng .NET đã cài đặt git với "mặc định, như hiện tại", tôi cũng đã tạo ra các vấn đề của riêng mình ở đó (tất cả đều được mặc định trước khi tôi đến) . Vì vậy, tôi vẫn đang nghiêng về một số loại cơ chế thực thi.


2
Với phía máy chủ hook nhận trước, điều này có thể xử lý được (đảm bảo kết thúc crlf và không thành công nếu không), với hook hook cập nhật, bạn cũng có thể cập nhật hợp nhất trước. Bạn đang sử dụng loại máy chủ git nào? Nếu điều này phải được thực hiện bên máy trạm, Trình quản lý cấu hình có thể là cách để thực hiện, nhưng khó hơn và với một loạt các nhược điểm. Phương sách cuối cùng là dựa vào CI và không bắt buộc mọi người phải tuân theo các thủ tục
Tensibai

1
Tôi đồng ý với Tensibai và sẽ thêm rằng tùy chọn bạn chọn phải dựa trên mức độ nghiêm trọng mà bạn tin rằng điều này sẽ được thi hành. Móc trước cam kết thực thi nghiêm ngặt, báo cáo tuân thủ sau cam kết.
Dave Swersky

Cảm ơn Dave, lý do căn bản của tôi đối với việc thực thi phía khách hàng / nghiêm ngặt hơn là nó sẽ đòi hỏi ít công việc hơn đối với tôi và bắt lỗi sớm hơn. Không đi đến các máy trạm của các nhà phát triển nhưng các máy chủ của nhà phát triển đều ở chế độ DSC nên việc bổ sung sẽ không đáng kể. Chỉnh sửa: Cảm ơn bạn cũng như @Tensibai ... bạn có thể giải thích về những nhược điểm mà bạn thấy đối với phía khách hàng không?
ndarwincorn

1
Chủ yếu là nếu bạn thực thi một phía máy khách hook toàn cầu, bạn có thể sẽ ngăn chặn công việc đối với các dự án cần kết thúc lf. Và bạn phải thiết lập nó theo một cách nào đó, bạn không thể chắc chắn mọi người sẽ làm theo đúng thiết lập. Tôi chắc chắn có những khẩu súng ngắn khác mà tôi không nghĩ đến ngay bây giờ
Tensibai

Rốt cuộc bạn đã làm gì để giải quyết vấn đề của mình?
Newtopian

Câu trả lời:


6

Để trả lời câu hỏi làm thế nào để thực thi một cái gì đó cục bộ, bạn không thể thực hiện một số công việc rất nặng nề xung quanh việc quản lý và thực thi trạng thái của mọi máy trạm của nhà phát triển, và tôi thường cho rằng các nhà phát triển có lẽ nên là quản trị viên địa phương cho sự phát triển của họ bởi vì nếu họ không làm như vậy thì họ sẽ chỉ dành thời gian để tìm ra cách để chúng ta có được những đặc quyền đó.

Và đó có lẽ là do bạn không cần quan tâm đến trạng thái cấu hình cục bộ khi sử dụng kiểm soát phiên bản phân tán. Bạn chỉ nên quan tâm đến trạng thái cấu hình của bạn . Giả sử bạn đang sử dụng git như một hệ thống kiểm soát phiên bản tập trung, bởi vì về cơ bản đó là điều mà mọi người đều làm vì nó dễ nhất, vậy thì hãy giả sử rằng cấu hình "của bạn" là bản sao của mã được lưu trên máy chủ trung tâm.

Nếu đây là trường hợp thì bạn không nên chấp nhận hợp nhất rằng, như bạn đã đề cập, phá vỡ các kết thúc dòng crlf / lf. Vì vậy, bạn thực thi rằng khi một số khách hàng khác cố gắng thay đổi bạn bằng logic phía máy chủ từ chối yêu cầu gây ô nhiễm repo của bạn với các lựa chọn phong cách có khả năng phá vỡ của họ .


4

Chúng tôi yêu cầu quá trình xem xét bằng cách sử dụng các yêu cầu Kéo trong github trên các nhánh chính hoặc nhánh chính của chúng tôi. Trong quá trình xem xét đó, chúng tôi sẽ đánh dấu các yêu cầu kéo là yêu cầu thay đổi nếu nhiều tệp có chênh lệch kết thúc dòng trắng hoặc dòng trắng và nhấn mạnh rằng chúng tuân theo định dạng của nhánh dev hoặc nhánh chính mà chúng đang thực hiện yêu cầu kéo.

Ngoài ra còn có một số công cụ hay tùy thuộc vào ngôn ngữ bạn sử dụng và công cụ CI nào bạn sử dụng, có thể, trong quá trình xây dựng hoặc kéo yêu cầu bước tự động định dạng mã dựa trên các quy tắc mà bạn thiết lập. Điều đó cũng giúp giữ cho mã trông nhất quán và giảm thiểu các vấn đề định dạng khi cam kết mã.


Bạn có quan tâm đến việc xây dựng các công cụ bạn đang sử dụng không? Cho rằng có một số cách để thực hiện điều này và chúng tôi đã có cách riêng của mình nhưng chưa thực sự thực hiện chúng theo cách đó, tôi tò mò về cách bạn giải quyết điều đó.
ndarwincorn

1
Chúng tôi đang sử dụng typcript, github và jenkins. Bản mô tả có một hệ sinh thái tốt đẹp cho loại điều này.
avi

3

Bạn có thể sử dụng mỗi cấu hình kho lưu trữ để ghi đè cấu hình của người dùng trên cơ sở mỗi kho lưu trữ. Khi được thực hiện trên repo được coi là nguồn trung tâm, nó sẽ lan truyền với các bản sao và kéo đến các repos khác bao gồm cả các repos cục bộ do đó ghi đè tập trung vào cấu hình cục bộ.

Bạn có thể thực thi thêm điều này thông qua các hook trong repo trung tâm của mình để kiểm tra xem các kết thúc tập tin có phải là những gì chúng được cho là và từ chối hợp nhất / đẩy nếu nó không phải là Kosher. Tuy nhiên, các hook này sẽ không nhân bản với repo, ít nhất là không trực tiếp nhưng điều này là không cần thiết vì các quy tắc chỉ thực sự cần phải được thực thi trên repo trung tâm.

Sử dụng các mẫu trong git init của bạn, bạn có thể đảm bảo rằng các repos của bạn được tạo bằng với tất cả các tệp gitignore, gitattribution vv theo cách bạn muốn.

Điều cuối cùng, không liên quan trực tiếp đến câu hỏi của bạn, tôi đã tìm thấy điểm ma sát lớn nhất khi đưa nhóm svn sa lượn vào một quy trình làm việc dựa trên git những gì để làm cho họ quen với repo thêm ở giữa. Tôi thấy rằng bảng cue trực quan này đã giúp một chút giải thích lệnh nào có tác dụng gì với phần nào.

Hy vọng điều này sẽ giúp một chút.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.